On 17 April 2015 at 03:29, Steven D'Aprano st...@pearwood.info 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
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:52 AM, Danny Yoo danny@gmail.com wrote:
On Apr 16, 2015 1:32 AM, Jim Mooney cybervigila...@gmail.com 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
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 / 4503599627370496
1.64
--
On Apr 16, 2015 1:32 AM, Jim Mooney cybervigila...@gmail.com 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)
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)
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 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 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,
On Apr 16, 2015 1:42 PM, Jim Mooney cybervigila...@gmail.com 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)).
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
fixed
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 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
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
14 matches
Mail list logo
