Bug 167762 - =(1,01)^1/12 fails in most columns but not in the T column or A to H
Summary: =(1,01)^1/12 fails in most columns but not in the T column or A to H
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
24.2.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-08-01 10:34 UTC by Henrik
Modified: 2025-08-02 08:00 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
shows the issue (308.40 KB, image/png)
2025-08-01 10:35 UTC, Henrik
Details
shows the issue 2 (204.70 KB, image/png)
2025-08-01 10:36 UTC, Henrik
Details
shows the issue 3 (203.85 KB, image/png)
2025-08-01 10:36 UTC, Henrik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik 2025-08-01 10:34:33 UTC
Description:
A fairly simple formula fails in some columns but work in other. see screenshot bellow. from what i can see if i paste it into the T or A To H columns it works fine but all other fails, the row nr doesn't look like it makes a difference. 
=(1,01)^1/12

This happens all the time it this document but not if i open a fresh document. but closing and opening the document changes nothing. 

There is no other strange behavior 

Steps to Reproduce:
1. not sure how the document got to this state, i was just playing around with formulas. changes that can be worth noting is changing default currency to euro and date and time to ddmmyyyy  and to use , instead of . for decimals.
2. copy paste the formula to different columns (it's the same if written by hand)
3. 

Actual Results:
=(1,01)^1/12  => ####

Expected Results:
=(1,01)^1/12  => 0,08416666


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.7.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3
Locale: fr-FR (en_US.UTF-8); UI: en-US
Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4
Calc: threaded
Comment 1 Henrik 2025-08-01 10:35:56 UTC
Created attachment 202124 [details]
shows the issue
Comment 2 Henrik 2025-08-01 10:36:39 UTC
Created attachment 202125 [details]
shows the issue 2
Comment 3 Henrik 2025-08-01 10:36:57 UTC
Created attachment 202126 [details]
shows the issue 3
Comment 4 Mike Kaganski 2025-08-01 10:47:51 UTC
https://help.libreoffice.org/latest/en-US/text/scalc/05/02140000.html?DbPAR=CALC

### means "the cell is not wide enough".
Comment 5 Werner Tietz 2025-08-01 11:30:25 UTC
this »fairly« simple formula »=(1,01)^1/12« could just more simple:

=1,01/12

maybe your really want to calculate:

=1,01^(1/12)

??
Comment 6 Henrik 2025-08-01 11:43:41 UTC
(In reply to Mike Kaganski from comment #4)
> https://help.libreoffice.org/latest/en-US/text/scalc/05/02140000.
> html?DbPAR=CALC
> 
> ### means "the cell is not wide enough".

Thanks for the fast reply Mike! And sorry for the inconvenience. 
May i submit a feature request to update the error code to something more intuitive. Or just displaying the numbers that can fit in the cell like is done when writing text that is too long in the cell. 

Thanks again,
Henrik
Comment 7 Henrik 2025-08-01 11:49:05 UTC
(In reply to Werner Tietz from comment #5)
> this »fairly« simple formula »=(1,01)^1/12« could just more simple:
> 
> =1,01/12
> 
> maybe your really want to calculate:
> 
> =1,01^(1/12)
> 
> ??

You are indeed correct, =1,01^(1/12), bit of a typo on my end
Comment 8 Mike Kaganski 2025-08-01 12:54:48 UTC
(In reply to Henrik from comment #6)
> May i submit a feature request to update the error code to something more
> intuitive.

Why not - just have a proposal, what is "more intuitive".

> Or just displaying the numbers that can fit in the cell like is
> done when writing text that is too long in the cell. 

No. Just no. We have a clear sign, that the data is incomplete. If your idea would be implemented, a number like 12345678 could look like 12345 on a printout / PDF, and there would be no sign that it's not the final sum.
Comment 9 Henrik 2025-08-01 14:21:46 UTC
(In reply to Mike Kaganski from comment #8)
> (In reply to Henrik from comment #6)
> > May i submit a feature request to update the error code to something more
> > intuitive.
> 
> Why not - just have a proposal, what is "more intuitive".
> 
> > Or just displaying the numbers that can fit in the cell like is
> > done when writing text that is too long in the cell. 
> 
> No. Just no. We have a clear sign, that the data is incomplete. If your idea
> would be implemented, a number like 12345678 could look like 12345 on a
> printout / PDF, and there would be no sign that it's not the final sum.

Good point. How about a middle ground where you show the first numbers that can fit, showing the user that the function worked then replace the two last numbers  ## (maybe with the second # halfway cut of by the end of the cell) indicating that it can't show the remaining numbers after
Comment 10 Mike Kaganski 2025-08-02 08:00:21 UTC
(In reply to Henrik from comment #9)
> How about a middle ground where you show the first numbers that
> can fit, showing the user that the function worked then replace the two last
> numbers  ## (maybe with the second # halfway cut of by the end of the cell)
> indicating that it can't show the remaining numbers after

As you said: file an enhancement request with your ideas. If they are found better than the current solution, maybe someone decided to implement them.