From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id ac98d464 for ; Sat, 21 Dec 2019 08:48:20 +0000 (UTC) Received: (qmail 12277 invoked by alias); 21 Dec 2019 08:48:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45105 Received: (qmail 19088 invoked by uid 1010); 21 Dec 2019 08:48:15 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm1-f42.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25663. spamassassin: 3.4.2. Clear:RC:0(209.85.128.42):SA:0(-2.0/5.0):. Processed in 1.251526 secs); 21 Dec 2019 08:48:15 -0000 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.42 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=LRAZzyiCA8g9LWNpDhfYlKutUymBxFYcF/EWbvCrbMM=; b=okRtIVyAZ7hE7ZMzoLU42KNIpquLGnQ/zP3NtNq5BeB+d0Ov6DzAogF96+lE7753NH Y6BSVQDM8KhcWVjk7CyJECaqUitzQZIYRvK56BGH+VV2Khk9IDQQI/8BPTeeo9f61Ea8 uvKXuKLG8EmgFd1kfqGG4Dm+B49e68LjZyoGl7SrSuYtnnKRReTY0gWvUPKM3rDAJ9ZM q1M09/jTlnliALMHLGtZyri7Gx2sdHvSF6cWavjtrKqru6D6rBqAxXZqEv/EF9QfEXwt lcYhyKYk7/mjlCvGO1Ztcp2zrSEdpwwdNG/tiWZ6ajrjoBMUopOyYOYcFT2SZ5gyFmlV cMhg== X-Gm-Message-State: APjAAAX8CmNBahNaeb0PgZtxkMwh73OEPpJkZD00UGu+kLE+vEhi6bne rgJ1bdEUjC//CfVfTQ2tlJgoHt6f X-Google-Smtp-Source: APXvYqxrBZZNJJQ9geT18w8MNjkKbyeSmI7dmzAz20cjLNrcbNvXujtjrt3rFvbRKx8ByPUtz3W+vg== X-Received: by 2002:a1c:4b01:: with SMTP id y1mr20061328wma.12.1576918058662; Sat, 21 Dec 2019 00:47:38 -0800 (PST) Date: Sat, 21 Dec 2019 08:47:36 +0000 From: Stephane Chazelas To: zsh-workers@zsh.org Subject: Re: zsh converts a floating-point number to string with too much precision Message-ID: <20191221084736.bokldw7tzxw3thn3@chaz.gmail.com> Mail-Followup-To: zsh-workers@zsh.org References: <20191220013711.GA708801@zira.vinc17.org> <20191220165824.ufvjtx37xt7dp2dt@chaz.gmail.com> <20191221005005.GB767822@zira.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191221005005.GB767822@zira.vinc17.org> User-Agent: NeoMutt/20180716 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