Discussion:
Rounding question (gawk)
(too old to reply)
Kenny McCormack
2023-03-17 11:20:51 UTC
Permalink
Note: Both of these questions are in the "I think it is right, but am
asking to make sure" category.

I have a GAWK program that contains the following construct:

strftime("%T",($14+$15)/100,1)

which is printed out. Now, $14 and $15 are (non-negative) integer numbers
of hundredths of a second. So, you add them together and divide by 100 to
get a number of seconds, which is then printed out via strftime. I've
noticed, though, that this value is always truncated - e.g., if the sum is
299, what I get is just 2 seconds (i.e., 00:00:02). I think it would be
better if this value were rounded instead of truncated.

So, my first question is: Is there any kind of rounding function in GAWK?
(I think there is not; the only references to "round" I could find in the
man page seem to do with MPFR stuff, which I'd rather not use for this
purpose).

Second, is it enough to just add 50 before doing the division? I.e., change
it to:

strftime("%T",($14+$15+50)/100,1)

Would it be that easy?
--
"If God wanted us to believe in him, he'd exist."

(Linda Smith on "10 Funniest Londoners", TimeOut, 23rd June, 2005.)
Janis Papanagnou
2023-03-17 15:23:50 UTC
Permalink
Post by Kenny McCormack
Note: Both of these questions are in the "I think it is right, but am
asking to make sure" category.
strftime("%T",($14+$15)/100,1)
which is printed out. Now, $14 and $15 are (non-negative) integer numbers
of hundredths of a second. So, you add them together and divide by 100 to
get a number of seconds, which is then printed out via strftime. I've
noticed, though, that this value is always truncated - e.g., if the sum is
299, what I get is just 2 seconds (i.e., 00:00:02). I think it would be
better if this value were rounded instead of truncated.
So, my first question is: Is there any kind of rounding function in GAWK?
Not that I know of, but I seem to recall that such an awk-function
can be found in the GNU Awk manual.
Post by Kenny McCormack
(I think there is not; the only references to "round" I could find in the
man page seem to do with MPFR stuff, which I'd rather not use for this
purpose).
Second, is it enough to just add 50 before doing the division? I.e., change
strftime("%T",($14+$15+50)/100,1)
Would it be that easy?
That depends on your (rounding-)requirements. Your approach is the
simple "always upwards rounding at .5", other applications may want
to round up or down depending on the preceding digit. (In the GNU
Awk manual there's a chapter "Rounding Numbers" that explains it a
bit, and I think in the know (old) paper "What scientists should
know about FP numbers" (or a similar sounding title) there's yet
more details about rounding strategies.)

Janis
Janis Papanagnou
2023-03-18 03:07:20 UTC
Permalink
[...] and I think in the known (old) paper "What scientists should
know about FP numbers" (or a similar sounding title) there's yet
more details about rounding strategies.)
Exact title: "What Every Computer Scientist Should Know About
Floating-Point Arithmetic". There are several PDF formats, e.g.
https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf
https://docs.oracle.com/cd/E19957-01/800-7895/800-7895.pdf

Janis
Kaz Kylheku
2023-03-18 04:14:22 UTC
Permalink
Post by Janis Papanagnou
Post by Kenny McCormack
Second, is it enough to just add 50 before doing the division? I.e., change
strftime("%T",($14+$15+50)/100,1)
Would it be that easy?
That depends on your (rounding-)requirements. Your approach is the
simple "always upwards rounding at .5", other applications may want
to round up or down depending on the preceding digit. (In the GNU
I think, fancy decimal rounding rules are mainly for money?
Post by Janis Papanagnou
Awk manual there's a chapter "Rounding Numbers" that explains it a
bit, and I think in the know (old) paper "What scientists should
know about FP numbers" (or a similar sounding title) there's yet
more details about rounding strategies.)
That's for the floating point operations themselves: how to determine
the last bit of the mantissa. In IEEE 754, a bunch of rounding
strategies are defined. C99 has a function to set that up, fesetround,
whose argument values are in this domain:

0 Rounding is toward 0.

