Re^3: Weird excel parsing problem

Not always. I found a bug trying to deploy JSON::XS on AIX 7 where '5e1' was deciphered by JSON::XS, and came out to 50.0000000007 or something.

I don't think you found a bug. See http://en.wikipedia.org/wiki/Scientific_notation#E_notation for why 5e1 is just another number (that is read as 5.0E+1 or 5.0*10¹), and perlfaq4 or What Every Computer Scientist Should Know About Floating-Point Arithmetic for why you don't get just 50 as a result and why using == and != with floats just does not work.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^3: Weird excel parsing problem

Replies are listed 'Best First'.
Re^4: Weird excel parsing problem by Tanktalus (Canon) on Nov 06, 2012 at 13:59 UTC
Except that, as you point out, we're referring to 5.0, and that is an exact number in binary, not like, say, 5.1. All of the numbers involved in that equation are representable exactly, even in floating point. On all platforms other than AIX7, 5e1 is deciphered to be 50, exactly. And IBM has a published bug report on this (they only publish bugs they accept and either have fixed or are planning to fix or acknowledge are bugs but cannot be fixed - rejected bug reports are not published). So I'm pretty confident it's an actual bug :-) But what you point out is true as a generality, which is why I was pointing out that == doesn't always work, depending on what you're comparing. Works best for pure integers, not so good in general for floating point (but if you have numbers that can be represented exactly, barring bugs like the above, it should work). So ++ for pointing out the part I should have made explicit as to why == doesn't always work.	[reply]

Replies are listed 'Best First'.

Re^4: Weird excel parsing problem
by Tanktalus (Canon) on Nov 06, 2012 at 13:59 UTC

Except that, as you point out, we're referring to 5.0, and that is an exact number in binary, not like, say, 5.1. All of the numbers involved in that equation are representable exactly, even in floating point. On all platforms other than AIX7, 5e1 is deciphered to be 50, exactly. And IBM has a published bug report on this (they only publish bugs they accept and either have fixed or are planning to fix or acknowledge are bugs but cannot be fixed - rejected bug reports are not published). So I'm pretty confident it's an actual bug :-)

But what you point out is true as a generality, which is why I was pointing out that == doesn't always work, depending on what you're comparing. Works best for pure integers, not so good in general for floating point (but if you have numbers that can be represented exactly, barring bugs like the above, it should work). So ++ for pointing out the part I should have made explicit as to why == doesn't always work.

[reply]