Bug 131216 - function RANK should show equal rank but does not (rare occurrence)
Summary: function RANK should show equal rank but does not (rare occurrence)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-08 03:15 UTC by Jake
Modified: 2020-03-09 16:01 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Worksheet should open to problem area described above (466.32 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-08 03:15 UTC, Jake
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jake 2020-03-08 03:15:20 UTC
Created attachment 158490 [details]
Worksheet should open to problem area described above

Function Rank is not giving same rank for identical numbers, intermittent problem.

Worksheet "Ind ScoreYTD" Cell B111 and C111 have identical numbers to the precision displayed.  Cell F111 confirms they are identical.

Cell B112 and C112 were copied and pasted as values from the cells above.

Cells B113 and C113 had their values typed in.

Cells B114 to C116 show the results from the function rank.

The value should be 15 in each of these cells.  This is not the case.

Tested with an older version of LibreOffice which gave slightly different but also anomalous problems.  Tried to recreate the problem in a much simpler spreadsheet but could not duplicate the problem.

As we were discussing the problem internally we suspected that the variable may have extremely minor differences that are not visible when the cell is displayed and that Rank pick up but the boolean = function does not.  However this does not explain why we could not recreate this bug in another spreadsheet.  There are some differences in behaviour but still a problem on the same spreadsheet running on a slightly older version of LibreOffice on a different Win 10 computer (x64).  This made us suspect minor differences in the compiler or optimization level.

Version: 6.3.4.2 (x64)
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-CA (en_CA); UI-Language: en-US
Calc: threaded
Comment 1 m_a_riosv 2020-03-08 16:48:52 UTC
I get 15 on B114:C116 with 6.3 and with 6.4

Have you tested with a clean profile Menu/Help/Restart in Safe Mode
Comment 2 Oliver Brinzing 2020-03-08 16:52:01 UTC
reproducible with:

Version: 5.4.7.2 (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: single

Version: 6.4.2.1 (x64)
Build-ID: c92dba0b4728c0ec26c4b83e2c0fbf3284425375
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

    B   C
114 15  16

but *not* reproducible with:

Version: 4.4.7.2 (x86)
Build-ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Gebietsschema: de_DE

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 2020-03-06 19:40:12 +0100 (Fr, 06 Mrz 2020)
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: 

    B   C
114 15  15
Comment 3 m_a_riosv 2020-03-08 18:24:34 UTC
I can see it in 6.4 with a hard recalc.
I think it is in relation with limits precision, several works along the time to make it better.
Rounding values in column N to 14 decimals places gets a correct results for me.
I'm not sure it can be considered a bug.
Comment 4 Jake 2020-03-09 15:30:04 UTC
Today I cannot reproduce the problem with version 6.3.  We will round column N to 14 places to be safe.  Thank you.
Comment 5 m_a_riosv 2020-03-09 16:01:06 UTC
If happen again, please reopen.