Michael Torrie wrote:
He's simply showing you the hex (binary) representation of the
floating-point number's binary representation. As you can clearly see
in the case of 1.1, there is no finite sequence that can store that.
You end up with repeating numbers.
Thanks for the explanation.
On 2012-02-27, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 26 Feb 2012 16:24:14 -0800, John Ladasky wrote:
Curiosity prompts me to ask...
Those of you who program in other languages regularly: if you visit
comp.lang.java, for example, do people ask this question
On 02/27/2012 08:02 AM, Grant Edwards wrote:
On 2012-02-27, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 26 Feb 2012 16:24:14 -0800, John Ladasky wrote:
Curiosity prompts me to ask...
Those of you who program in other languages regularly: if you visit
comp.lang.java,
jmfauth wrote:
On 25 fév, 23:51, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:
(2.0).hex()
'0x1.0p+1'
(4.0).hex()
'0x1.0p+2'
(1.5).hex()
'0x1.8p+0'
(1.1).hex()
'0x1.1999ap+0'
On 02/27/2012 10:28 AM, Ethan Furman wrote:
jmfauth wrote:
On 25 fév, 23:51, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:
(2.0).hex()
'0x1.0p+1'
(4.0).hex()
'0x1.0p+2'
(1.5).hex()
On 25 fév, 23:51, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:
(2.0).hex()
'0x1.0p+1'
(4.0).hex()
'0x1.0p+2'
(1.5).hex()
'0x1.8p+0'
(1.1).hex()
'0x1.1999ap+0'
jmf
Curiosity prompts me to ask...
Those of you who program in other languages regularly: if you visit
comp.lang.java, for example, do people ask this question about
floating-point arithmetic in that forum? Or in comp.lang.perl?
Is there something about Python that exposes the uncomfortable truth
On 2/26/2012 7:24 PM, John Ladasky wrote:
I always found it helpful to ask someone who is confused by this issue
to imagine what the binary representation of the number 1/3 would be.
0.011 to three binary digits of precision:
0.0101 to four:
0.01011 to five:
0.010101 to six:
0.0101011 to
On Sun, 26 Feb 2012 16:24:14 -0800, John Ladasky wrote:
Curiosity prompts me to ask...
Those of you who program in other languages regularly: if you visit
comp.lang.java, for example, do people ask this question about
floating-point arithmetic in that forum? Or in comp.lang.perl?
Yes.
For every floating point
number there is a corresponding real number, but 0% of real numbers
can be represented exactly by floating point numbers.
It seems to me that there are a great many real numbers that can be
represented exactly by floating point numbers. The number 1 is an
example.
On Sat, 2012-02-25 at 09:56 -0800, Tobiah wrote:
For every floating point
number there is a corresponding real number, but 0% of real numbers
can be represented exactly by floating point numbers.
It seems to me that there are a great many real numbers that can be
represented exactly
On 2/25/2012 12:56 PM, Tobiah wrote:
It seems to me that there are a great many real numbers that can be
represented exactly by floating point numbers. The number 1 is an
example.
Binary floats can represent and integer and any fraction with a
denominator of 2**n within certain ranges. For
(2.0).hex()
'0x1.0p+1'
(4.0).hex()
'0x1.0p+2'
(1.5).hex()
'0x1.8p+0'
(1.1).hex()
'0x1.1999ap+0'
jmf
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:
(2.0).hex()
'0x1.0p+1'
(4.0).hex()
'0x1.0p+2'
(1.5).hex()
'0x1.8p+0'
(1.1).hex()
'0x1.1999ap+0'
jmf
What's your point? I'm afraid my crystal ball is out of order and I have
no idea whether
On Sat, Feb 25, 2012 at 2:08 PM, Tim Wintle tim.win...@teamrubber.com wrote:
It seems to me that there are a great many real numbers that can be
represented exactly by floating point numbers. The number 1 is an
example.
I suppose that if you divide that count by the infinite count of
On 2/25/2012 9:49 PM, Devin Jeanpierre wrote:
What this boils down to is to say that, basically by definition, the
set of numbers representable in some finite number of binary digits is
countable (just count up in binary value). But the whole of the real
numbers are uncountable. The hard part
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Proof
http://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-794.95
-60.95 aka (-(1219/20))
Is there a reason Python math is only approximated? - Or is this a bug?
On 22/02/2012 18:13, Alec Taylor wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Proof
http://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-794.95
-60.95 aka (-(1219/20))
Is there a reason Python math
Am 22.02.2012 19:13, schrieb Alec Taylor:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
That's only the correct answer for unlimited precision, not for IEEE-754
semantics. http://en.wikipedia.org/wiki/IEEE_754
Proof
On Wed, Feb 22, 2012 at 11:13 AM, Alec Taylor alec.tayl...@gmail.com wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Proof
http://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-794.95
-60.95 aka
On Feb 22, 2012 1:16 PM, Alec Taylor alec.tayl...@gmail.com wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Proof
http://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-794.95
-60.95 aka (-(1219/20))
On Wed, Feb 22, 2012 at 10:13 AM, Alec Taylor alec.tayl...@gmail.com wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Welcome to the world of finite-precision binary floating-point
arithmetic then! Reality bites.
On Feb 22, 1:13 pm, Alec Taylor alec.tayl...@gmail.com wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Proofhttp://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-...
-60.95 aka (-(1219/20))
Is
Alec Taylor writes:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Not by much. I'm not an expert, but my guess is that the exact value
is not representable in binary floating point, which most programming
languages use
On 2012-02-22, Alec Taylor alec.tayl...@gmail.com wrote:
Simple mathematical problem, + and - only:
1800.00-1041.00-555.74+530.74-794.95
-60.9500045
That's wrong.
Oh good. We haven't have this thread for several days.
Proof
On Wed, 22 Feb 2012 19:26:26 +0100, Christian Heimes wrote:
Python uses the platforms double precision float datatype. Floats are
almost never exact.
Well, that's not quite true. Python floats are always exact. They just
may not be exactly what you want :)
Pedantic-but-unhelpful-as-always-ly
26 matches
Mail list logo
