bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect output with OFMT="%.15e"


From: arnold
Subject: Re: Incorrect output with OFMT="%.15e"
Date: Tue, 09 May 2023 01:36:45 -0600
User-agent: Heirloom mailx 12.5 7/5/10

Hi.

The manual is frozen for the upcoming 5.2.2 release, but I will add
a paragraph in the OFMT section (which is super old) pointing at the
section that discusses CONVFMT; this will be there going forward.

In any case, both OFMT and CONVFMT convert integral values as integers.
All awks work that way (or they should!).

This makes sense for most use cases. For example, foo[1] is really
foo["1"]; a %e conversion in CONVFMT would really cause confusion if
the integral conversion rule were not in place.

I don't have POSIX chapter and verse handy, nor the time to go looking
right now, but I suspect that it says something like OFMT works the
same as CONVFMT and is used for the print statement, which would cover
the integral conversion rule.

Thanks,

Arnold

"Neil R. Ormos" <ormos-gnulists17@ormos.org> wrote:

> Andrew J. Schorr wrote:
> > Keith Thompson wrote:
>
> >> Ah, yes, I agree that it's not a bug, and using
> >> printf rather than OFMT is the right thing to
> >> do (if you want scientific notation) and not a
> >> workaround.
>
> > It is also discussed here in the gawk manual:
>
> > https://www.gnu.org/software/gawk/manual/html_node/Strings-And-Numbers.html
>
> > | As a special case, if a number is an integer,
> > | then the result of converting it to a string
> > | is always an integer, no matter what the value
> > | of CONVFMT may be.
>
> > You may ask why OFMT and CONVFMT are handled the
> > same way. I can think of 3 reasons: [...]
>
> The manual could be improved by explicitly mentioning the special-case 
> integer-value conversion behavior of OFMT, e.g., in section 5.4, instead of 
> expecting users to infer that OFMT has special-case behavior that parallels 
> the documented behavior of CONVFMT.
>
> The manual states that "CONVFMT was introduced in order to separate the 
> semantics of conversion from the semantics of printing," (6.1.4.1).  Most 
> users won't be aware of the parallelism between CONVFMT and OFMT, and the 
> "separate the semantics of conversion" phrase teaches away from the inference 
> that they exhibit parallel behavior.  
>
> In addition, perhaps the parallelism should be explicitly mentioned so users 
> know that if they want to understand how OFMT works generally, they'll also 
> need to read about CONVFMT.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]