For example:

f(1.20000) => 1.2
f(100) => 100
f(1.0234) => 1.0234
f(123.00) => 123

How would you implement such a function as f in bc?

In comp.unix.shell, Oğuz <oguzismailuysal@gmail.com> wrote:
> For example:
>
> f(1.20000) => 1.2
> f(100) => 100
> f(1.0234) => 1.0234
> f(123.00) => 123
>
> How would you implement such a function as f in bc?

Who's to say 1.2 is more accurate than 1.20000? If I see something
specified has 1.20000 meters, than I'll expect that it is not 1.20010
meters. If I see something specified as 1.2 meters, than 1.20010 is very
much within spec.

For your example of "just drop zeros at the end of a decimal sequence",
I'd do that in sed or something.

sed -e 's/\([(.][0-9]*[1-9]\)0*$/\1/; s/[.]0*$//'

Elijah
------
but maybe you want to keep the decimal place, eg 1.0000 => 1.

Eli the Bearded <*@eli.users.panix.com> writes:

> In comp.unix.shell, Oğuz <oguzismailuysal@gmail.com> wrote:
>> For example:
>>
>> f(1.20000) => 1.2
>> f(100) => 100
>> f(1.0234) => 1.0234
>> f(123.00) => 123
>>
>> How would you implement such a function as f in bc?
>
> Who's to say 1.2 is more accurate than 1.20000? If I see something
> specified has 1.20000 meters, than I'll expect that it is not 1.20010
> meters. If I see something specified as 1.2 meters, than 1.20010 is very
> much within spec.

I have to agree, the number of decimals can be an indication of
accuracy. I use bc a lot and for what I'm doing, I always want 2
decimals.

In my ~/.bc file I have:

scale=2

--
Dan Espen

Dan Espen <dan1espen@gmail.com> writes:

> Eli the Bearded <*@eli.users.panix.com> writes:

>> Who's to say 1.2 is more accurate than 1.20000? If I see something
>> specified has 1.20000 meters, than I'll expect that it is not 1.20010
>> meters. If I see something specified as 1.2 meters, than 1.20010 is very
>> much within spec.
>
> I have to agree, the number of decimals can be an indication of
> accuracy. I use bc a lot and for what I'm doing, I always want 2
> decimals.
>
> In my ~/.bc file I have:
>
> scale=2

That may do what you want, but I think it's worth pointing out for a
wider audience that bc does not round into the last digit, but truncates
to it. Also, the setting is not a display option for numbers stored
internally with greater precision, but governs the precision used for
some arithmetic results. For example

scale=2; 1.0099+0; 1.0099*1; 1.0099/1

produces

1.0099
1.0099
1.00

which is unlikely to be what anyone wants!

--
Ben.

On Monday, September 13, 2021 at 12:49:27 AM UTC+3, Eli the Bearded wrote:
> In comp.unix.shell, Oğuz <oguzism...@gmail.com> wrote:
> > For example:
> >
> > f(1.20000) => 1.2
> > f(100) => 100
> > f(1.0234) => 1.0234
> > f(123.00) => 123
> >
> > How would you implement such a function as f in bc?
> Who's to say 1.2 is more accurate than 1.20000? If I see something
> specified has 1.20000 meters, than I'll expect that it is not 1.20010
> meters. If I see something specified as 1.2 meters, than 1.20010 is very
> much within spec.

I didn't think about this. Sigh, now it's got more complicated.

Say, you're converting 1.323 days to seconds, wouldn't you expect the result to be 114307.2 seconds? Wouldn't the trailing zeros in 114307.200 be redundant?

For context, I'm writing a shell script that accepts inputs like ``1d2h3m4.5s'' (one day, two hours, three minutes, and four point five seconds) and converts them to seconds for internal computations; and the user may request that the result of this conversion be printed immediately. Right now it doesn't allow a decimal point in days, hours, and minutes fields; but I've been considering allowing such inputs as ``1.323d'' (one point three twenty-three days) after I figure out how they should look after conversion.

