On Tue, May 05, 2020 at 01:03:31AM +0200, address@hidden wrote:
On 2020-05-04 17:24, Anton Ertl wrote:
> One issue is how to deal with -infinity (e.g., the result of -1e 0e f/).
> Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive),
> f2=0 (not valid); other libc implementations might lead to different
> results.
>
> gforth 0.7.9_20200423 uses an ecvt_r supplied by us and produces
> "-inf" and f1=-1 (negative), f2=0 (not valid); the new REPRESENT
> currently works in the same way (except that it gives you "-infinity",
> space permitting).
>
> In both systems F. and FS. outputs -in.
>
> iForth behaves like gforth 0.7.2.
>
> VFX produces "Inf" and f1=-1, f2=0.
>
> The VFX behaviour looks like the most sensible one to me, but it might
> affect code that uses REPRESENT; we can change our own code
> accordingly, but what about your code? Do you have code that uses
> REPRESENT and that has been designed for a specific behaviour when
> getting -infinity?
( Bernd clarified f1 and f2. )
> VFX produces "Inf" and f1=-1, f2=0.
I think I will fix iForth (in due time) to give "-INF", f1=-1 f2=-1.
It does not make sense to me to claim f2=0 when the item has a sign
and
gives valid output for many operations.
I think that putting the sign in f1, not in the string is most
appropriate, because that's the same as for finite numbers (-1e
produces "10..." and f1=-1).
As for f2, with IEEE arithmetic there is no number that's strictly
invalid; IEEE 754 defines a meaning for every bit pattern. So what
should we return as f2?
1) Always return -1? That's not useful, and contrary to existing
practice.
2) Return -1 for finite and infinite numbers, and 0 for NaNs. That's
arguable, but contrary to existing practice. Moreover, what would be
the use of this behaviour?
3) Return -1 for finite numbers, and 0 for infinities and NaNs.
That's existing practice, and is useful for indicating that the that
the string result consists of digits and that the n (exponent) result
of REPRESENT is actually meaningful.