Bug 136897 - Convergence check in iteration prevents lots of uses of iteration (anti-feature)
Summary: Convergence check in iteration prevents lots of uses of iteration (anti-feature)
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.6.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-20 01:36 UTC by hardcoder
Modified: 2024-03-12 06:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of a file which works perfectly in recent MS Office versions. (20.23 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2020-09-20 01:47 UTC, hardcoder
Details
String iteration experiments (9.91 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-11-26 17:15 UTC, hardcoder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hardcoder 2020-09-20 01:36:58 UTC
Description:
Iterative calculation is an already old feature to many traditional spreadsheet apps, but LibreOffice has something more on topic. It tries to detect whether variation between iterations goes beyond certain limit, and tries to hide the result of the iteration if it judges it is not converging, using a very basic checking. IMHO this checking it otiose/superfluous and is only here to prevent some real applications of iteration. Iteration is a really powerful feature; you could built an emulator out of it.

Steps to Reproduce:
1. Open a new spreadsheet
2. Go to Tools > Options... > LibreOffice Calc > Calculate
3. Enable "Iterations". I recommend to bump up the "minimum change" to the modest amount of 1E+308, to minimize your problems. Observe how many iterations are set.
4. In cell A1, type =A1 + 1
5. Try throwing F9s (recalcs), whether or not A1 is the selected cell (results may vary).
6. Try to rationalize why LibreOffice Calc is behaving that way (I failed at that point).
Bonus track. In cell A2, put =A2&"a" . See if a string of a's appear, as it would on Office for instance, at every recalc.

Actual Results:
Even though iterations is set as 100 steps here, A1 sometimes advances 2 cycles (when selected), sometimes doesn't advance. A2 simply yields Err:523 (not converging). Well, I'm asking for a string output to be built; who cares if it doesn't converge?

Expected Results:
It should work more like WPS Office Free, or Office 2010+ for Windows. Fortunately those programs have no obligatory convergence check on iterative calculations.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.6.2 (x64)
Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 1 hardcoder 2020-09-20 01:47:23 UTC
Created attachment 165694 [details]
Example of a file which works perfectly in recent MS Office versions.

This is an Excel simulation of Conway's automaton, or Conway's game of life. First you check your iteration settings according to the grey header text. Then you uncheck 'Reset', and press F9 (recalc) to make the model advance.
Comment 2 Telesto 2020-09-20 21:11:38 UTC
@Eike
They iteration topic is beyond me; and I recall something about being hairy soup.
Comment 3 hardcoder 2020-09-23 19:11:57 UTC
Your iteration's "Minimum change" was likely born as a misinterpretation of Excel's iterative calculation "Maximum Change".

This feature has been neglected in LibreOffice for a long time, as I noted in a less polite report attempt: https://bugs.documentfoundation.org/show_bug.cgi?id=126866
Comment 4 Xisco Faulí 2021-11-23 11:10:07 UTC
Hello hardcoder,
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 5 hardcoder 2021-11-26 02:14:25 UTC
(In reply to Xisco Faulí from comment #4)
> Hello hardcoder,
> Could you please try to reproduce it with the latest version of LibreOffice
> from https://www.libreoffice.org/download/libreoffice-fresh/ ?
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the bug is still present in the latest version.

Do you prefer that I get the 7.3.0 prerelease? Or should I stick to 7.2.3 fresh?
Comment 6 QA Administrators 2021-11-26 04:45:04 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2021-11-26 10:20:34 UTC
(In reply to hardcoder from comment #5)
> (In reply to Xisco Faulí from comment #4)
> > Hello hardcoder,
> > Could you please try to reproduce it with the latest version of LibreOffice
> > from https://www.libreoffice.org/download/libreoffice-fresh/ ?
> > I have set the bug's status to 'NEEDINFO'. Please change it back to
> > 'UNCONFIRMED' if the bug is still present in the latest version.
> 
> Do you prefer that I get the 7.3.0 prerelease? Or should I stick to 7.2.3
> fresh?

7.2.3 should be fine
Comment 8 hardcoder 2021-11-26 16:25:10 UTC
Short answer: the bugs are still there.

Sorry for the delay; weak Internet connection.

So, I just upgraded and reproduced the steps I wrote earlier. I couldn't detect any change in behavior, it's all the same.

Also, some time ago I discovered that the number of iterations is correctly applied on iterated string concatenation, even though it is disregarded for numbers.

But even though the calculation may advance behind the scenes with Recalculate Hard (ctrl+shift+f9), or Recalculate (only when selecting the iterative cell), again, Err:523 is hindering the usefulness of the calculation. Even another cell referencing the value (e.g. =A2) also splashes Err:523.

Version: 7.2.3.2 (x64) / LibreOffice Community
Build ID: d166454616c1632304285822f9c83ce2e660fd92
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 9 hardcoder 2021-11-26 17:13:37 UTC
I discovered a trick to observe string iteration. If the string's length varies, you won't be able to see it, because any string size change under iteration triggers Err:523 (even if the string shrinks). But if you interleave rest states into the string calculation, you can see the string (half of the time):

1. Create a new spreadsheet in Calc.
2. Make sure iteration is enabled in Options.
3. On A1, enter: =MOD(A1+1,4)
This will make the value of A1 swap between 1 and 3 on recalcs (unless the number of iteration steps is 1).
4. On A2, enter: =IF($A$1=1, A2, A2&"a")
5. Optional: on A3 enter: =LEN(A2)
6. Press Ctrl+Shift+F9 a number of times. If you just press F9, only the selected cell among the iterative ones will be updated, which is yet another incompatibility with Excel, but who's caring.

From here, the result is that A2 alternates between Err:523 and 0aaaaaa...
Comment 10 hardcoder 2021-11-26 17:15:48 UTC
Created attachment 176530 [details]
String iteration experiments
Comment 11 hardcoder 2022-03-06 21:29:21 UTC
I just downloaded and installed LO 7.3.1.3 from https://downloadarchive.documentfoundation.org/libreoffice/old/latest/win/x86_64/ and checked the iteration bugs, and it all seems the same.

Bugs include:
- Err:523 hiding the results (anti-feature).
- For strings, Err:523 when it grows or shrinks in length, only not when the length doesn't vary. String content seems to be irrelevant in this aspect.
- For numbers, the number of iterations is 3 at the first time, then 2 (except if the number of iterations is set to 1).
- When the formula is NOT converging, the correct number of iterations (set in Options) is applied (this can't be directly seen; only when the value is not changing anymore).
- All the iteration steps are calculated at a time for a cell, then for other cell, and so on (incompatible behavior). In MS Excel, an iteration is calculated for all cells (apparently even those in other workbooks, as long as they are open), then another iteration, etc. (The Excel behavior is more useful IMHO.)

Also, I wrote some comments in bug 129658.

Version: 7.3.1.3 (x64) / LibreOffice Community
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 12 LizaVersy 2024-01-26 11:48:09 UTC Comment hidden (spam)
Comment 13 hardcoder 2024-01-26 19:06:33 UTC
(In reply to LizaVersy from comment #12)
> Thanks for reporting this issue.
> A new major release of LibreOffice is available since this bug was reported.
> Could you please try to reproduce it with the latest version of LibreOffice
> from https://litaviser.com/
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the bug is still present in the latest version.
litaviser.com? I visited the site, and looks like an empty landing site offering itself for sale (possibly expired). I have LO 24.2.0.2 on my Win11 laptop, downloaded from https://downloadarchive.documentfoundation.org/libreoffice/old/ .

Short answer: nothing changed, except for a subtle behavior regarding iterated strings (see below).

Revising bug claims:
> - Err:523 hiding the results (anti-feature).
Still there, whenever Calc judges the variation is too large, a simple but limiting "convergence" check that MS Excel and other software don't have.

> - For strings, Err:523 when it grows or shrinks in length, only not when the length doesn't vary. String content seems to be irrelevant in this aspect.
When doing iterated string concatenation, now sometimes Err:523 sticks and hides the result even when the added string is blank and the accumulated string isn't growing anymore (worse than before). But if you go to Options dialog and change the "Minimum change" field to whatever else, Err:523 is a string cell gets inhibited in case the value is not changing (head-scratcher).

> - For numbers, the number of iterations is 3 at the first time, then 2 (except if the number of iterations is set to 1).
Still there, apparently like before.

> - When the formula is NOT converging, the correct number of iterations (set in Options) is applied (this can't be directly seen; only when the value is not changing anymore).
Still there, apparently like before.

> - All the iteration steps are calculated at a time for a cell, then for other cell, and so on (incompatible behavior). In MS Excel, an iteration is calculated for all cells (apparently even those in other workbooks, as long as they are open), then another iteration, etc. (The Excel behavior is more useful IMHO.)
Still there. You can confirm that with:
A1: 0
A2: =A2+A1
A3: =A3+A2
Always take note of the value of A3 before recalc'ing. Then change A1 to 1; A2 will change a repeated number of times, all BEFORE updating A3 with intermediate values of A2. Only later, A3 is updated based on the last value of A2. MS Excel has a different behaviour, like I said.

> Even another cell referencing the value (e.g. =A2) also splashes Err:523.
Still there, apparently like before.

Also: In Calc, iterative cells are kind of "non-volatile"; if you simply throw a recalc, they are not updated unless selected. If you do a "recalc hard", they are all updated. (Same behaviour as before.)


Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (C); UI: en-US
Calc: threaded
Comment 14 Telesto 2024-01-27 08:03:08 UTC
(In reply to hardcoder from comment #13)
FYI: comment 12 is a spam post
Comment 15 aickymoriarty0509@outlook.com 2024-03-12 06:43:34 UTC Comment hidden (spam)