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 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