The following are the contents of the cells producing an error: b72:7,093 b73:97,686 b74:lessor of above 2 or 7,093 b79, 14% of b74 does not equal 13,676 it should be 993 The problem seems to be related to the test of cells b72 and b73. b72: 7,093 =0.75*D22 this is correct b73: 97,686 =C69*0.25 this is correct b74: 7,093 =IF(B72<B73,B72,B73) this is correct (least of above 2 amounts) Noted here: I received an error code complaining about number of iterations not being set so I set interations to 25 and error went away and the resulting test worked properly. What I didn't notice was: b79: =0.14*B74 produced 13,676 which is incorrect it should be 993 Fortunately the amount was great enough in difference it was easily spotted. If I go into cell b74 and set it to equal b72 (7,093) then the calculation works correctly. Cell b79 now equals 993. The problem seems to be associated with the test in b74.
Please attach a sample file.
Since there is need of a sample file(or a step by step explanation of how reproduce the bug) i change the state in NEED INFO.
Created attachment 125821 [details] The file with the problem. The person who had reported the bug contacted me by email because he wasn't able to login in bugzilla. He send me the file, which I have attached, and effectively the bug is present. To reproduce: -Change the value of cell E7 in the attached file -The value of the cell H79(=0.14*B74) changed in a wrong result If I save the file and reload it, the result is correct. I change the state to NEW. Affected version: Version: 5.0.6.3 Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: it-IT (it_IT.UTF-8) OS: openSUSE Leap 42.1 (x86_64)
What value to enter in E7 and what value must be the result in B79?
Created attachment 125835 [details] Screenshot of the error (In reply to m.a.riosv from comment #4) > What value to enter in E7 and what value must be the result in B79? In theory any value should be enter in E7, and the result in H79(not B79) must be the content of B74*0,14. After some other test I discovered that some times the value in H79 remain correct(equal to 0,14*B74) even after i change the value in E7 for the first time, but if i change the value in E7 again the value in H79 become incorrect. I noticed that some times the value don't change at all when i change the value in E7. I attached a screenshot of the incorrect value. In the screenshot B74=3713 so H79 should be equal to 519.82, but the result in the sheet is 46,725. For obtain that number I had changed the value of E7 to 550000 and the value of H79 changed correctly to 46,725(0,14*334) then I changed E7 to 560000 and the value of H79 remain 46,725. I think the problem is that the cell don't update correctly when the value of another cell is changed.
Is it solved with [F9] calculate or needs a [Ctrl+Shift+F9] hard recalculate. The has a recursive calculation, may be with a low value for Minimum change in Menu/Tools/Options/LibreOffice calc/Calculate/Iterative References.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
steps and values from comment #5 work fine with below mentioned ver., H79 is calculated to 519,86 (exactly 519,855) and not 519,82, but that may be an roundig issue, funnily H79 is 'off' from calculation after producing an error condition by switching iterations off, it gets '0' after re-enabling iterations, it comes back to values with 'hard recalc' (or other changes?), it's not the 'same' but similar to the behaviour of: https://bugs.documentfoundation.org/show_bug.cgi?id=129199 tested with: Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: b.
original complaint still ok in 6.4.0.1 CL-thr, but irregular behaviour of H79 'cut off' from recalculation after an error condition from comment #8 is still present, H79 comes to live again on new input changing B74 too, but - normally - should be calculated correctly when you re-enable iterations, will open a new bug for that, tested with: Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc:
*** Bug 129658 has been marked as a duplicate of this bug. ***
more problem(s) left ... with low values in E7 (definitively not the purpose of the sheet and not 'real life'; but a nice test to check the correctness of formulas and systematic inside calc) you get 0 as result in B74 and H79 for ~100.000 to ~540.000 in E7, below 100.000 B74 and H79 dont get final results, the iteration stops after two circles despite changes above the 'minimum change' limit, and it takes up to 10 manual triggered recalculations (strg-shift-F9) until B74 and H79 reach stable values. it's an effect of 'lagging behind' as described in other iteration bugs, e.g. 'bend_allowance' #81757 or 'silent, deceptive fail' #129199. it's easier to see when you format B74 and H79 to show more decimal places.
To get it straight for me Taxes payable (J11) should show $1.250.093 for E7 10000000. However the it starts with 1276160 and needs multiple hard recalculates (Calculate doesn't work) to solve Version: 7.0.0.0.alpha1+ (x64) Build ID: f9790da286f2d2fa47f1748f8cfa6172c6622ca3 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: de-CH (nl_NL); UI: en-US Calc: CL and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
@Eike, I thought you might be interested in this issue
No time for such thing. Iterations are a hairy soup.
Dear Ted Waugh, 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