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

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

[Charles Millar]

Please note that in the second src_latex the zero is stripped from the 
results. The final zero is required for my purposes, i.e. dollars and 
cents. This occurs in both results and on export to pdflatex,

Does org's evaluation cause this or does latex? I have attempted to use 
the siunutx and currency packages.as follows,

#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
:results replace :exports 
results]{\num[round-precision=2,round-mode=places,round-pad = 
false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\vUSD{printthis}} {{{results(@@latex:\vUSD{22578.6}@@)}}}
(I also tried \dUSA and \cUSA)

On the other hand this has no problem:

#+NAME: TABLE1
|22578.59 |

src_latex[:var printthis=TABLE1[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.59}@@)}}}

The missing zero is important - the result is supposed to be dollars and 
cents.

Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
/usr/local/share/org-mode/lisp/)

GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0) of 2024-04-27

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

[Charles Millar]

Forgot to include that i also used the numprint package.

On 5/5/24 2:30 PM, Charles Millar wrote:
> Please note that in the second src_latex the zero is stripped from the 
> results. The final zero is required for my purposes, i.e. dollars and 
> cents. This occurs in both results and on export to pdflatex,
> 
> Does org's evaluation cause this or does latex? I have attempted to use 
> the siunutx and currency packages.as follows,
> 
> #+NAME: TABLE2
> |22578.60|
> 
> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
> 
> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
> :results replace :exports 
> results]{\num[round-precision=2,round-mode=places,round-pad = 
> false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
> 
> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
> :exports results]{\vUSD{printthis}} {{{results(@@latex:\vUSD{22578.6}@@)}}}
> (I also tried \dUSA and \cUSA)
> 
> On the other hand this has no problem:
> 
> #+NAME: TABLE1
> |22578.59 |
> 
> src_latex[:var printthis=TABLE1[-1,-1] :eval yes :results replace 
> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.59}@@)}}}
> 
> The missing zero is important - the result is supposed to be dollars and 
> cents.
> 
> Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
> /usr/local/share/org-mode/lisp/)
> 
> GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
> cairo version 1.16.0) of 2024-04-27
> 

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

[Ihor Radchenko]

Charles Millar <millarc@verizon.net> writes:

> Please note that in the second src_latex the zero is stripped from the 
> results. The final zero is required for my purposes, i.e. dollars and 
> cents. This occurs in both results and on export to pdflatex,
>
> Does org's evaluation cause this or does latex? I have attempted to use 
> the siunutx and currency packages.as follows,
>
> #+NAME: TABLE2
> |22578.60|
>
> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}

This is expected. When you assign :var, Org mode reads the table data,
converting it to number. When numbers are considered, 22578.60 and
22578.6 are the same thing. If you want to retain the non-significant
zeros in numbers, you need to use strings inside the table:

#+name: TABLE2
|"22578.60"|

Not a bug.
Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Max Nikulin]

On 06/05/2024 19:44, Ihor Radchenko wrote:
> Charles Millar writes:
>> #+NAME: TABLE2
>> |22578.60|
>>
>> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
>> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
> 
> This is expected. When you assign :var, Org mode reads the table data,
> converting it to number.

After discussion of ob-shell related issues I am in doubts if org-babel 
should eagerly convert strings to numbers. Perhaps numbers should be 
recognized for specific backends only (or vice versa conversion should 
be suppressed for specific backends).

> #+name: TABLE2
> |"22578.60"|

It may require boilerplate code for post-processing causing inconvenience.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 06/05/2024 19:44, Ihor Radchenko wrote:
>> Charles Millar writes:
>>> #+NAME: TABLE2
>>> |22578.60|
>>>
>>> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
>>> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
>> 
>> This is expected. When you assign :var, Org mode reads the table data,
>> converting it to number.
>
> After discussion of ob-shell related issues I am in doubts if org-babel 
> should eagerly convert strings to numbers. Perhaps numbers should be 
> recognized for specific backends only (or vice versa conversion should 
> be suppressed for specific backends).

Maybe. But changing the current behavior is not trivial - a lot of code
relies upon it implicitly. If anyone wants to work on more
fine-grained control over Org markup -> Elisp conversion, feel free.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Charles Millar]

On 5/6/24 12:42 PM, Ihor Radchenko wrote:
> Max Nikulin <manikulin@gmail.com> writes:
> 
>> On 06/05/2024 19:44, Ihor Radchenko wrote:
>>> Charles Millar writes:
>>>> #+NAME: TABLE2
>>>> |22578.60|
>>>>
>>>> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
>>>> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
>>>
>>> This is expected. When you assign :var, Org mode reads the table data,
>>> converting it to number.
>>
>> After discussion of ob-shell related issues I am in doubts if org-babel
>> should eagerly convert strings to numbers. Perhaps numbers should be
>> recognized for specific backends only (or vice versa conversion should
>> be suppressed for specific backends).
> 
> Maybe. But changing the current behavior is not trivial - a lot of code
> relies upon it implicitly. If anyone wants to work on more
> fine-grained control over Org markup -> Elisp conversion, feel free.
> 
Thanks for the feedback. For the moment I will create separate tables 
that have the the desired data in quotes.

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?

As an aside, I am not a coder; however I was playing around in the 
scratch butter, and it appears to me that this issue may run deeper that 
Org Mode, for instance:

(number-to-string 5.000)

evaluates to "5.0"

Furthermore, and more closely related to the topic,

(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".

Just my 0.020 cents

Charlie Millar

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

[Max Nikulin]

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.

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.

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

[Max Nikulin]

On 07/05/2024 21:25, Charles Millar wrote:
> On 5/7/24 7:49 AM, Max Nikulin wrote:
>> On 07/05/2024 03:05, Charles Millar wrote:
>>
>>> (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.

Debian bookworm stable and Emacs-28.2.

LANG, LC_NUMERIC, LC_ALL environment variable should not affect 
formatting in numbers in Emacs since the "C" locale is forced for numbers.

The only guess I have is non-default value of `float-output-format'.