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=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 ac7bf8bd for ; Fri, 20 Dec 2019 01:38:02 +0000 (UTC) Received: (qmail 17522 invoked by alias); 20 Dec 2019 01:37:55 -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: 45093 Received: (qmail 27750 invoked by uid 1010); 20 Dec 2019 01:37:55 -0000 X-Qmail-Scanner-Diagnostics: from joooj.vinc17.net 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(155.133.131.76):SA:0(-1.9/5.0):. Processed in 2.190724 secs); 20 Dec 2019 01:37:55 -0000 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Fri, 20 Dec 2019 02:37:11 +0100 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: zsh converts a floating-point number to string with too much precision Message-ID: <20191220013711.GA708801@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.12.1+33 (6a74e24e) vl-117499 (2019-06-23) With zsh 5.7.1, I get: zira% echo $((1.1)) 1.1000000000000001 because zsh seems to first select the precision independently from the value, i.e. 17 to be able to convert the string back to floating point, preserving the original value, then it outputs the closest number in this precision. Instead, zsh should select the minimum precision so that the inverse conversion can give the original value, i.e. it should output 1.1 here. FYI, GNU MPFR has the same issue with mpfr_printf and %Re (with an empty precision field), and I regard this as a bug: https://sympa.inria.fr/sympa/arc/mpfr/2019-12/msg00000.html https://sympa.inria.fr/sympa/arc/mpfr/2019-12/msg00001.html Note that Java does it right: zira:~> cat tst.java public class tst { public static void main(String[] args) { double x; x = 0x1.1999999999999p+0; System.out.println(x); x = 0x1.199999999999ap+0; System.out.println(x); x = 0x1.199999999999bp+0; System.out.println(x); } } zira:~> javac tst.java zira:~> java tst 1.0999999999999999 1.1 1.1000000000000003 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)