Bug 165619 - ROUND function in Data Provider numeric transformation is ineffective
Summary: ROUND function in Data Provider numeric transformation is ineffective
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
25.8.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Data-Provider
  Show dependency treegraph
 
Reported: 2025-03-06 22:30 UTC by Olivier Hallot
Modified: 2025-03-12 12:20 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
sample data to show issue (13.05 KB, text/csv)
2025-03-06 22:30 UTC, Olivier Hallot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2025-03-06 22:30:46 UTC
Created attachment 199671 [details]
sample data to show issue

The ROUND function found in Data Provider Numeric Transformation is ineffective.

Step to reproduce
0) in an empty sheet
1) define a database range
2) open Data Provider, select the database range above, select CSV (default)
3) Select the CSV attached
4) Choose Numeric transformation
5) Select Round function on a column with decimals
6) Press Apply
7) inspect the Preview window

Expected results:
The columns selected should be truncated (only integer part)

Actual results
Nothing happens

Note: ROUNDUP and ROUNDDOWN works, no extra param needed.

Inspecting the source code at line 414 of

https://opengrok.libreoffice.org/xref/core/sc/source/ui/dataprovider/datatransformation.cxx

and line 143 of

https://opengrok.libreoffice.org/xref/core/sc/source/ui/inc/datatransformation.hxx

We see that the numeric transformations has 2 signatures

NumberTransformation(std::set<SCCOL>&& nCol, const NUMBER_TRANSFORM_TYPE rType);
NumberTransformation(std::set<SCCOL>&& nCol, const NUMBER_TRANSFORM_TYPE rType,
                             int nPrecision);

The ROUND function uses the second signature as indicated in line 435 and 445 of

https://opengrok.libreoffice.org/xref/core/sc/source/ui/dataprovider/datatransformation.cxx

However the dialog does not have an entry for the second signature and the argument nPrecision is not defined.

The dialog is

https://opengrok.libreoffice.org/xref/core/sc/uiconfig/scalc/ui/numbertransformationentry.ui
Comment 1 m_a_riosv 2025-03-07 01:36:37 UTC
Repro
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e79e12484f5a7ec20e48233a2b5b60d7bd8b54ab
CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-US (es_ES); UI: en-GB
Calc: CL threaded
Comment 2 Rafael Lima 2025-03-08 23:04:25 UTC
There are 2 ways to fix this. A super simple fix is to force nPrecision = 0 to round numbers to the closest integer. This is done here:

https://gerrit.libreoffice.org/c/core/+/182677

The more complicated fix would be to show an GtkEntry to allow the user to entry the precision. This Entry would only appear for the ROUND transformation. This would be similar to what we have in the "Random Number Generator" dialog.

TBH I think this is a bit overkill, because one would argue that this "Precision" should also apply for other transformations as ROUND_UP, ROUNDDOWN, SQUARE, SQUARE_ROOT, etc, which would require various changes in NumberTransformation::Transform.

Let me know which one you think is best.
Comment 3 Olivier Hallot 2025-03-10 17:14:34 UTC
Setting nPrecision to 0 is a bugzilla time bomb, IMHO.

I prefer to address the issue in full.

I'll bring it to ESC. Stay tuned.

In the meantime, adding a 3rd parameter (nPrecision) in the dialog does seem feasible. THe dialog findandreplace.ui has 3 entries. The controller should detect the ROUND function is make the 3rd entry visible, and if not ROUND function, the make it invisible.
Comment 4 m_a_riosv 2025-03-11 03:06:34 UTC
+1 for full implementation.
Comment 5 Rafael Lima 2025-03-12 12:20:09 UTC
(In reply to m_a_riosv from comment #4)
> +1 for full implementation.

Working on it.