Re: -infinity and REPRESENT

On 2020-05-05 08:48, Anton Ertl wrote:
> On Tue, May 05, 2020 at 01:03:31AM +0200, [email protected] 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.

Good points. I see now that iForth does not handle +/-0 correctly, and
that the fpout 1.4 discussion is still relevant. When considering to be
non-standard, I'd better take that into account.

-marcel