1 Rounding is toward nearest number.

2 Rounding is toward positive infinity.

3 Rounding is toward negative infinity.

This is not directly related to decimal rounding concepts like 5 goes up or
down to whichever number is event ("banker's rounding").
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Janis Papanagnou
2023-03-18 05:25:48 UTC
Permalink
Post by Kaz Kylheku
Post by Janis Papanagnou
Post by Kenny McCormack
Second, is it enough to just add 50 before doing the division? I.e., change
strftime("%T",($14+$15+50)/100,1)
Would it be that easy?
That depends on your (rounding-)requirements. Your approach is the
simple "always upwards rounding at .5", other applications may want
to round up or down depending on the preceding digit. (In the GNU
I think, fancy decimal rounding rules are mainly for money?
Given that there had been hacks in the past where sub-cent amounts
in financial transactions had been accumulated on separate fraud
accounts we might get the impression that rounding applications is
least for money. ;-)

My thought where it matters would have been in numerical math, e.g.
in hydrodynamic and/or chaotic systems where rounding accumulations
would matter most.

Anyway, I do most of my computation in non-FP, so I am not too much
concerned, but physicists may be.

Janis
tTh
2023-03-18 12:33:52 UTC
Permalink
Post by Janis Papanagnou
bit, and I think in the know (old) paper "What scientists should
know about FP numbers" (or a similar sounding title) there's yet
more details about rounding strategies.)
https://dl.acm.org/doi/pdf/10.1145/103162.103163
--
+-------------------------------------------------------------------+
| https://danstonchat.com/1138.html |
+-------------------------------------------------------------------+
Ben Bacarisse
2023-03-17 15:51:15 UTC
Permalink
Post by Kenny McCormack
Second, is it enough to just add 50 before doing the division? I.e., change
strftime("%T",($14+$15+50)/100,1)
Would it be that easy?
My only worry would be that you rely on something not explicitly
documented -- that strftime will truncate the value it receives. If
GAWK's strftime "shim" decides to be "helpful" and round the floating
value, your results will be off again. Seems very unlikely, but since
your code made me go and check if that was guaranteed, I would want to
assure future readers (such as myself) by making it explicit:

strftime("%T", int(($14+$15+50)/100), 1)
--
Ben.
Kaz Kylheku
2023-03-18 04:03:52 UTC
Permalink
Post by Kenny McCormack
Note: Both of these questions are in the "I think it is right, but am
asking to make sure" category.
strftime("%T",($14+$15)/100,1)
which is printed out. Now, $14 and $15 are (non-negative) integer numbers
of hundredths of a second. So, you add them together and divide by 100 to
get a number of seconds, which is then printed out via strftime. I've
noticed, though, that this value is always truncated - e.g., if the sum is
299, what I get is just 2 seconds (i.e., 00:00:02). I think it would be
better if this value were rounded instead of truncated.
You could call strftime to get 00:00:02 and then stick on that value %
100 as a two-digit hundredths of a second:

00:00:02.99

I mean, if hundredths of a second, and their rounding, matter in the
program, maybe the requirements can be stretched to allow them to be
retained in the output.
Post by Kenny McCormack
Second, is it enough to just add 50 before doing the division? I.e., change
strftime("%T",($14+$15+50)/100,1)
Would it be that easy?
Yes?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Kenny McCormack
2023-03-18 04:21:07 UTC
Permalink
In article <***@kylheku.com>,
Kaz Kylheku <864-117-***@kylheku.com> wrote:
...
Post by Kaz Kylheku
You could call strftime to get 00:00:02 and then stick on that value %
00:00:02.99
I mean, if hundredths of a second, and their rounding, matter in the
program, maybe the requirements can be stretched to allow them to be
retained in the output.
I actually kinda like that. Interesting idea!

Note, FWIW, that hundredths actually aren't necessary or significant
(although it could be made so, as you suggest). It is just that that is
the format in which the data is stored - i.e., how it comes to me.
--
There's nothing more American than demanding to carry an AR-15 to
"protect yourself" but refusing to wear a mask to protect everyone else.
Loading...