>
> For your example of "just drop zeros at the end of a decimal sequence",
> I'd do that in sed or something.
>
> sed -e 's/\([(.][0-9]*[1-9]\)0*$/\1/; s/[.]0*$//'
>
> Elijah
> ------
> but maybe you want to keep the decimal place, eg 1.0000 => 1.

Oğuz <oguzismailuysal@gmail.com> writes:
> On Monday, September 13, 2021 at 12:49:27 AM UTC+3, Eli the Bearded wrote:
>> In comp.unix.shell, Oğuz <oguzism...@gmail.com> wrote:
>> > For example:
>> >
>> > f(1.20000) => 1.2
>> > f(100) => 100
>> > f(1.0234) => 1.0234
>> > f(123.00) => 123
>> >
>> > How would you implement such a function as f in bc?
>> Who's to say 1.2 is more accurate than 1.20000? If I see something
>> specified has 1.20000 meters, than I'll expect that it is not 1.20010
>> meters. If I see something specified as 1.2 meters, than 1.20010 is very
>> much within spec.
>
> I didn't think about this. Sigh, now it's got more complicated.

You didn't initially say that you wanted the result to express a
meaningful precision.

> Say, you're converting 1.323 days to seconds, wouldn't you expect the
> result to be 114307.2 seconds? Wouldn't the trailing zeros in
> 114307.200 be redundant?
>
> For context, I'm writing a shell script that accepts inputs like
> ``1d2h3m4.5s'' (one day, two hours, three minutes, and four point five
> seconds) and converts them to seconds for internal computations; and
> the user may request that the result of this conversion be printed
> immediately. Right now it doesn't allow a decimal point in days,
> hours, and minutes fields; but I've been considering allowing such
> inputs as ``1.323d'' (one point three twenty-three days) after I
> figure out how they should look after conversion.

One approach that might make sense is to allow a non-integer value only
for the last field, so that for example "1.5d" is allowed by "1.5d1h" is
not.

Or you could allow real values for all fields, but I wouldn't expect
that to be used very often.

If your goal is to produce a number of seconds with a sensible number of
decimal places based on the input, you could consider each field to
specify a precision. A field of "1.323d" would specify a precision of
0.001 day (86.4 seconds). Whichever field specifies the greatest
precision could control the precision of the result. For example,
"3.1415926535d" would represent a precision of 8.64 microseconds, so the
result might be expressed as 271433.60526 seconds (if I've calculated it
correctly).

But consider whether users are going to expect "3.14d" and "3.140d" to
have different meanings.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 13/09/2021 04:32, Oğuz wrote:
>[...] Sigh, now it's got more complicated.
> Say, you're converting 1.323 days to seconds, wouldn't you expect the
> result to be 114307.2 seconds? Wouldn't the trailing zeros in
> 114307.200 be redundant?
> For context, I'm writing a shell script that accepts inputs like
> ``1d2h3m4.5s'' [...].

I think the answer is probably to use interval arithmetic,
of which this is a fairly simple example as you're [presumably] not
multiplying times together [to get square hours, or whatever!] nor
dividing them. So "1.323d" means "between 1.3225 and 1.3235 days"
"1d2h3m4.5s" means "between 1d2h3m4.45s and 1d2h3m4.55s" and
"1.2d 3.4h" means "between 1.15d 3.35h and 1.25d 3.45h". Convert
to seconds, or microseconds, or whatever, and, when printing,
print the lower and upper times as far as they agree; anything
after that is "noise". Details left as an exercise.

Note that for your "1.323d" example, the upper and lower
times differ by over a minute, so no, it shouldn't be printed out
with even one decimal place of seconds. For that, the user should
perhaps have specified "1.323000d".

