Created attachment 177569 [details] La fonction NB.SI() donne des résultats pas toujours correct Voir le document en pièce jointe Avec le même jeux de données le résultat Libre Office diffère de celui d'Excel. Ce n'est pas toujours le cas le bug est aléatoire.
Please, language for this site is English. And usually images are not good to test the problem like in this case. Please can you attach a sample file.
Created attachment 177583 [details] Illustration du bug document calc
I can confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: bd5492275d31f59b1d269205018d1487af52426f CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo but not with Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Created attachment 177728 [details] test file test file created in excel with fixed values. The problem disappears after reload the file.
Created attachment 177731 [details] Libre Office Clalc Bug NB.SI() New testing with the last version of Libre Office The test result is unchanged
Repro in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 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 on 2023-04-21
What actually is the problem? Loading (and recalculating) attachment 177728 [details] has the correct result 4. Version: 7.5.4.0.0+ (X86_64) / LibreOffice Community Build ID: 748c1400a4408ad875d72044bb635524cfeddf4d CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8a9936e2f8a30cc24279f4a749984f15bd2aaec8 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Eike Rathke from comment #7) > What actually is the problem? STR: 1. Open attachment 177583 [details] from comment 2 2. [CTRL]+[SHIFT]+[F9] repeatedly until some numeric values in column D have their background color changed according to their conditional format. Step 2 might take several tries, but it will happen eventually. The BG color in column D shows repeating values, which in theory would only happen when there are repeating values in column A too, but it is clearly not always the case in attachment 177583 [details]. Thus, it would hint at some problem in COUNTIF(). I tried replicating the same situation with column A being integers (instead of [0...1], and it was clearly less likely to happen. So, is this because natural accuracy issues? IDK. (FWIW, bug 151958, also related to COUNTIF() doesn't seem to be related to accuracy.)
(In reply to ady from comment #8) > (In reply to Eike Rathke from comment #7) > > What actually is the problem? In addition to the strange results from COUNTIF(), by copy+pasting the original random values from attachment 177583 [details] from comment 2 as fixed values, then saving as new file and reloading, the correct results for countif() are shown, but not with recalculate hard. So, recalculate hard generates different countif() results than save+reload (not related to rand()).
Still repro with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9a555d79b3b00793edf1d51a8a7c76b723cc436d 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-27
Dear GDH, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug