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

[Max Nikulin <manikulin@gmail.com>]

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.