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?

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

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.

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

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

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

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.

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

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.

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

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 */

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

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

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

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.

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

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

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

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"

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

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"

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

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.

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

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

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

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

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

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

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

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

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

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 */

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

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

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

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

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

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

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

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

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

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

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