• Re: awk not outputting in scientific notation despite %e

    From Kpop 2GM@21:1/5 to Andrew Schorr on Fri Oct 27 15:13:58 2023
    On Tuesday, May 9, 2023 at 9:03:51 AM UTC-4, Andrew Schorr wrote:
    On Monday, May 8, 2023 at 8:59:47 PM UTC-4, Ben Bacarisse wrote:
    I think it is. Where OFMT applies (in print) the text refers to the conversion that otherwise uses CONVFMT:

    "All expression arguments shall be taken as strings, being converted if necessary; this conversion shall be as described in Expressions in
    awk, with the exception that the printf format in OFMT shall be used instead of the value in CONVFMT."

    and it's the referenced text that has the integer exception with CONVFMT used for other values. Using OFMT in place of CONVFMT in that text does not remove the exception.
    I think that's right. It also says this:

    "The intent has been to specify historical practice in almost all cases."

    And I think the history is that all implementations of awk have always converted
    integral values using the equivalent of "%d", regardless of the CONVFMT or OFMT setting.

    Regards,
    Andy

    That would *nearly* be true if not for gawk + GMP's lovely behavior with parsing the decimal dot :

    gawk -Mbe 'BEGIN { OFS = RS;

    . . . . . print x = 10.^10 * 5^12 * 3, --x, "--------------",
    . . . . . . . . . . y = 10^10 * 5^12 * 3, --y, "-----------------", 2^63-1 }'

    7324218750000000000
    7324218750000000000
    --------------
    7324218750000000000
    7324218749999999999
    -----------------
    9223372036854775807

    everything about "x" and "y" are mathematically identical - both are ***supposed*** to be integers,

    but the mere presence of an extra dot (".") at the 1st "10" ( "10." instead of "10") causes gawk + GMP to treat the whole thing as double-precision floating point value instead of GMP's arbitrary precision integers.

    which can be confirmed when using the -d- flag to dump variables to /dev/stdout :

    x: 7.32421875e+18
    y: 7324218749999999999

    The same undesirable effect also occurs when the exponent is written as "10^10." instead of "10^10". but interestingly enough, if one adds a

    . . . x = int(x)

    before

    . . . . --x

    then it circumvents this annoyance and returns a properly decremented integer value instead

    — The 4Chan Teller

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)