On Feb 25, 12:52 am, Grant Edwards wrote:
> So I think the C standard actually
> forces the compiler to convert results to 64-bits at the points where
> a store to a temporary variable happens.
I'm not sure that this is true. IIRC, C99 + Annex F forces this, but
C99 by itself doesn't.
> Indeed.
On Feb 25, 12:33 am, Steven D'Aprano wrote:
> On Thu, 24 Feb 2011 10:40:45 -0600, Robert Kern wrote:
> > On 2/24/11 5:55 AM, Steven D'Aprano wrote:
> >> On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
>
> >>> The IEEE 754 compliant FPU on most machines today, though, has an
> >>> 80-bit inte
On 01/-10/-28163 02:59 PM, Grant Edwards wrote:
On 2011-02-25, Steven D'Aprano wrote:
C double *variables* are, but as John suggests, C compilers are allowed
(to my knowledge) to keep intermediate results of an expression in the
larger-precision FPU registers. The final result does get shoved
On Fri, 2011-02-25 at 00:57 +, Grant Edwards wrote:
> On 2011-02-25, Westley Mart?nez wrote:
>
> > Maybe I'm wrong, but wouldn't compiling Python with a compiler that
> > supports extended precision for intermediates allow Python to use
> > extended precision for its immediates?
>
> I'm not
On 2011-02-25, Westley Mart?nez wrote:
> Maybe I'm wrong, but wouldn't compiling Python with a compiler that
> supports extended precision for intermediates allow Python to use
> extended precision for its immediates?
I'm not sure what you mean by "immediates", but I don't think so. For
the C c
On 2011-02-25, Steven D'Aprano wrote:
>> C double *variables* are, but as John suggests, C compilers are allowed
>> (to my knowledge) to keep intermediate results of an expression in the
>> larger-precision FPU registers. The final result does get shoved back
>> into a 64-bit double when it is at
On Fri, 2011-02-25 at 00:33 +, Steven D'Aprano wrote:
> On Thu, 24 Feb 2011 10:40:45 -0600, Robert Kern wrote:
>
> > On 2/24/11 5:55 AM, Steven D'Aprano wrote:
> >> On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
> >>
> >>> The IEEE 754 compliant FPU on most machines today, though, has a
On Thu, 24 Feb 2011 10:40:45 -0600, Robert Kern wrote:
> On 2/24/11 5:55 AM, Steven D'Aprano wrote:
>> On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
>>
>>> The IEEE 754 compliant FPU on most machines today, though, has an
>>> 80-bit internal representation. If you do a sequence of operati
On 2/24/11 5:55 AM, Steven D'Aprano wrote:
On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
The IEEE 754 compliant FPU on most machines today, though, has an 80-bit
internal representation. If you do a sequence of operations that retain
all the intermediate results in the FPU registers, y
D'Arcy J.M. Cain wrote:
> On Thu, 24 Feb 2011 04:56:46 -0800
> Ethan Furman wrote:
>> > That's a big if though. Which languages support such a thing? C doubles
>> > are 64 bit, same as Python.
>>
>> Assembly! :)
>
> Really? Why would you need that level of precision just to gather all
> the s
On Thu, 24 Feb 2011 04:56:46 -0800
Ethan Furman wrote:
> >> The IEEE 754 compliant FPU on most machines today, though, has an 80-bit
> >> internal representation. If you do a sequence of operations that retain
> >> all the intermediate results in the FPU registers, you get 16 more bits
> >> of pr
Steven D'Aprano wrote:
On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
The IEEE 754 compliant FPU on most machines today, though, has an 80-bit
internal representation. If you do a sequence of operations that retain
all the intermediate results in the FPU registers, you get 16 more bits
On Wed, 23 Feb 2011 13:26:05 -0800, John Nagle wrote:
> The IEEE 754 compliant FPU on most machines today, though, has an 80-bit
> internal representation. If you do a sequence of operations that retain
> all the intermediate results in the FPU registers, you get 16 more bits
> of precision than
On 2/22/2011 9:59 AM, Roy Smith wrote:
In article,
Grant Edwards wrote:
Python doesn't do equations. Python does floating point operations.
More generally, all general-purpose programming languages have the same
problem. You'll see the same issues in Fortran, C, Java, Ruby, Pascal,
etc,
On 2011-02-23, Terry Reedy wrote:
> On 2/22/2011 2:42 PM, Grant Edwards wrote:
>
>> Except that Python (and computer languages in general) don't deal with
>> real numbers. They deal with floating point numbers, which aren't the
>> same thing. [In case anybody is still fuzzy about that.]
>
> In p
On 2/22/2011 2:42 PM, Grant Edwards wrote:
Except that Python (and computer languages in general) don't deal with
real numbers. They deal with floating point numbers, which aren't the
same thing. [In case anybody is still fuzzy about that.]
In particular, floats are a fixed finite set of rat
On 22 Feb., 21:18, Stephen Hansen wrote:
> On 2/22/11 5:20 AM, christian schulze wrote:
>
> > I just found out, how much Python fails on simple math.
> 2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
>
> Everyone else has answered very well, so I won't comment on the actual
> question at hand-- it see
On 22 Feb, 14:20, christian schulze wrote:
> Hey guys,
>
> I just found out, how much Python fails on simple math. I checked a
> simple equation for a friend.
Python does not fail. Floating point arithmetics and numerical
approximations will do this. If you need symbolic maths, consider
using the
On 2/22/11 5:20 AM, christian schulze wrote:
> I just found out, how much Python fails on simple math.
2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
Everyone else has answered very well, so I won't comment on the actual
question at hand-- it seems to have been answered completely.
But! I shall go
On 2011-02-22, Ian Kelly wrote:
> On Tue, Feb 22, 2011 at 9:54 AM, David C. Ullrich
> wrote:
>> Anyway, I don't know why you're jumping to the conclusion that it's
>> Python that's wrong here. Could be the math you learned in school
>> is wrong. I mean you're assuming that
>>
>> (*) ? ? ? a(b+c)
On 2011-02-22, Roy Smith wrote:
> In article ,
> Grant Edwards wrote:
>
>> Python doesn't do equations. Python does floating point operations.
>
> More generally, all general-purpose programming languages have the same
> problem. You'll see the same issues in Fortran, C, Java, Ruby, Pascal,
On Tue, Feb 22, 2011 at 9:54 AM, David C. Ullrich wrote:
> Anyway, I don't know why you're jumping to the conclusion that it's
> Python that's wrong here. Could be the math you learned in school
> is wrong. I mean you're assuming that
>
> (*) a(b+c) = ab + ac
>
> but what makes you so certai
In article ,
Grant Edwards wrote:
> Python doesn't do equations. Python does floating point operations.
More generally, all general-purpose programming languages have the same
problem. You'll see the same issues in Fortran, C, Java, Ruby, Pascal,
etc, etc. You'll see the same problem if yo
On 2011-02-22, christian schulze wrote:
> Hey guys,
>
> I just found out, how much Python fails on simple math.
Python doesn't do math.
It does floating point operations.
They're different. Seriously.
On all of the platforms I know of, it's IEEE 754 (base-2) floating
point.
> I checked a sim
In article
<127fc97e-c210-4df1-952c-f6383d44b...@o8g2000vbq.googlegroups.com>,
christian schulze wrote:
> Hey guys,
>
> I just found out, how much Python fails on simple math. I checked a
> simple equation for a friend.
>
> [code]
> >>> from math import e as e
> >>> from math import sqrt as s
christian schulze wrote:
> Hey guys,
>
> I just found out, how much Python fails on simple math. I checked a
> simple equation for a friend.
>
> [code]
from math import e as e
from math import sqrt as sqrt
2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
> False
> [/code]
>
Try the same i
christian schulze wrote:
Hey guys,
I just found out, how much Python fails on simple math. I checked a
simple equation for a friend.
[code]
from math import e as e
from math import sqrt as sqrt
2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
e has no accurate representation in computer science. Nei
On 22/02/2011 13:20, christian schulze wrote:
Hey guys,
I just found out, how much Python fails on simple math. I checked a
simple equation for a friend.
[code]
from math import e as e
from math import sqrt as sqrt
2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
False
[/code]
So WTF? The equation is
On Tue, Feb 22, 2011 at 8:20 AM, christian schulze
wrote:
> Hey guys,
>
> I just found out, how much Python fails on simple math. I checked a
> simple equation for a friend.
>
> [code]
from math import e as e
from math import sqrt as sqrt
2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
> Fal
On Tue, 2011-02-22 at 05:20 -0800, christian schulze wrote:
> [code]
> >>> from math import e as e
> >>> from math import sqrt as sqrt
> >>> 2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
> False
> [/code]
> I was wondering what exactly is failing here. The math module? Python,
> or the IEEE specification
christian schulze wrote:
> #1:
2.0 * e * sqrt(3.0) - 2.0 * e
> 3.9798408154464964
>
> #2:
2.0 * e * (sqrt(3.0) -1.0)
> 3.979840815446496
>
> I was wondering what exactly is failing here. The math module? Python,
> or the IEEE specifications?
Limited-precision calculation, computer flo
-- Forwarded message --
From: Grigory Javadyan
Date: Tue, Feb 22, 2011 at 5:32 PM
Subject: Re: Python fails on math
To: christian schulze
Everybody knows you can't just compare floating point values for
equality with a simple ==.
Instead, check that the difference between
You may want to restrict the result to certain limit in the floating
numbers
each system has its own levels of floating numbers and even a small
difference is a difference to return FALSE
On Tue, Feb 22, 2011 at 6:50 PM, christian schulze wrote:
> Hey guys,
>
> I just found out, how much Python
Hey guys,
I just found out, how much Python fails on simple math. I checked a
simple equation for a friend.
[code]
>>> from math import e as e
>>> from math import sqrt as sqrt
>>> 2*e*sqrt(3) - 2*e == 2*e*(sqrt(3) - 1)
False
[/code]
So WTF? The equation is definitive equivalent. (See http://mat
34 matches
Mail list logo
