| Summary: | Inconsistencies in RANK() function in Calc | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | ady <adylo811517> |
| Component: | Calc | Assignee: | Eike Rathke <erack> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | implementationError |
| Priority: | medium | ||
| Version: | 4.0.0.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:7.6.0 target:7.5.3 | ||
| Crash report or crash signature: | Regression By: | ||
|
Description
ady
2023-04-05 17:04:20 UTC
2.,3.,4. are clearly bugs. Whether #N/A would be better than #VALUE! depends, for query values not being numeric #VALUE! is appropriate. If a rank number is not found #N/A can be expected. Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/74d39f5cff324d76092268418028bd882d8a4d60 Resolves: tdf#154627 RANK() query value not in data must return error It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Pending review https://gerrit.libreoffice.org/c/core/+/150084 for 7-5 (In reply to Eike Rathke from comment #1) > 2.,3.,4. are clearly bugs. > > Whether #N/A would be better than #VALUE! depends, for query values not > being numeric #VALUE! is appropriate. If a rank number is not found #N/A can > be expected. Thank you. With: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 375f85f8518f49ce4381b6663f1e94fc02bacf93 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded Built: 2023-04-07 By using attachment 186403 [details], I immediately see points 0.3 and 1 solved, but points 2, 3 and 4 initially seemed still the same as they were before. I had to manually "Recalculate Hard" in order to see points 2, 3 and 4 being resolved. If I don't re-save the ods file, the previous results show up again when reopening. * Is the need for "Recalculate Hard" expected? * Is there still any/some case in which the result of any of the RANK functions would result in "-1"? * Could this bug 154627 be resolved / cherry picked for LO 7.4.7. too? Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/92ac45898fe6715b7dd5e12831af6f7d3df119e3 Resolves: tdf#154627 RANK() query value not in data must return error It will be available in 7.5.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. RANK should not be the same as RANK.EQ. Item 1 has broken a number of my spreadsheets. I am querying a range of values and want to what where a value not explicitly in the range would appear, had it been in the range. Now all I get is a column of NA instead of the position the search value would appear. I am reverting to 7.5.2. (In reply to Alex Doll from comment #6) > RANK should not be the same as RANK.EQ. Item 1 has broken a number of my > spreadsheets. > > I am querying a range of values and want to what where a value not > explicitly in the range would appear, had it been in the range. Now all I > get is a column of NA instead of the position the search value would appear. > Please explain (or point to some relevant source) how or why in your opinion RANK() should not be the same as RANK.EQ(). As for your needs (or "broken" spreadsheets), please attach a sample file. Regarding sensitive info in your file, please see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission ...before attaching it. |