On Feb 25, 12:33 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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,
On Feb 25, 12:52 am, Grant Edwards inva...@invalid.invalid 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
On 01/-10/-28163 02:59 PM, Grant Edwards wrote:
On 2011-02-25, Steven D'Apranosteve+comp.lang.pyt...@pearwood.info 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
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 if
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 Thu, 24 Feb 2011 04:56:46 -0800
Ethan Furman et...@stoneleaf.us 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
D'Arcy J.M. Cain wrote:
On Thu, 24 Feb 2011 04:56:46 -0800
Ethan Furman et...@stoneleaf.us 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
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,
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 operations
that
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 an
80-bit
On 2011-02-25, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On 2011-02-25, Westley Mart?nez aniko...@gmail.com 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
On Fri, 2011-02-25 at 00:57 +, Grant Edwards wrote:
On 2011-02-25, Westley Mart?nez aniko...@gmail.com 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?
On 2011-02-23, Terry Reedy tjre...@udel.edu 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.]
On 2/22/2011 9:59 AM, Roy Smith wrote:
In articleik0rmr$ck4$1...@reader1.panix.com,
Grant Edwardsinvalid@invalid.invalid 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
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://mathbin.net
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://mathbin.net/59158)
PS:
#1
-- Forwarded message --
From: Grigory Javadyan grigory.javad...@gmail.com
Date: Tue, Feb 22, 2011 at 5:32 PM
Subject: Re: Python fails on math
To: christian schulze xcr...@googlemail.com
Everybody knows you can't just compare floating point values for
equality with a simple
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 floating-point for
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 specifications?
I'm not sure
On Tue, Feb 22, 2011 at 8:20 AM, christian schulze
xcr...@googlemail.com 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
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
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
christian schulze xcr...@googlemail.com 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
In article
127fc97e-c210-4df1-952c-f6383d44b...@o8g2000vbq.googlegroups.com,
christian schulze xcr...@googlemail.com 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
On 2011-02-22, christian schulze xcr...@googlemail.com 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
In article ik0rmr$ck4$1...@reader1.panix.com,
Grant Edwards invalid@invalid.invalid 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,
On Tue, Feb 22, 2011 at 9:54 AM, David C. Ullrich dullr...@sprynet.com 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
On 2011-02-22, Roy Smith r...@panix.com wrote:
In article ik0rmr$ck4$1...@reader1.panix.com,
Grant Edwards invalid@invalid.invalid wrote:
Python doesn't do equations. Python does floating point operations.
More generally, all general-purpose programming languages have the same
problem.
On 2011-02-22, Ian Kelly ian.g.ke...@gmail.com wrote:
On Tue, Feb 22, 2011 at 9:54 AM, David C. Ullrich dullr...@sprynet.com
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
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 all
On 22 Feb, 14:20, christian schulze xcr...@googlemail.com 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
On 22 Feb., 21:18, Stephen Hansen me+list/pyt...@ixokai.io 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
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
34 matches
Mail list logo
