[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] Invalid result when converting to hex literal
From: |
arnold |
Subject: |
Re: [bug-gawk] Invalid result when converting to hex literal |
Date: |
Wed, 21 Mar 2018 01:37:49 -0600 |
User-agent: |
Heirloom mailx 12.4 7/29/08 |
Hi Nelson.
"Nelson H. F. Beebe" <address@hidden> wrote:
> However, hexadecimal floating-point constants were introduced into C99
> for an extremely important reason: they allow exact specification of
> floating-point bit patterns that could not be reliably obtained with
> either decimal input, or with C library function calls, or with
> recognizable rational numbers, because there is no guarantee that I/O
> base conversions, and library functions, and floating-point division,
> always produce correctly-rounded results.
That's all fine and good. But awk is not C, nor does it aim to be.
I would further suggest that awk is not a language to use for serious
numerical work in any case.
> Hexadecimal floating point is not supported (unless you also use
> '--non-decimal-data', which is _not_ recommended).
This is talking about *DATA*, not constants in the source code.
$ echo 0x2A | gawk '{ print $1 + 0 }'
0
$ echo 0x2A | gawk --non-decimal-data '{ print $1 + 0 }'
42
> Let us try the latter suggestion with gawk-4.2.1:
>
> % gawk --non-decimal-data 'BEGIN {print 0x1p5}'
> 1
You are assuming that gawk knows how to parse C99 floating point
hex constants. It doesn't. It only understands C89 format hex values.
Even with --non-decimal-data, gawk does not currently understand
C99 floating point hex values, since it does not use strtod for
this conversion. Changing this is something that I may consider,
but it would be only in the context of the --non-decimal-data option.
> At least the three major awk implementations behave consistently: they
> all ignore nonnumeric suffixes without raising an error, and silently
> skip to the next recognizable lexical token:
>
> % gawk 'BEGIN {print 12345foolish}'
> 12345
Here you are way out in left field. This is printing the string concatenation
of 12345 with the value of variable named "foolish". Since variables are
auto-initialized to the null string, all you're getting is the 12345. This
is easy to prove:
$ gawk -v foolish=fooled 'BEGIN { print 12345foolish }'
12345fooled
In short, gawk purposely ignores C99 hex floating point.
It may be time to reconsider this decision, but then again, it may not.
Thanks,
Arnold
- Re: [bug-gawk] Invalid result when converting to hex literal, (continued)
- Re: [bug-gawk] Invalid result when converting to hex literal, arnold, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, arnold, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, Nelson H. F. Beebe, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, Steven Penny, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, arnold, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, Steven Penny, 2018/03/20
- Re: [bug-gawk] Invalid result when converting to hex literal, arnold, 2018/03/21
- Re: [bug-gawk] Invalid result when converting to hex literal, Nelson H. F. Beebe, 2018/03/21
- Re: [bug-gawk] Invalid result when converting to hex literal, arnold, 2018/03/22
- Re: [bug-gawk] Invalid result when converting to hex literal, Arnold Robbins, 2018/03/22
- Re: [bug-gawk] Invalid result when converting to hex literal,
arnold <=