Fwd: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

-------- Forwarded Message --------
Subject: Re: Bug: Final zero after decimal point is stripped when inline 
code evaluated
Date: Tue, 7 May 2024 10:25:05 -0400
From: Charles Millar <millarc@verizon.net>
To: Max Nikulin <manikulin@gmail.com>

On 5/7/24 7:49 AM, Max Nikulin wrote:
> 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".

Nor sure myself! What I meant was each number in the second column was a 
result of a :var evaluation that called a table and that there was a 
different table for each number.

>  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.
I am using Debian Testing, full upgrade as of last Saturday.