From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id wMDMOaUVOmYssQAAqHPOHw:P1 (envelope-from ) for ; Tue, 07 May 2024 13:51:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id wMDMOaUVOmYssQAAqHPOHw (envelope-from ) for ; Tue, 07 May 2024 13:51:02 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1715082661; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=c/7+egjNpMwvm4Cxx0mHNLKihf9zF2ZUWnnF5zg7A+s=; b=nJH5w12AUSNzAxbeK0xp5pR17bxIxShWGvZxT5poAhUpWFIreI62Pm/bYTXA0jSQJfMRYB EwNhssEeZqmkVcI90GEEBtu+GFGDQjxldJZsMDVNouWlm4RSMwlU0X7F6hjtnPUt5JtWBS SbIPwFaFsJNAjHFH/rOFLF8Y5s8P69U/Uq4iJIWM086Vwqyiw4sKLdZSm6EiJSE5CrmXBj NaBbikni4aRb6QyvdRrBpu09ttA/Ie4Y7xtpysdPpa351OMJXJiCDmToGGb1Xkkfrqf08r NjwYP/QiHpqpFsK3PbsYCZDgbSh889Psdml+NxoGuH6okGI9xPjJIatz2PGvTQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1715082661; a=rsa-sha256; cv=none; b=Mseh8zpAWD93sU/E8dRAzFqeO95mX7wg2rvCPd6L+Iw8WPS/WbLoM7ICnuD14b2qVYExM8 peq8zTF8tRjL/oKsZijTDjQU+//kfzEH1w0adwOMaP0be4s7zD5ygYJ3WMIaLv8wmPCm/k xEe64MGdbu8Vy0aShGJMCktuJkmuRq/pJTvekwRiFfVEbpRKWTWoR4QuM319q8IeUfM2YW heDq/tLHm1Oka2/qycS7CO7CpKomX2I6EIKOqs6vNw2nQ35bNbAWT2AMAQu/NJtF1PRGnp ct1auUJGwZOrvpf8xmCC4xawBsT+gYYfah/8Sk45ForlhAglh0aEH1DJlYEJPw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9F100518F2 for ; Tue, 7 May 2024 13:51:01 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4JKV-00063u-JK; Tue, 07 May 2024 07:49:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JKN-00060H-WB for emacs-orgmode@gnu.org; Tue, 07 May 2024 07:49:49 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JKH-0004h4-Tm for emacs-orgmode@gnu.org; Tue, 07 May 2024 07:49:44 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1s4JK7-0007rU-Kb for emacs-orgmode@gnu.org; Tue, 07 May 2024 13:49:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Bug: Final zero after decimal point is stripped when inline code evaluated Date: Tue, 7 May 2024 18:49:18 +0700 Message-ID: References: <144951b9-d715-4fd6-a3f5-2462ff98acb0.ref@verizon.net> <144951b9-d715-4fd6-a3f5-2462ff98acb0@verizon.net> <87bk5jhzzi.fsf@localhost> <87v83q3n9r.fsf@localhost> <3eb4f551-ea60-4e56-b666-4430747c816f@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU In-Reply-To: <3eb4f551-ea60-4e56-b666-4430747c816f@verizon.net> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -0.87 X-Spam-Score: -0.87 X-Migadu-Queue-Id: 9F100518F2 X-Migadu-Scanner: mx13.migadu.com X-TUID: QHKa55tA+mI7 On 07/05/2024 03:05, Charles Millar wrote: > I appreciate that mathematically a trailing zero or zeros may be > non-significant; however, in my use case, i.e. correct format in a text, > they are necessary. Another example, in addition to my Dollars and cents > scenario, may be a table that that has been created by using append, and > the table appears as follows because trailing zeros were disregarded. > > This 1.222 > that 3.444 > it   5.6 > last 7.691 > > Question arises - is the correct number reported on line "it" 5.600 or > has some editing omitted the last two decimal places? I am unsure what do you mean by "using append". From my point of view there are 2 cases: - When output format is fixed | 2 | 1.41 | | 3 | 1.73 | #+TBLFM: $2=(sqrt $1);%.2f - When calculations should be performed with fixed point, usual floating point representation gives unexpected results src_elisp{(- 0.3 (+ 0.1 0.1 0.1))} {{{results(=-5.551115123125783e-17=)}}} Some programming languages have decimal type for numbers: https://docs.python.org/3/library/decimal.html As to finances, I was surprised that ledger, hledger, and beancount have different internal representations for amounts and there are various issues with rounding. Org just should avoid unnecessary conversions between strings an numbers, but Ihor is right and implementation would require enough efforts. > (setq toconvert 5.000) > (number-to-string toconvert) > > evaluates to "5". I get "5.0" (Linux), so I suspect some mistake.