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

[Charles Millar <millarc@verizon.net>]

-------- 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.