Numerics question: reading floating point constants
ducasse at iam.unibe.ch
Sun Apr 9 07:34:02 UTC 2006
I knew you much stronger on your statements :) so why would not it be
Do you imply that we could have an implementation justification of
this ad-hoc behavior in reading
float? I'm puzzled because reading seems to me the only easy things
with floats :)
> This post is one for the numerics fraction. I was just in the
> process of transcribing some interesting numerical code from C to
> Squeak while I was running into an issue with floating point
> constants. The code that I have has constants like here:
> pio2_2 = 6.07710050630396597660e-11, /* 0x3DD0B461, 0x1A600000 */
> but naively transcribing this into, e.g.,
> pio22 := 6.07710050630396597660e-11.
> turned out to get some of the expected results wrong. Why? Because
> the bit pattern is different, e.g., what we get is this:
> 6.07710050630396597660e-11 hex => '3DD0B4611A5FFFFF'
> Notice how the last hex digits are different.
> My question here is the following: While I can understand why
> *printing* might give different results based on the algorithm
> chosen (e.g., what amount of error do we allow when printing
> floating point numbers etc) is it to be expected that *reading* has
> similar properties? In particular considering that, e.g.,
> (607710050630396597660 * 1.0e-31) hex => '3DD0B4611A600000'
> gives the "correct" bit pattern makes me think that there might be
> something broken in our way of reading floating point numbers.
> Obviously, in a case like mine the best way to work around this
> problem is to construct the floats from the bit patterns directly
> but I can't stop but wonder what the impact of a subtle bug like
> this might be on code which does *not* include the hex denotations
> for the relevant bit patterns.
> So. Is this a bug?
More information about the Squeak-dev