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.
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
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.
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.
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:Who's to say 1.2 is more accurate than 1.20000? If I see something
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?
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.
[...] 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'' [...].
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.
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:49:27 AM UTC+3, Eli the Bearded wrote:
In comp.unix.shell, Oğuz <oguzism...@gmail.com> wrote:
For example:Who's to say 1.2 is more accurate than 1.20000? If I see something
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?
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?
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:Who's to say 1.2 is more accurate than 1.20000? If I see something
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?
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 expectInstead of concentrating on the insignificant trailing zeros in your converted values, you probably should be concentrating on ensuring
the result to be 114307.2 seconds? Wouldn't the trailing zeros in 114307.200 be redundant?
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"
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 ofIt's not common to interpret decimal fractions as representing exact quantities because this privilege some values over others. If instead
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.
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.
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?
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…
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?
calc 4/7~0.57142857142857142857
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.)
Fedora not found...
sudo dnf install calc
[...]
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.
calc 4/7~0.57142857142857142857
Hmm...
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?
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 185 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 83:19:11 |
| Calls: | 3,750 |
| Files: | 11,172 |
| Messages: | 3,461,816 |