Mail Archives: djgpp-workers/2002/03/03/11:43:14
> From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> Date: Sun, 3 Mar 2002 15:31:04 +0100 (MET)
>
> asinf has a lot of inaccurate answers in bit 33.
>
> atan2f has one inaccurate answer (ia, my abbr.) in bit 33.
>
> gamma has two ias in bits 58 and 61.
>
> gammaf has three ias, two in bit 33 and one in bit 31.
>
> j0 has one ia in bit 61.
>
> j0f has a lot of ias; mostly in bit 33, one in bit 31.
>
> j1 has two ias, one bit 60 and one in 61.
>
> j1f has a lot of ias in bits 32 and 33.
>
> jn has a lot of ias in bits 59-61.
>
> jnf has a lot of ias in bits 29-33.
>
> log1p has six ias in bit 61.
These are not serious problems, but what I miss is the differences
against standard.results. Does the new compile only add new
inaccuracies, or does it add some and remove others?
> log2 has two in bit 12 and one in bit 0!?
What results are those? Are they finite or Inf/NaN?
> log2 also has errno wrong-
What value of errno? If log2 is documented to produce that value,
it's okay.
> sqrt has two in bit 0!?
That's a sign bit? A NaN, perhaps? (Our NaN has its sign bit set.)
> y0f has a lot of ias in bit 33.
>
> y1 has two in bit 61 and one in 59.
>
> y1f has a lot of ias in bits 29-33.
>
> yn has a lot of ias in bits 59-61.
>
> ynf has a lot of ias in bits 29-33.
These are okay, unless the new compile adds much more new
inaccuracies.
> fpsetroundtoi/fpgetroundtoi has one ia: 00000000 should be 00000001.
This is a known limitation of emulations of these functiosn I threw
together to get the test suite to run. I think you will see the same
in standard.results.
- Raw text -