Bug 85410 - Remove Decimal Space button causes 10 decimals before it decreases one at a time
Summary: Remove Decimal Space button causes 10 decimals before it decreases one at a time
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 92985 157514 157651 (view as bug list)
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2014-10-24 16:35 UTC by icerabbit
Modified: 2024-03-15 17:12 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file. Same data over several rows. Showing result of each additional click. (32.94 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-10-24 16:35 UTC, icerabbit
Details
reduceDecimalPlaces.ods: several situations trying to reduce decimal place (15.69 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-03-11 13:49 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description icerabbit 2014-10-24 16:35:59 UTC
Created attachment 108359 [details]
Example file. Same data over several rows. Showing result of each additional click.

Problem description: 

This has been a long time issue, probably carried over from OO. 

Whenever I'm working with numbers and trying to get some averages in general or per week, month, etc LO will randomly show anywhere from 3 to 5 even 7 decimals (based on space?). Then when I click the remove decimal button, the cell goes ### (number doesn't fit) because it kicked the decimals up to ten; and only then takes one decimal away at a time with each click.  In many cases I've seen now that going from 3 decimals to 2 requires 8 clicks. From 3 to zero requires 10 clicks.

Steps to reproduce:
1. Brand New Spread Sheet
2. A1= nnnnnn.nn
3. B1= nnn
4. C1 = A1/B1
5. Result is nnnn.nnnnnn
6. Click delete decimal space button

( example a1: 123456.78  b1:123 )

Current behavior: cell goes ###, adding more decimal spaces, up to 10, then deletes one with each additional click

Expected behavior: Remove one decimal right away, do not add extra decimals first 

PS: I have seen this behavior both in pc and mac versions of calc OO and LO. 

Additional note: I believe the delete decimal function to work properly when there's only one or two, but acting up when there are three or more. Anytime it defaults to 3,4,5,6 etc. it takes several additional clicks to remove one or two, because it jumps to 10 first. 

(through the LO feedback page I can't seem to submit a file, in safari, says data not loaded try again in a few secs, will try file separately, or firefox, maybe? no doesn't work in firefox either? ... trying bugs freedesktop)
Comment 1 A (Andy) 2014-10-24 17:20:57 UTC
Reproducible with LO 4.3.2.2 (Win 8.1), after step 6 I get also "###"

As far as I know LO is showing and calculating (?) 10 decimal places if there is enough space or less if there is less space.  
Under TOOLS -> OPTIONS -> LIBREOFFICE CALC -> CALCULATE it is possible to limit decimal places.  
Of the function PI() LO calculates/shows at maximum 14 decimal places.
Comment 2 icerabbit 2014-10-25 01:29:19 UTC
Thanks, Andy.

Just earlier today learned about the decimal limiter preference option, but I'm hesitant to use it. Guess I could set it to four decimals (rather than two) as 3-4 that is the max I typically use.

Still think though that the exhibited behavior of going from 4,5,6 decimals shown to 10 and then down one at a time, is not the proper or expected behavior.
Comment 3 A (Andy) 2014-10-25 06:51:52 UTC
I would agree, the reported behavior is buggy.
Comment 4 tommy27 2016-04-16 07:27:44 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2017-05-22 13:25:11 UTC Comment hidden (obsolete)
Comment 6 icerabbit 2017-07-13 13:56:53 UTC
Problem still persists, but in testing I should clarify that it is in part visual. Technically works fine ... just not as visually expected.

Just downloaded the latest FRESH version on Windows: 5.3.4.
Created new spreadsheet in CALC.

I picked two random numbers:

Cell one: 2344 
Cell two: 13
Cell three: 2344/13= 180.307692

When I click decrease indent, it goes ###
Then one has to keep clicking decrease indent, until it finally shows 180.307692 again, and then after that it takes one decimal off at a time. 

My expected behavior is to take an indent away based on what I see on screen.
Comment 7 QA Administrators 2018-07-14 02:45:47 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2020-07-14 04:03:36 UTC Comment hidden (obsolete)
Comment 9 Michael Warner 2020-07-25 04:03:45 UTC
*** Bug 92985 has been marked as a duplicate of this bug. ***
Comment 10 Laurent Balland 2020-07-25 09:26:48 UTC
The reason of this behavior is that "General" format has no fixed decimal places: it is adapted to column width and precision (scientific format may be preferred for large or small values). As there is no specified format (number places is undefined), "Add/Delete Decimal Place" fixes decimal places to the maximum given by precision.
The easiest workaround I found is to first apply "Format as Number" with one of these ways:
- button "Format as Number" in Format toolbar (just left of "Add/Delete Decimal Place"
- keyboard shortcut Shift+Ctrl+1
- sidebar "Number format" section: modify "Leading zeroes" or change category to Number
Comment 11 icerabbit 2021-02-18 15:22:36 UTC
I understand that applying cell formatting to a specified type and notation will  change this behavior. LO's behavior could be enhanced.  

As, for end users and people new to the program, this is not desirable; when this issue is not present in competing commercial programs.  Other products understand logically, that if a cell or table space shows 4 decimals in a default cell, reducing means show 3 decimals, and again gets it to show 2 cells. 

This less than ideal behavior is still present in LO 7.0.3.1

I have a cell: 

=(F35*E35)+(D35*$D$21/60)
With a calculated value of 8.333333333333333333333...

LO Shows this as 8.3333

Clicking Reduce Decimals makes it ####

Clicking it nine more times I am back at 8.3333

Clicking it two more times I am at 8.33

Something other programs do by default in two clicks, regardless of formatting.
Comment 12 José Trujillo 2022-01-26 09:17:43 UTC
Yes, this behaviour is annoying and undesired.
In addition, for those who start with libreoffice it is disconcerting.
To resolve the situation, they have to learn some of the techniques listed above. Or simply pressing "reduce decimals" too many times.
It is discouraging. It should revert to the situation in previous versions.
Comment 13 Rafael Lima 2023-10-07 13:15:58 UTC
*** Bug 157651 has been marked as a duplicate of this bug. ***
Comment 14 Rafael Lima 2023-10-07 13:17:16 UTC
*** Bug 157514 has been marked as a duplicate of this bug. ***
Comment 15 Justin L 2024-03-11 13:49:38 UTC
Created attachment 193059 [details]
reduceDecimalPlaces.ods: several situations trying to reduce decimal place

The function handling this is ScViewFunc::ChangeNumFmtDecimals(bool bIncrement)

It isn't as bad as it originally sounded, IMHO. Most situations handle it correctly. When a range of cells is chosen, only the "current" cell is evaluated - that seems logical and simplifies things.

The problem happens in the "General Number" case, when there is not enough space to display the whole number. In that case, the program is allowed to "round" the number based on the column width instead of showing ###. However, the "real" number is more decimal places than can be shown. By decreasing the decimal point, we now force X number of decimal places, which in the "auto-rounded" cases likely means it won't fit any more.

In other words, you will only see this problem on cells where more decimal places will be shown if you increase the width of the column.

So this depends on font size, zoom level, etc.
Comment 16 Justin L 2024-03-11 22:38:07 UTC
Getting what is actually displayed in the cell is not easy. It is NOT one of these:
rDoc.GetString(nCol, nRow, nTab)
ScCellFormat::GetInputString(aCell, nOldFormat, *rDoc.GetFormatTable(), rDoc)
ScCellFormat::GetOutputString(rDoc, aPos, aCell)

In fact, I think the shortened string just ends up being drawn to a screen position, and never ends up as an actual string stored anywhere.
mpDev->DrawText(aDrawTextPos, aShort, 0, -1, nullptr, nullptr, ...
in ScOutputData::LayoutStrings

where aDrawTextPos is an X,Y coordinate, and  aShort is ScDrawStringsVars::GetString where (m_)aString was set in ScDrawStringsVars::SetTextToWidthOrHash

That pretty much makes this bug impossible to solve without doing massive edge-casing. It certainly doesn't seem to be a logical flaw...
Comment 17 Rafael Lima 2024-03-15 13:32:52 UTC
(In reply to Justin L from comment #16)
> That pretty much makes this bug impossible to solve without doing massive
> edge-casing. It certainly doesn't seem to be a logical flaw...

I did some testing as well and I can confirm everything you said.

One idea I had is the following: Currently, when bWasStandard is true, we test the output string to figure out the value of nPrecision. However, the output string can be much larger than what would fit on the screen.

Instead we should define nPrecision by the amount of text that would fit in the cell. This probably could be done by dividing the cell width by the width of a single character. Then we could figure out how many decimal numbers are probably being displayed on the screen to determine nPrecision.

Since this would only be needed for the current cell (not the entire range), than it shouldn't be too costly.
Comment 18 Laurent Balland 2024-03-15 17:12:20 UTC
(In reply to Rafael Lima from comment #17)
> Instead we should define nPrecision by the amount of text that would fit in
> the cell. This probably could be done by dividing the cell width by the
> width of a single character. Then we could figure out how many decimal
> numbers are probably being displayed on the screen to determine nPrecision.
You need also to check if General format chose a scientific notation to better fit in column width.