[Libreoffice-bugs] [Bug 128329] WORK: 'incomplete autocalculations' - cooperation of autocalculate and shared formulas / formulae still broken in LO calc ver. 6.2.7.1 with *threaded* calculation on

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=128329

--- Comment #6 from b. <newbie-02 at gmx.de> ---
@Telesto: 

to be or not to be ... a bug ... that's the question ... 

imho a bug is when the results of a program deviate from intended and defined
calculation, in ancient times this was sometimes caused by physical bugs
between contacts of relays, thus this behaviour got its nickname, but the
nickname is used for wrong (buggy) results 'in general'!

we don't use open relays anymore, thus there are no real bugs to point to, 

some bugs are easy, some sporadic and hard to spot, but they are! 

it is difficult to ensure the quality of a program if you limit yourself in the
processing of errors. 

the requirement for an example (file) excludes runtime errors, the requirement
for repeatability excludes sporadic errors, the requirement for
'bibisectibility' excludes all problems introduced from OO ... and so on... 

i see weaknesses in the scheme of how LO currently operates, it is a good way
to avoid too much deterioration, but not to produce real quality: 
- in a timely manner, 
- in general, and 
- verifiable

if such an error occurs and is documented... screenshot... someone who can do
that would have to look at the corresponding code and analyse if it can make
mistakes ... or not. it's not easy, but it has to be, otherwise we won't get
rid of all these 'shared formula' - 'autocalculate' errors, and they undermine
calc since version 4.2, for over 6 years. 

the whole thing might not have happened if someone had written enough unittests
back then, but that (probably) didn't happen.
https://www.slideshare.net/kohei101/life-after-calc-core-change - slide 25. 

an idea how to check against - some - mistakes that got unnoticed: 

a routine that extracts a 'fingerprint' (hash value?) from a complete calc map,
each cell is somehow calculated so that changes in it change the result, 

a routine that takes this hash value, triggers a hard recalc, takes the hash
again and compares it with the first one. hard recalc is quite reliable
according to @Eike and my experience (not absolute, i mean i had a case where
it didn't help the other day) but you could easily distinguish 'probably
error-free' against 'contains calculation errors'. if errors ... go after them
...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200617/73de2740/attachment-0001.htm>