Bug 133161 - Formula in Calc giving wrong result (MIN function)
Summary: Formula in Calc giving wrong result (MIN function)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.5.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:xlsx
Depends on:
Blocks:
 
Reported: 2020-05-19 09:00 UTC by tracht
Modified: 2020-05-20 06:42 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
file with the issue (5.85 KB, application/wps-office.xlsx)
2020-05-19 09:01 UTC, tracht 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description tracht 2020-05-19 09:00:31 UTC 
Description:
A formula which uses MIN function produces obviously wrong result.

Steps to Reproduce:
No easy way to reproduce. I tried to calculate relative values (i.e. value minus minimum value). Tests on smaller dataset produces right result

Actual Results:
value in B20 is 0

Expected Results:
value in B20 should be ~8.2


Reproducible: Always


User Profile Reset: No



Additional Info:
Ubuntu 18.04, affected both 6.0.7.3 and 6.4.3.2 (snap1) versions. WPS Office produces good results
Comment 1 tracht 2020-05-19 09:01:34 UTC 
Created attachment 160996 [details]
file with the issue
Comment 2 tracht 2020-05-19 09:02:50 UTC 
The result in B20 is not the only wrong value, but I expect all the wrong values come from the same reason
Comment 3 tracht 2020-05-19 09:15:40 UTC 
Values in B20:B26 are shifted by 8.2, B27:B31 by 3.9, B32:B33 are fine
Comment 4 tracht 2020-05-19 09:30:08 UTC 
The values in the cells were copied from Linux terminal, so some invisible formatting marks may be present
Comment 5 himajin100000 2020-05-19 09:39:15 UTC 
not reproducible.
B20 shows 8.2(precisely 8.16999999992549)

Version: 7.0.0.0.alpha1+ (x64)
Build ID: 0e3196c49b84651df20b770d5cd7f0bbb19dfc40
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: ja-JP (ja_JP); UI: en-US
Calc: CL
Comment 6 Ming Hua 2020-05-19 10:13:25 UTC 
I can reproduce with both 7.0.0 Alpha1:
Version: 7.0.0.0.alpha1 (x64)
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; UI 渲染: Skia/Raster; VCL: win; 
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: threaded

and 6.3.5:
Version: 6.3.5.2 (x64)
Build ID: dd0751754f11728f69b42ee2af66670068624673
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

B20 is 0.0 in both cases.

I don't have daily builds installed.
Comment 7 Ming Hua 2020-05-19 10:18:36 UTC 
(In reply to tracht from comment #4)
> The values in the cells were copied from Linux terminal, so some invisible
> formatting marks may be present
Clear direct formatting does nothing.

However, Data > Force Recalculation (Ctrl+Shift+F9) gives me the correct 8.2 result for cell B20.  Can you try that as well?
Comment 8 tracht 2020-05-19 10:27:13 UTC 
Yes, I can confirm that recalculation helps.
Comment 9 Ming Hua 2020-05-19 11:00:35 UTC 
(In reply to tracht from comment #8)
> Yes, I can confirm that recalculation helps.
Thanks for testing.  I don't know enough about importing to act on this bug (briefly looked in Tool > Options and didn't find anything like "force recalculation on load"), so I'll leave it to more experienced people.

But it should be configurable, I believe that's the reason why himajin100000 couldn't reproduce this bug.