all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Bug: Final zero after decimal point is stripped when inline code evaluated
       [not found] <144951b9-d715-4fd6-a3f5-2462ff98acb0.ref@verizon.net>
@ 2024-05-05 18:30 ` Charles Millar
  2024-05-05 18:41   ` Charles Millar
  2024-05-06 12:44   ` Ihor Radchenko
  0 siblings, 2 replies; 9+ messages in thread
From: Charles Millar @ 2024-05-05 18:30 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-05 18:30 ` Bug: Final zero after decimal point is stripped when inline code evaluated Charles Millar
@ 2024-05-05 18:41   ` Charles Millar
  2024-05-06 12:44   ` Ihor Radchenko
  1 sibling, 0 replies; 9+ messages in thread
From: Charles Millar @ 2024-05-05 18:41 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org

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
> 



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-05 18:30 ` Bug: Final zero after decimal point is stripped when inline code evaluated Charles Millar
  2024-05-05 18:41   ` Charles Millar
@ 2024-05-06 12:44   ` Ihor Radchenko
  2024-05-06 16:36     ` Max Nikulin
  1 sibling, 1 reply; 9+ messages in thread
From: Ihor Radchenko @ 2024-05-06 12:44 UTC (permalink / raw)
  To: Charles Millar; +Cc: emacs-orgmode@gnu.org

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>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-06 12:44   ` Ihor Radchenko
@ 2024-05-06 16:36     ` Max Nikulin
  2024-05-06 16:42       ` Ihor Radchenko
  0 siblings, 1 reply; 9+ messages in thread
From: Max Nikulin @ 2024-05-06 16:36 UTC (permalink / raw)
  To: emacs-orgmode

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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-06 16:36     ` Max Nikulin
@ 2024-05-06 16:42       ` Ihor Radchenko
  2024-05-06 20:05         ` Charles Millar
  0 siblings, 1 reply; 9+ messages in thread
From: Ihor Radchenko @ 2024-05-06 16:42 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

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>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-06 16:42       ` Ihor Radchenko
@ 2024-05-06 20:05         ` Charles Millar
  2024-05-07 11:49           ` Max Nikulin
  0 siblings, 1 reply; 9+ messages in thread
From: Charles Millar @ 2024-05-06 20:05 UTC (permalink / raw)
  To: Ihor Radchenko, Max Nikulin; +Cc: emacs-orgmode

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






^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
  2024-05-06 20:05         ` Charles Millar
@ 2024-05-07 11:49           ` Max Nikulin
       [not found]             ` <aad9bb0b-4b64-4934-952d-a6cdc9f3b32f@verizon.net>
  0 siblings, 1 reply; 9+ messages in thread
From: Max Nikulin @ 2024-05-07 11:49 UTC (permalink / raw)
  To: emacs-orgmode

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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Fwd: Bug: Final zero after decimal point is stripped when inline code evaluated
       [not found]             ` <aad9bb0b-4b64-4934-952d-a6cdc9f3b32f@verizon.net>
@ 2024-05-07 14:31               ` Charles Millar
  2024-05-07 16:40               ` Max Nikulin
  1 sibling, 0 replies; 9+ messages in thread
From: Charles Millar @ 2024-05-07 14:31 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org




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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Bug: Final zero after decimal point is stripped when inline code evaluated
       [not found]             ` <aad9bb0b-4b64-4934-952d-a6cdc9f3b32f@verizon.net>
  2024-05-07 14:31               ` Fwd: " Charles Millar
@ 2024-05-07 16:40               ` Max Nikulin
  1 sibling, 0 replies; 9+ messages in thread
From: Max Nikulin @ 2024-05-07 16:40 UTC (permalink / raw)
  To: Charles Millar; +Cc: Org Mode List

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-05-07 16:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <144951b9-d715-4fd6-a3f5-2462ff98acb0.ref@verizon.net>
2024-05-05 18:30 ` Bug: Final zero after decimal point is stripped when inline code evaluated Charles Millar
2024-05-05 18:41   ` Charles Millar
2024-05-06 12:44   ` Ihor Radchenko
2024-05-06 16:36     ` Max Nikulin
2024-05-06 16:42       ` Ihor Radchenko
2024-05-06 20:05         ` Charles Millar
2024-05-07 11:49           ` Max Nikulin
     [not found]             ` <aad9bb0b-4b64-4934-952d-a6cdc9f3b32f@verizon.net>
2024-05-07 14:31               ` Fwd: " Charles Millar
2024-05-07 16:40               ` Max Nikulin

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.