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.
Thi
On 02/27/2012 10:28 AM, Ethan Furman wrote:
> jmfauth wrote:
>> On 25 fév, 23:51, Steven D'Aprano > +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'
>>>
jmfauth wrote:
On 25 fév, 23:51, Steven D'Aprano 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
What's your point? I'm afraid my cr
On 02/27/2012 08:02 AM, Grant Edwards wrote:
> On 2012-02-27, Steven D'Aprano 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 peop
On 2012-02-27, Steven D'Aprano 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 about
>> floating-point arithme
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.
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.010
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
ab
On 25 fév, 23:51, Steven D'Aprano 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
>
> What's
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 i
On Sat, Feb 25, 2012 at 2:08 PM, Tim Wintle 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 all
> > real numb
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
>>> (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 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 de
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
> 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 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-l
On 2012-02-22, Alec Taylor 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
> http://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.
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
langua
On Feb 22, 1:13 pm, Alec Taylor 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 there a reas
On Wed, Feb 22, 2012 at 10:13 AM, Alec Taylor 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.
> Proof
> http://ww
On Feb 22, 2012 1:16 PM, "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
On Wed, Feb 22, 2012 at 11:13 AM, 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))
>
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
>
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 i
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?
26 matches
Mail list logo
