Re^2: Math::BigFloat and zero

Yes, that's exactly what it does.

What I'm trying to work out is why it stores 0 as '0E1' if it stringifies to '0'? DBI functions return zero as '0E0' so that it becomes 'true' in a boolean context, but if you evaluate a Math::BigFloat zero in a boolean context it becomes 'false'. So why not just store it internally as '0'? What is gained by storing as '0E1'?

My second question is why use '0E1' instead of the more usual '0E0'? They both become 0 in a numerical context and stringify to '0'.

-- iakobski

Comment on Re^2: Math::BigFloat and zero

Replies are listed 'Best First'.
Re^3: Math::BigFloat and zero by JavaFan (Canon) on Sep 24, 2010 at 13:23 UTC
Well, Math::BigFloat is about floating point numbers. Not about integers. So, to me it makes a lot of sense to store it as a significant/exponent pair, and not a plain integer. Note that the internal representation is not `"0E1"`. The internal representation is: `{ _e => 1, _es => '+', _m => [0], sign => '+', }` [download] which corresponds to 0E1.	[reply] [d/l] [select]
Re^3: Math::BigFloat and zero by Anonymous Monk on Sep 24, 2010 at 06:56 UTC
Did you try looking up Knuth's reasoning?	[reply]
Re^4: Math::BigFloat and zero by iakobski (Pilgrim) on Sep 24, 2010 at 12:42 UTC
Yes, and I can't find it. My best guess is that Knuth discussed 0⁰ being less securely defined than 0¹, and possibly the author of Math::BigFloat was making a joke on this, but 0E0 is not related to 0⁰ and is very much defined. -- iakobski	[reply]
Re^5: Math::BigFloat and zero by JavaFan (Canon) on Sep 24, 2010 at 13:29 UTC
"Less securely defined"? It's typically considered to be undefined, considering that: lim x->0 x⁰ = 1 lim x->0 0^x = 0 But of course, any model is free to define 0⁰ to be anything it wants. I prefer 0⁰ == 7. After all 0⁰ == 7 <==> 0 * 0⁰ == 7 * 0 <==> 0¹ == 0 <==> 0 == 0	[reply]