On 17 April 2015 at 03:29, Steven D'Aprano wrote:
> On Thu, Apr 16, 2015 at 03:11:59PM -0700, Jim Mooney wrote:
>
>> So the longer numerator and denominator would, indeed, be more accurate if
>> used in certain calculations rather than being normalized to a float - such
>> as in a Fortran subrouti
On Thu, Apr 16, 2015 at 03:11:59PM -0700, Jim Mooney wrote:
> So the longer numerator and denominator would, indeed, be more accurate if
> used in certain calculations rather than being normalized to a float - such
> as in a Fortran subroutine or perhaps if exported to a machine with a
> longer bi
The whole point of the discussion is that this is *not* a presentation
issue. Fraction(1.64) and Fraction("1.64") *are* two different numbers
because one gets constructed from a value that is not quite 1.64.
Wolfgang Maier
--
So the longer numerator and denominator would, indeed, be more accurate
On 04/16/2015 01:24 PM, Jim Mooney wrote:
Is this "inaccurate"? Well, in the sense that it is not the exact true
mathematical result, yes it is, but that term can be misleading if you
think of it as "a mistake". In another sense, it's not inaccurate, it is
as accurate as possible (given the limi
On Apr 16, 2015 1:42 PM, "Jim Mooney" wrote:
> Understood about the quondam inexactness of floating point bit
> representation. I was just wondering why the different implementation of
> representing it when using Fraction(float) as opposed to using
> Fraction(string(float)).
Ah. Correction. Y
On 16.04.2015 19:24, Jim Mooney wrote:
Understood about the quondam inexactness of floating point bit
representation. I was just wondering why the different implementation of
representing it when using Fraction(float) as opposed to using
Fraction(string(float)). In terms of user presentation, t
>
> Is this "inaccurate"? Well, in the sense that it is not the exact true
> mathematical result, yes it is, but that term can be misleading if you
> think of it as "a mistake". In another sense, it's not inaccurate, it is
> as accurate as possible (given the limitation of only having a certain
> f
On Thu, Apr 16, 2015 at 01:52:51AM -0700, Danny Yoo wrote:
> It's this last supposition that should be treated most seriously. Most
> computers use "floating point", a representation of numbers that use a
> fixed set of bits. This uniformity allows floating point math to be
> implemented quickly
On 04/16/2015 08:11 AM, Dave Angel wrote:
On 04/16/2015 01:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fract
On 04/16/2015 01:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction("1.64")
Fraction(41, 25)
41/25
1.64
On Apr 16, 2015 1:52 AM, "Danny Yoo" wrote:
>
>
> On Apr 16, 2015 1:32 AM, "Jim Mooney" wrote:
> >
> > Why does Fraction interpret a number and string so differently? They
come
> > out the same, but it seems rather odd
> >
> > >>> from fractions import Fraction
> > >>> Fraction(1.64)
> > Fraction
On 04/16/2015 07:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction("1.64")
Fraction(41, 25)
41/25
1.64
On Apr 16, 2015 1:32 AM, "Jim Mooney" wrote:
>
> Why does Fraction interpret a number and string so differently? They come
> out the same, but it seems rather odd
>
> >>> from fractions import Fraction
> >>> Fraction(1.64)
> Fraction(738590337613, 4503599627370496)
> >>> Fraction("1.64")
> Fra
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
>>> from fractions import Fraction
>>> Fraction(1.64)
Fraction(738590337613, 4503599627370496)
>>> Fraction("1.64")
Fraction(41, 25)
>>> 41/25
1.64
>>> 738590337613 / 45035996273
14 matches
Mail list logo
