zsh-workers
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane.chazelas@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: zsh converts a floating-point number to string with too much precision
Date: Sat, 21 Dec 2019 08:47:36 +0000	[thread overview]
Message-ID: <20191221084736.bokldw7tzxw3thn3@chaz.gmail.com> (raw)
In-Reply-To: <20191221005005.GB767822@zira.vinc17.org>

2019-12-21 01:50:05 +0100, Vincent Lefevre:
> On 2019-12-20 18:12:18 +0100, Roman Perepelitsa wrote:
> > I think what Vincent meant is that zsh should produce the shortest
> > string that, when parsed, results in a value equal to the original.
> > 
> > For your example, "1.1" is the shortest string that parses into
> > floating point value equal to the original, hence this (according to
> > Vincent) is what zsh should produce.
> 
> Yes, this is exactly what I meant, and what Java's System.out.println
> seems to do. This is also specified like that in XPath.
> 
> I think that's the best compromise in practice.
[...]

OK, I think I see what you mean.

So on a system (with a compiler) where C doubles are implemented
as IEEE 754 double precision, both 1.1 and 1.1000000000000001
are represented as the same binary double (whose exact value is
1.100000000000000088817841970012523233890533447265625).

So you're saying echo $((1.1000000000000001)) and echo $((1.1))
should output 1.1, because even though 1.1000000000000001 is
closer to that value than 1.1000000000000000, zsh should pick
the latter because people prefer to see shorter number
representations and in that case it doesn't matter which one we
pick as both lead to the same double.

How would we do that?

Is there a standard C API for that?

Or would we get the output of sprintf("%.17g"), look at the last
two significant digits, if the second last is 9 or 0, then see
if rounding it and doing a strtod again yields the same double?

That seems a bit overkill (and I suspect that's not even a valid
approach).

Or should we implement the conversion to decimal string
representation from scratch without using sprintf() and adapt to
every system's double representation? or assume doubles are IEEE
754 ones as is more or less already done?

How are those other languages doing it?

-- 
Stephane

  reply	other threads:[~2019-12-21  8:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20  1:37 Vincent Lefevre
2019-12-20  3:38 ` Mikael Magnusson
2019-12-20 16:58 ` Stephane Chazelas
2019-12-20 17:12   ` Roman Perepelitsa
2019-12-21  0:50     ` Vincent Lefevre
2019-12-21  8:47       ` Stephane Chazelas [this message]
2019-12-21  9:43         ` Roman Perepelitsa
2019-12-21 17:56           ` Stephane Chazelas
2019-12-21 18:11             ` Stephane Chazelas
2019-12-21 18:20               ` Roman Perepelitsa
2019-12-21 21:28         ` Vincent Lefevre
2019-12-21  1:00   ` Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191221084736.bokldw7tzxw3thn3@chaz.gmail.com \
    --to=stephane.chazelas@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).