Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
floating-point precision and zsh vs ksh93 and coreutils
- X-seq: zsh-workers 49886
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: floating-point precision and zsh vs ksh93 and coreutils
- Date: Wed, 23 Mar 2022 17:36:46 +0100
- Archived-at: <https://zsh.org/workers/49886>
- List-id: <zsh-workers.zsh.org>
- Mail-followup-to: zsh-workers@xxxxxxx
For floating-point arithmetic evaluation, it appears that zsh uses the
"double" type while ksh93 and GNU coreutils both use the "long double"
type, which means incompatibility:
$ ksh93 -c '/usr/bin/printf "%a\n" $((1./3))'
0xa.aaaaaaaaaaaaa9ep-5
$ zsh -fc '/usr/bin/printf "%a\n" $((1./3))'
0xa.aaaaaaaaaaaa74ep-5
and
$ ksh93 -c '/usr/bin/printf "%a\n" $((43./2**22))'
0xa.cp-20
$ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))'
0xa.c0000000000025cp-20
In the second case, while the number is exactly representable
(and has the same value) in both double and long double, the
issue is visible because the number is passed with a decimal
representation, with enough decimal digits to read the result
with 53-bit precision in the zsh test.
Shouldn't zsh switch to long double?
Note: using printf from the GNU coreutils instead of the zsh printf
builtin is needed for %a support.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author