[Interval arithmetic is commonly implemented in symbolic
algebra packages; whether it's available in any standard shell
commands or facilities, I don't know and haven't investigated.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Goodban

On Monday, September 13, 2021 at 12:23:04 PM UTC+3, Andy Walker wrote:
> On 13/09/2021 04:32, Oğuz wrote:
> >[...] Sigh, now it's got more complicated.
> > Say, you're converting 1.323 days to seconds, wouldn't you expect the
> > result to be 114307.2 seconds? Wouldn't the trailing zeros in
> > 114307.200 be redundant?
> > For context, I'm writing a shell script that accepts inputs like
> > ``1d2h3m4.5s'' [...].
>
> I think the answer is probably to use interval arithmetic,
> of which this is a fairly simple example as you're [presumably] not
> multiplying times together [to get square hours, or whatever!] nor
> dividing them. So "1.323d" means "between 1.3225 and 1.3235 days"
> "1d2h3m4.5s" means "between 1d2h3m4.45s and 1d2h3m4.55s" and
> "1.2d 3.4h" means "between 1.15d 3.35h and 1.25d 3.45h". Convert
> to seconds, or microseconds, or whatever, and, when printing,
> print the lower and upper times as far as they agree; anything
> after that is "noise". Details left as an exercise.

This is beyond me. Besides, the script uses an arbitrary precision calculator (bc) for all computations (and users are made aware of this, assuming they actually read the manual). So, ``1.323d'' does not represent a value between any two others; it is precisely 1.323 days, no distinction is made between 1.323 and 1.3230000000000000000000 in bc. That's why I thought removing trailing zeros from the fractional portion would suffice, but then Eli's message confused me.

>
> Note that for your "1.323d" example, the upper and lower
> times differ by over a minute, so no, it shouldn't be printed out
> with even one decimal place of seconds. For that, the user should
> perhaps have specified "1.323000d".
>
> [Interval arithmetic is commonly implemented in symbolic
> algebra packages; whether it's available in any standard shell
> commands or facilities, I don't know and haven't investigated.]
>
> --
> Andy Walker, Nottingham.
> Andy's music pages: www.cuboid.me.uk/andy/Music
> Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Goodban

Oğuz <oguzismailuysal@gmail.com> writes:

> On Monday, September 13, 2021 at 12:23:04 PM UTC+3, Andy Walker wrote:
>> On 13/09/2021 04:32, Oğuz wrote:
>> >[...] Sigh, now it's got more complicated.
>> > Say, you're converting 1.323 days to seconds, wouldn't you expect the
>> > result to be 114307.2 seconds? Wouldn't the trailing zeros in
>> > 114307.200 be redundant?
>> > For context, I'm writing a shell script that accepts inputs like
>> > ``1d2h3m4.5s'' [...].
>>
>> I think the answer is probably to use interval arithmetic,
>> of which this is a fairly simple example as you're [presumably] not
>> multiplying times together [to get square hours, or whatever!] nor
>> dividing them. So "1.323d" means "between 1.3225 and 1.3235 days"
>> "1d2h3m4.5s" means "between 1d2h3m4.45s and 1d2h3m4.55s" and
>> "1.2d 3.4h" means "between 1.15d 3.35h and 1.25d 3.45h". Convert
>> to seconds, or microseconds, or whatever, and, when printing,
>> print the lower and upper times as far as they agree; anything
>> after that is "noise". Details left as an exercise.
>
> This is beyond me. Besides, the script uses an arbitrary precision
> calculator (bc) for all computations (and users are made aware of
> this, assuming they actually read the manual). So, ``1.323d'' does not
> represent a value between any two others; it is precisely 1.323 days,
> no distinction is made between 1.323 and 1.3230000000000000000000 in
> bc. That's why I thought removing trailing zeros from the fractional
> portion would suffice, but then Eli's message confused me.

It's not common to interpret decimal fractions as representing exact
quantities because this privilege some values over others. If instead
of 1.323 days the user had wanted one and a third days, there is no
simple way to write that as a decimal fraction. (Well there is: 1.(3)
but it's no widely used in computing.)

The simplest way to do exact arithmetic is as fractions. 1.323 is
exactly 1323/1000 and all the other numbers can be similarly converted.
After adjusting to get a common divisor, you can then do all the
arithmetic as integers and divide once at the end. You need to do it
this way because of what bc does with division. You will then also know
how may digits to show after the point.

But it's unlikely that this is worth the effort. Is there significant
demand from users to see fewer zeros?

--
Ben.

On Sun, 12 Sep 2021 20:32:38 -0700, Oğuz wrote:

> On Monday, September 13, 2021 at 12:49:27 AM UTC+3, Eli the Bearded wrote:
>> In comp.unix.shell, Oğuz <oguzism...@gmail.com> wrote:
>> > For example:
>> >
>> > f(1.20000) => 1.2
>> > f(100) => 100
>> > f(1.0234) => 1.0234
>> > f(123.00) => 123
>> >
>> > How would you implement such a function as f in bc?
>> Who's to say 1.2 is more accurate than 1.20000? If I see something
>> specified has 1.20000 meters, than I'll expect that it is not 1.20010
>> meters. If I see something specified as 1.2 meters, than 1.20010 is very
>> much within spec.
>
> I didn't think about this. Sigh, now it's got more complicated.
>
> Say, you're converting 1.323 days to seconds, wouldn't you expect
> the result to be 114307.2 seconds? Wouldn't the trailing zeros in
> 114307.200 be redundant?

Instead of concentrating on the insignificant trailing zeros in your
converted values, you probably should be concentrating on ensuring
that the conversion maintains the accuracy of the values being
converted.

Both 114307.2 and 114307.200 represent the same value. The discussion
regarding a preference of one expression of that value ("114307.2")
over another ("114307.200") tells me that we aren't talking about
accuracy here, but /significance/. And that is a common quandary
among scientists and engineers; so much so that they've expressed
various recommendations regarding "significant numbers".

Your original value was 1.323 days. Likely, this number wasn't meant
to represent /exactly/ 114307.2 seconds, but instead was meant to
represent some interval of at least 1.3230 days, and no more than
1.3240 days. That interval represents approximately 86.4 seconds.

So, your example of 1.323 days likely represents a value somewhere
between 114307.2 and 114393.6 seconds. And, that's if we take your
1.323 as a completely accurate value.

But wait, there's more :-)

To quote one of the many articles on "significant digits",
"The significant figures in a measurement consist of all the
certain digits in that measurement plus one uncertain or
estimated digit."
(https://chem.libretexts.org/Bookshelves/Introductory_Chemistry/Map%3A_Introductory_Chemistry_(Tro)/02%3A_Measurement_and_Problem_Solving/2.03%3A_Significant_Figures_-_Writing_Numbers_to_Reflect_Precision)

If we work with this guideline, your figure of 1.323 could
represent a value of 1.32 days with an uncertainty of 0.003
days. So, somewhere between (approximately) 1.3225 days and
1.3235 days, or between 114264 seconds and 114350.4 seconds.

I know that computers work (mostly) with precise numbers, BUT
your conversion between time measurements isn't as precise
as the computer's computation will be.

HTH

[snip]
--
Lew Pitcher
"In Skills, We Trust"

On Monday, September 13, 2021 at 4:13:32 PM UTC+3, Ben Bacarisse wrote:
> Oğuz <oguzism...@gmail.com> writes:
>
> > On Monday, September 13, 2021 at 12:23:04 PM UTC+3, Andy Walker wrote:
> >> On 13/09/2021 04:32, Oğuz wrote:
> >> >[...] Sigh, now it's got more complicated.
> >> > Say, you're converting 1.323 days to seconds, wouldn't you expect the
> >> > result to be 114307.2 seconds? Wouldn't the trailing zeros in
> >> > 114307.200 be redundant?
> >> > For context, I'm writing a shell script that accepts inputs like
> >> > ``1d2h3m4.5s'' [...].
> >>
> >> I think the answer is probably to use interval arithmetic,
> >> of which this is a fairly simple example as you're [presumably] not
> >> multiplying times together [to get square hours, or whatever!] nor
> >> dividing them. So "1.323d" means "between 1.3225 and 1.3235 days"
> >> "1d2h3m4.5s" means "between 1d2h3m4.45s and 1d2h3m4.55s" and
> >> "1.2d 3.4h" means "between 1.15d 3.35h and 1.25d 3.45h". Convert
> >> to seconds, or microseconds, or whatever, and, when printing,
> >> print the lower and upper times as far as they agree; anything
> >> after that is "noise". Details left as an exercise.
> >
> > This is beyond me. Besides, the script uses an arbitrary precision
> > calculator (bc) for all computations (and users are made aware of
> > this, assuming they actually read the manual). So, ``1.323d'' does not
> > represent a value between any two others; it is precisely 1.323 days,
> > no distinction is made between 1.323 and 1.3230000000000000000000 in
> > bc. That's why I thought removing trailing zeros from the fractional
> > portion would suffice, but then Eli's message confused me.
> It's not common to interpret decimal fractions as representing exact
> quantities because this privilege some values over others. If instead
> of 1.323 days the user had wanted one and a third days, there is no
> simple way to write that as a decimal fraction. (Well there is: 1.(3)
> but it's no widely used in computing.)

In that case the user would enter ``1d8h''. I got the point though.

>
> The simplest way to do exact arithmetic is as fractions. 1.323 is
> exactly 1323/1000 and all the other numbers can be similarly converted.
> After adjusting to get a common divisor, you can then do all the
> arithmetic as integers and divide once at the end. You need to do it
> this way because of what bc does with division. You will then also know
> how may digits to show after the point.
>
> But it's unlikely that this is worth the effort. Is there significant
> demand from users to see fewer zeros?

Oh, none yet. No demand. I thought it'd be useful, that's all.

>
> --
> Ben.

On Monday, September 13, 2021 at 5:00:52 PM UTC+3, Lew Pitcher wrote:
> On Sun, 12 Sep 2021 20:32:38 -0700, Oğuz wrote:
>
> > On Monday, September 13, 2021 at 12:49:27 AM UTC+3, Eli the Bearded wrote:
> >> In comp.unix.shell, Oğuz <oguzism...@gmail.com> wrote:
> >> > For example:
> >> >
> >> > f(1.20000) => 1.2
> >> > f(100) => 100
> >> > f(1.0234) => 1.0234
> >> > f(123.00) => 123
> >> >
> >> > How would you implement such a function as f in bc?
> >> Who's to say 1.2 is more accurate than 1.20000? If I see something
> >> specified has 1.20000 meters, than I'll expect that it is not 1.20010
> >> meters. If I see something specified as 1.2 meters, than 1.20010 is very
> >> much within spec.
> >
> > I didn't think about this. Sigh, now it's got more complicated.
> >
> > Say, you're converting 1.323 days to seconds, wouldn't you expect
> > the result to be 114307.2 seconds? Wouldn't the trailing zeros in
> > 114307.200 be redundant?
> Instead of concentrating on the insignificant trailing zeros in your
> converted values, you probably should be concentrating on ensuring
> that the conversion maintains the accuracy of the values being
> converted.
>
> Both 114307.2 and 114307.200 represent the same value. The discussion
> regarding a preference of one expression of that value ("114307.2")
> over another ("114307.200") tells me that we aren't talking about
> accuracy here, but /significance/. And that is a common quandary
> among scientists and engineers; so much so that they've expressed
> various recommendations regarding "significant numbers".
>
> Your original value was 1.323 days. Likely, this number wasn't meant
> to represent /exactly/ 114307.2 seconds, but instead was meant to
> represent some interval of at least 1.3230 days, and no more than
> 1.3240 days. That interval represents approximately 86.4 seconds.
>
> So, your example of 1.323 days likely represents a value somewhere
> between 114307.2 and 114393.6 seconds. And, that's if we take your
> 1.323 as a completely accurate value.
>
> But wait, there's more :-)
>
> To quote one of the many articles on "significant digits",
> "The significant figures in a measurement consist of all the
> certain digits in that measurement plus one uncertain or
> estimated digit."
> (https://chem.libretexts.org/Bookshelves/Introductory_Chemistry/Map%3A_Introductory_Chemistry_(Tro)/02%3A_Measurement_and_Problem_Solving/2.03%3A_Significant_Figures_-_Writing_Numbers_to_Reflect_Precision)

I'll read this when I have time, thank you.

>
> If we work with this guideline, your figure of 1.323 could
> represent a value of 1.32 days with an uncertainty of 0.003
> days. So, somewhere between (approximately) 1.3225 days and
> 1.3235 days, or between 114264 seconds and 114350.4 seconds.
>
> I know that computers work (mostly) with precise numbers, BUT
> your conversion between time measurements isn't as precise
> as the computer's computation will be.

Sounds like a good excuse to put this feature on hold :D

>
> HTH
>
> [snip]
> --
> Lew Pitcher
> "In Skills, We Trust"

On 12/09/2021 07:39 pm, Oğuz wrote:
> For example:
>
> f(1.20000) => 1.2
> f(100) => 100
> f(1.0234) => 1.0234
> f(123.00) => 123
>
> How would you implement such a function as f in bc?
>

I wouldn't use bc, just bash.

rmz ()
{ local N;
# an integer, just return value
[[ $1 == ?([-+])+([0-9]) ]] && {
echo "$1";
return
};
N="$1";
# remove trailing 0, one by one
until [ "$N" = "${N%0}" ]; do
N="${N%0}";
done;
# remove any trailing .
echo "${N%.}"
}

If you set extglob (shopt -s extglob) you could substitute the until
loop with N="${N%%+(0)}"

--
Chris Elvidge
England

On 12/09/2021 at 20.39, Oğuz wrote:
> For example:
>
> f(1.20000) => 1.2
> f(100) => 100
> f(1.0234) => 1.0234
> f(123.00) => 123
>
> How would you implement such a function as f in bc?

Consider using 'calc' instead of 'bc' for your calculations…

~ $ calc 1.20000
1.2
~ $ calc 100
100
~ $ calc 1.0234
1.0234
~ $ calc 123.00
123
~ $ calc 1.323*60*60*24
114307.2
~ $

--
mrg

In comp.unix.shell, marrgol <marrgol@address.invalid> wrote:
> Consider using 'calc' instead of 'bc' for your calculations…

Ubuntu 18.04.5: command not found
NetBSD 9.1: command not found

If you're not going to provide any more information about the program
than the name, and the post says POSIX in the subject, then shouldn't
you only be mentioning programs that are pretty standardized?

Elijah
------
knows people that could whip up an Excel formula for this but...

Eli the Bearded <*@eli.users.panix.com> writes:

> In comp.unix.shell, marrgol <marrgol@address.invalid> wrote:
>> Consider using 'calc' instead of 'bc' for your calculations…
>
> Ubuntu 18.04.5: command not found
> NetBSD 9.1: command not found
>
> If you're not going to provide any more information about the program
> than the name, and the post says POSIX in the subject, then shouldn't
> you only be mentioning programs that are pretty standardized?

Fedora not found...

sudo dnf install calc

> calc 4/7
~0.57142857142857142857

Hmm...

--
Dan Espen

In comp.unix.shell, Dan Espen <dan1espen@gmail.com> wrote:
> Fedora not found...
>
> sudo dnf install calc

There's no calc package on Ubuntu. apcalc provides a /usr/bin/calc
but I didn't try to install it, because: I have no idea if it's
the same tool, or just someone else using the same name. I mean it's
not like "calc" is an unlikely name for a calculator.

(I don't have root on this NetBSD system, so I didn't even consider
looking for a package.)

Elijah
------
would consider dc and bc to be somewhat unlikely names

Eli the Bearded <*@eli.users.panix.com> writes:
> In comp.unix.shell, Dan Espen <dan1espen@gmail.com> wrote:
>> Fedora not found...
>>
>> sudo dnf install calc
>
> There's no calc package on Ubuntu. apcalc provides a /usr/bin/calc
> but I didn't try to install it, because: I have no idea if it's
> the same tool, or just someone else using the same name. I mean it's
> not like "calc" is an unlikely name for a calculator.
>
> (I don't have root on this NetBSD system, so I didn't even consider
> looking for a package.)

There is an installable Debian and Ubuntu package named "calc". It's
not installed by default.

Previously, this package was named `apcalc' in Debian due to a name
collision. However, the previous `calc' Debian package vanished long ago,
so `apcalc' was renamed back to `calc' to match the upstream name.

Yes, it is a rather generic name (and I've just decided to rename my own
"calc" program because of this).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 13.09.2021 05:32, Oğuz wrote:
> [...]
>
> For context, I'm writing a shell script that accepts inputs like
> ``1d2h3m4.5s'' (one day, two hours, three minutes, and four point
> five seconds) and converts them to seconds for internal computations;
> and the user may request that the result of this conversion be
> printed immediately. Right now it doesn't allow a decimal point in
> days, hours, and minutes fields; but I've been considering allowing
> such inputs as ``1.323d'' (one point three twenty-three days) after I
> figure out how they should look after conversion.

Period to seconds conversions can quite easily be computed in shell.
Kornshell also allows fractional arithmetic which simplifies matters.

$ cat period
p=${1:?}
s=${p}
s=${s/[Dd]/*24*60*60+}
s=${s/[Hh]/*60*60+}
s=${s/[Mm]/*60+}
s=${s/[Ss]}
s=${s%+}
printf "%s\n" "${p}" "${s}" "$((s))"

$ ksh period 1d2h5.5m3.7s
1d2h5.5m3.7s
1*24*60*60+2*60*60+5.5*60+3.7
93933.7

We can see that all the components (no only the seconds) can also be
fractions, so that this requirement would also be covered.

(The question remains - not sure it matters in your context - how to
convert larger time entities, like 'year'; would 365.2425 days be ok?)

If you want to formalize the interface you may also want to consider
using the ISO time period syntax that starts with a 'P' and (IIRC) is
using all capitals, like in 'P1D10.33S'. (Just BTW.)

Janis

On 14/09/2021 at 01.40, Eli the Bearded wrote:
>> Consider using 'calc' instead of 'bc' for your calculations…
>
> Ubuntu 18.04.5: command not found
> NetBSD 9.1: command not found
>
> If you're not going to provide any more information about the program
> than the name, and the post says POSIX in the subject, then shouldn't
> you only be mentioning programs that are pretty standardized?

Ah! Right! POSIX. Sorry. Keep forgetting about that POSIX zealotry…
Comes with age, I guess… I mean forgetting, not zealotry. ;-)

And for those who who might still be interested in calc but don't
know what to do with 'command not found' or are afraid to install
and try packages from the repos of their OS, or it's just not there,
here is the source:

http://www.isthe.com/chongo/tech/comp/calc/index.html

And look! It's older than POSIX! ;-)

--
mrg

On 14/09/2021 at 03.09, Dan Espen wrote:
>> calc 4/7
> ~0.57142857142857142857
>
> Hmm...

What's wrong about it? You did notice it's not 'minus' in front
of that number and you did read the man page?

--
mrg

marrgol <marrgol@address.invalid> writes:

> On 14/09/2021 at 03.09, Dan Espen wrote:
>>> calc 4/7
>> ~0.57142857142857142857
>> Hmm...
>
> What's wrong about it? You did notice it's not 'minus' in front
> of that number and you did read the man page?

I haven't read the man page but for my use I don't want to see all those
decimal places, 2 will do me fine.

Without the man page I tried // instead of /. Gives me zero decimal
places and truncation. I see "calc help round" gives me something.
Guess this isn't a simple tool, I suppose I should read the man page...

--
Dan Espen