On 03.11.2025 17:11, Kenny McCormack wrote:
[...]
It is all kind of a bodge and it would have been better if it could have
just been integrated into $(( ... )), like in ksh. [...]
Indeed. Especially if the lib is just adding FP (and nothing else).
Everything, it seems to me, is just easier with ksh.
On Mon, 3 Nov 2025 14:03:18 +0000, Richard Harnden wrote:
Everything, it seems to me, is just easier with ksh.
The saying rCLto someone with a hammer, every problem looks like a nailrCY comes to mind ...
On Mon, 3 Nov 2025 14:03:18 +0000, Richard Harnden wrote:
Everything, it seems to me, is just easier with ksh.
The saying rCLto someone with a hammer, every problem looks like a nailrCY
$ zsh -c 'echo $(( 1.0+2.3 ))'
3.2999999999999998
$ ksh -c 'echo $(( 1.0+2.3 ))'
3.3
Zsh is not really confidence-inspiring here. - Hmm..
On 03.11.2025 17:11, Kenny McCormack wrote:
[...]
It is all kind of a bodge and it would have been better if it could have
just been integrated into $(( ... )), like in ksh. [...]
Indeed. Especially if the lib is just adding FP (and nothing else).
Also with the paragon of Ksh or Zsh using already $((...)) for that.
I also cannot see an extension of $((...)) would break anything in
Bash, or would it?
Alas, re: Zsh, I just noticed...
$ zsh -c 'echo $(( 1.0+2.3 ))'
3.2999999999999998
$ ksh -c 'echo $(( 1.0+2.3 ))'
3.3
Zsh is not really confidence-inspiring here. - Hmm..
0.30.3
*print-flo-precision*15
(set *print-flo-precision* 17)17
0.30.29999999999999999
IEEE 64 bit floats can record a 15 digit number and reproduce
every digit.
On 2025-11-03, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
$ zsh -c 'echo $(( 1.0+2.3 ))'
3.2999999999999998
$ ksh -c 'echo $(( 1.0+2.3 ))'
3.3
Zsh is not really confidence-inspiring here. - Hmm..
I think 0.3 cannot be represented in binary floating point format,
so you are getting an approximation. Zsh and ksh appear to apply
different rounding on output. It's probably just the difference
between %.17g and %g or such.
On 04.11.2025 00:19, Christian Weisgerber wrote:
On 2025-11-03, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
$ zsh -c 'echo $(( 1.0+2.3 ))'
3.2999999999999998
$ ksh -c 'echo $(( 1.0+2.3 ))'
3.3
Zsh is not really confidence-inspiring here. - Hmm..
I think 0.3 cannot be represented in binary floating point format,
so you are getting an approximation. Zsh and ksh appear to apply
different rounding on output. It's probably just the difference
between %.17g and %g or such.
Yes, sure. - It's just that my "simple" pocket-calculator that
I bought around 1980 does not show such obvious rounding errors
(i.e. with numbers it can not exactly represent).
On 2025-11-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 04.11.2025 00:19, Christian Weisgerber wrote:
On 2025-11-03, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>
$ zsh -c 'echo $(( 1.0+2.3 ))'
3.2999999999999998
$ ksh -c 'echo $(( 1.0+2.3 ))'
3.3
Zsh is not really confidence-inspiring here. - Hmm..
I think 0.3 cannot be represented in binary floating point format,
so you are getting an approximation. Zsh and ksh appear to apply
different rounding on output. It's probably just the difference
between %.17g and %g or such.
Yes, sure. - It's just that my "simple" pocket-calculator that
I bought around 1980 does not show such obvious rounding errors
(i.e. with numbers it can not exactly represent).
Calculators use the same base for calculating that they do for
displaying and input. That makes all the difference.
You literally cannot input anything into your calculator that
it cannot represent. It supports an exact representation of 0.3,
or anything else you can punch in.
You can calculate something it cannot represent, like dividing 1 by 3.
But it does that in decimal and can truncate and round as you would
using pencil-and-paper calculations. If it agrees with pencil-and-paper
model decimal calculations, you will find it flawless. :)
On Sun, 2 Nov 2025 16:58:54 -0600, Ed Morton wrote:
On 11/1/2025 3:21 PM, Lawrence DrCOOliveiro wrote:
On Sat, 1 Nov 2025 11:47:47 -0500, Ed Morton wrote:
It's not clear why you'd use bc instead of awk to evaluate the
expression, e.g. using any POSIX awk:
I never bothered with Awk. I realized early on that Perl did everything
that Awk could do, and a lot more, just as concisely.
Conciseness is brevity plus clarity and perl scripts are invariably
missing one of those qualities.
Nope. Things like rCLperl -lnerCY or even rCLperl -lneprCY allow you to write short one-liners that are just as powerful as anything in Awk.
On Sun, 2 Nov 2025 16:58:54 -0600, Ed Morton wrote:
On 11/1/2025 3:21 PM, Lawrence DrCOOliveiro wrote:
On Sat, 1 Nov 2025 11:47:47 -0500, Ed Morton wrote:
It's not clear why you'd use bc instead of awk to evaluate the
expression, e.g. using any POSIX awk:
I never bothered with Awk. I realized early on that Perl did everything
that Awk could do, and a lot more, just as concisely.
Conciseness is brevity plus clarity and perl scripts are invariably
missing one of those qualities.
Nope. Things like rCLperl -lnerCY or even rCLperl -lneprCY allow you to write
short one-liners that are just as powerful as anything in Awk.
(flow "lnep" perm tprint)lnep
On 11/2/2025 7:53 PM, Lawrence DrCOOliveiro wrote:
On Sun, 2 Nov 2025 16:58:54 -0600, Ed Morton wrote:
On 11/1/2025 3:21 PM, Lawrence DrCOOliveiro wrote:
On Sat, 1 Nov 2025 11:47:47 -0500, Ed Morton wrote:
It's not clear why you'd use bc instead of awk to evaluate the
expression, e.g. using any POSIX awk:
I never bothered with Awk. I realized early on that Perl did
everything that Awk could do, and a lot more, just as concisely.
Conciseness is brevity plus clarity and perl scripts are invariably
missing one of those qualities.
Nope. Things like rCLperl -lnerCY or even rCLperl -lneprCY allow you to write
short one-liners that are just as powerful as anything in Awk.
Standard perl proponent type of response there.
On Fri, 31 Oct 2025 06:32:18 -0000 (UTC), Michael Sanders wrote:
usage example: exp 5*2-1
ldo@theon:~> bc <<<'5*2-1'
9
DonrCOt need a whole script to save a few characters of typing ...
On 2025-10-31 at 03:38 ADT, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Fri, 31 Oct 2025 06:32:18 -0000 (UTC), Michael Sanders wrote:
usage example: exp 5*2-1
ldo@theon:~> bc <<<'5*2-1'
9
DonrCOt need a whole script to save a few characters of typing ...
Or in zsh, to avoid having to type quotes
In .zshrc put
aliases[==]='noglob bcfn'
bcfn () {
echo "scale=6 ; $*" | bc
}
At the prompt type
$ == 5*2+1
11
$
This definition
bcfn() { bc <<<"scale=6; $*"; }
was accepted, but then
bcfn 5*2+1
produced the error
zsh: no matches found: 5*2+1
(Did print the answer rCL11rCY in bash, but probably unsafe there too.)
The issue here is that 5*2+1 is interpreted as a glob to be expanded.
On Fri, 7 Nov 2025 10:09:57 -0400, Jim wrote:
On 2025-10-31 at 03:38 ADT, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote: >>>
On Fri, 31 Oct 2025 06:32:18 -0000 (UTC), Michael Sanders wrote:
usage example: exp 5*2-1
ldo@theon:~> bc <<<'5*2-1'
9
DonrCOt need a whole script to save a few characters of typing ...
Or in zsh, to avoid having to type quotes
In .zshrc put
aliases[==]='noglob bcfn'
bcfn () {
echo "scale=6 ; $*" | bc
}
At the prompt type
$ == 5*2+1
11
$
Interesting: this
==() { bc <<<"scale=6; $*"; }
is directly valid in bash, but not zsh.
This definition
bcfn() { bc <<<"scale=6; $*"; }
was accepted, but then
bcfn 5*2+1
produced the error
zsh: no matches found: 5*2+1
(Did print the answer rCL11rCY in bash, but probably unsafe there too.)
...I will admit to being surprised that bash doesn't try
to glob the argument(s)...
Jim Diamond wrote:
...I will admit to being surprised that bash doesn't try to glob
the argument(s)...
It does. But upon failure, bash follows the (dangerous) precedent, established by sh, of passing globs that don't match anything as
literals. The danger in this is that, if you get in the habit of
relying upon the behaviour, you might find it matching something
when you didn't expect it.
Jim Diamond wrote:
...I will admit to being surprised that bash doesn't try
to glob the argument(s)...
It does. But upon failure, bash follows the (dangerous) precedent, established by sh, of passing globs that don't match anything as
literals. The danger in this is that, if you get in the habit of
relying upon the behaviour, you might find it matching something when
you didn't expect it.
I much prefer zsh's (default) behaviour of complaining. I can quote the thing, or use noglob if needed.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 09:07:56 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
2 files (6,679K bytes) |
| Messages: | 265,062 |