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.)

On 17.03.2023 12:20, Kenny McCormack wrote:
> 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?

Not that I know of, but I seem to recall that such an awk-function
can be found in the GNU Awk manual.

> (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?

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

gazelle@shell.xmission.com (Kenny McCormack) writes:

> 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?

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.

On 17.03.2023 16:23, Janis Papanagnou wrote:
>
> [...] 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

On 2023-03-17, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> 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.

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.

> 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?

Yes?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-03-17, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 17.03.2023 12:20, Kenny McCormack wrote:
>> 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?
>
> 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?

> 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: @Kazinator@mstdn.ca

In article <20230317210107.144@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
....
>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.

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.

On 18.03.2023 05:14, Kaz Kylheku wrote:
> On 2023-03-17, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 17.03.2023 12:20, Kenny McCormack wrote:
>>> 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?
>>
>> 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

On 3/17/23 16:23, Janis Papanagnou wrote:

> 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 |
+-------------------------------------------------------------------+