[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] Overflow to Infinity
From: |
Andrew J. Schorr |
Subject: |
Re: [bug-gawk] Overflow to Infinity |
Date: |
Fri, 13 Jul 2018 11:25:01 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jul 13, 2018 at 03:07:57PM +0300, Eli Zaretskii wrote:
> > From: Arnold Robbins <address@hidden>
> > Date: Fri, 13 Jul 2018 14:03:26 +0300
> > Cc: address@hidden, address@hidden
> >
> > I am working on changing comparison (==, !=, etc.) such that for NaN
> > and INF values gawk will behave like C. I hope this will be done
> > within another week or so. This will NOT affect array sorting, whereby
> > NaN values will continue to compare equal to each other.
>
> So the behavior will not really be like C, where NaN == NaN yields
> zero, right? I think this part of the C behavior makes no sense in
> Awk.
I must confess that I have never grappled with this issue before. I generally
try to avoid calculations that generate NaN or Inf. But I really do not
see why gawk should treat NaN differently than C does. Why would we want
to deviate from the standard NaN and Inf handling? I guess part of the problem
is in this logic in node.c:
int
cmp_awknums(const NODE *t1, const NODE *t2)
{
/*
* This routine is also used to sort numeric array indices or values.
* For the purposes of sorting, NaN is considered greater than
* any other value, and all NaN values are considered equivalent and
equal.
* This isn't in compliance with IEEE standard, but compliance w.r.t.
NaN
* comparison at the awk level is a different issue, and needs to be
dealt
* with in the interpreter for each opcode seperately.
*/
if (isnan(t1->numbr))
return ! isnan(t2->numbr);
if (isnan(t2->numbr))
return -1;
/* don't subtract, in case one or both are infinite */
if (t1->numbr == t2->numbr)
return 0;
if (t1->numbr < t2->numbr)
return -1;
return 1;
}
The obvious fix seems to be:
int
cmp_awknums(const NODE *t1, const NODE *t2)
{
return (t1->numbr == t2->numbr) ? 0 :
((t1->numbr < t2->numbr) ? -1 : 1);
}
But this seems to be more complicated than I think based on the comment
about interpreter opcodes...
Regards,
Andy
- Re: [bug-gawk] Overflow to Infinity, (continued)
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity, arnold, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/17
- Re: [bug-gawk] Overflow to Infinity, arnold, 2018/07/19
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/19
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/21
- Re: [bug-gawk] Overflow to Infinity, Andrew J. Schorr, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity, Andrew J. Schorr, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity, Eli Zaretskii, 2018/07/16
- Re: [bug-gawk] Overflow to Infinity,
Andrew J. Schorr <=