Thanks for the report - a nice clear example that even a Haggis can grasp.
I'm guessing that the problem lies in primFloatDecode
which is defined by the C function of the same name in builtin.c.
A simple test would be to look at the result of primFloatDecode (-1)
On an x86 box, I get (-8388608,-23). The numbers might be different on
other architectures but their magnitude and sign should be about the same.
But, this problem isn't showing up on my Linux box, can someone with
a Mac and a debugger have a look, please?
I'm highly suspicious of the call to frexp in primFloatDecode - the
documentation I have available suggests that frexp(-1) might not be
very well defined.
Alastair
> [EMAIL PROTECTED] reports the following problem.
>
> Version: 1.4 "Ported to Macintosh by Hans Aberg, compiled Jan 19 1998"
> OS: Mac OS 8.1 on a PowerPC 8500/120 with 256Mb
> compiler:
> configuration:
> Expected behaviour:
> In Complex, sqrt (-1::Complex Float) should be 0:+1
> Observed behaviour:
> Instead, it's 0:+sqrt 0.5 .
>
> The cause seems to be that the significand of negative floats
> is bogus.
> Transcript:
> Prelude> :l Complex
> Reading file ":lib:Complex.hs":
>
> Hugs session for:
> :lib:Prelude.hs
> :lib:Complex.hs
> Complex> sqrt (-1::Complex Float)
> 0.0 :+ 0.707107
> Complex> significand (-2)
> -0.0
