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