code pointer - refining subtractions

hi @all,

[edit II by b. 2021-06-09]

  • had some success with correction for addition roundoff/-on fails, the classic ‘=0.1 + 0.2’ → 0.30000000000000004, hope it holds for other values, see attached screenshot ‘repaAdd’ - click to open, cells B34, C34,

  • would like / need some more testcases for roundon / roundoff fails in additions, who has some ready? (they normally don’t come into user sight as calc rounds and displays only 15 digits and the errors are very small, one ULP at max?, thus out of sight. '=rawsubtract(x, value(left(x,5))) helped me to make some cancellation fails visible,

  • and does someone have a code pointer for the preparation / rounding of values for display on screen and write to file? would like to try to give that one more digit …

[/edit II]

[edit by b. 2021-06-07]

@mikekaganski: the project contradicts some theses about fp inaccuracy you made and spreaded in the past, may i ask you to try to find errors in it? ‘advocatus diaboli’?

@all: with these patches calc will deviate from excel in some results … in direction ‘mathematically correct’. how to handle?
A: say ‘correct is better, the problem goes to … Redmont?’
B: make precise calculations optional? a switch / option ‘excel compatible’?
C: leave calc as it is and continue to declare mathematical accuracy impossible, superfluous and undesirable?

(if i got lost somewhere … be lenient, the intention was good, the work unfamiliar and difficult, and even if i hacked together cruel code and other bullshit … it shows that more is possible than calc delivers so far. (This is what gnumeric has been showing for decades, but this is a point that even the! precision fanatics par excellence haven’t solved yet?) Calc could possibly overtake Excel and! gnumeric? i like that idea … )

original question was:


i think i can put some better precision in some calculations, esp. improving subtractions which suffer from cancellation, but … i’m not a coder and not used to calc’s programming structure …

(did some tries replacing approxSub, as it’s defined in a ‘hxx’ file it didn’t let me define functions, tried to put it in math.cxx and ran into ‘not defined’ and missing access to other standards and plenty other errors … :frowning: ),

can anyone give me a pointer where the calculation for a simple subtraction starts, and which path it’s supposed to make through the modules and procedures? would be very nice …



(P.S. i know it’s more a ‘dev-question’, but at the moment not connected to a special bug, asked in tdf#124286, not yet answered, thus asking here too)

calc: are decimal correct calculations possible? - #4 by mikekaganski has the code pointer for the simple subtraction. And the implementation (ScInterpreter::CalculateAddSub in sc/source/core/tool/interpr5.cxx) for the simple case of not using array calculations does simple rtl::math::approxSub that you already found (at the very end of the method)

@mikekaganski: :slight_smile:
whow …
to say that was well hidden is not the understatement of the century … but in the ranking of the decade I see good chances for a medal …

@mikekaganski: that helped, thanks a lot, make your comment an answer, i’ll accept and upvote …

Just send the patch to gerrit, to enable review.

will do so, just on the way to clean out all my mistakenly attempts and make it ‘nice looking’. and checking if it qualifies as ‘intellectual property’ (free for free software, but would like a little fee from M$, google …). and have been working on addition roundoff/-ons, looks like ‘easily working’, see second screenshot added to question.
need to work out a clean separation between ‘add’ and ‘sub’ in interpr5, shouldn’t be too difficult but takes some time. and is sort of double / triple negation problem for the sign … need some quiet time for that.
if you - or somebody else - could provide some testcases for addition fails it could help, just 0.1 + 0.2 is a little weak and healing might be ‘by chance’. i have plenty cases for sub-cancellation, but only this classic for add. theoretically also ‘undershoot’ results might occur? would like to check if the routine holds for that.

checking if it qualifies as ‘intellectual property’ (free for free software, but would like a little fee from M$, google …)

All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license.

That’s all you may do. No other license restrictions that you could try to put on the code. It’s MPLv2/LGPLv3+, if you want it to get into LibreOffice.

tried to separate my changes in ‘functions’, like rawsubtract, in an attempt to:
a. have a better structure between original and patched, b. be able to test ‘in sheet’ how to best combine them …
as i’m not experienced in such i tried the simple stupid way, copied coding and declarations for rawsubtract and changed ‘rawsubtract’ to ‘rawsubtract2’ in every file where i found it. and added an entry with the next free number (500) in a list of numbered functions. the idea was to get a working ‘shell’ in which i can put and try my edits. compiles fine, but in sheet rawsubtract is ‘capitalised’ and evaluated, while rawsubtract2 is kept in lowercase and results in #NAME? … anyone an idea where i failed?

Just don’t do that. Simply modify the function(s) you want the way you want, and post the result to gerrit. It will enable checking and reviewing, instead of trying to guess a possible problem out of infinity possibilities.

Please STOP abusing this Ask site with this development-related question. You were already advised how to proceed.

good hint would have been: insert the new function before ‘#define SC_OPCODE_STOP_2_PAR 500’ as ‘xxxxxxxxxx 500’ and change ‘stop_2_par’ to ‘501’ in compiler.hxx.
why do i write this here? to spread knowledge and hope that it’s really possible for new people to learn about and dive into the code and change things … :slight_smile: and it’s fun and interesting and challenging on the level of a good computer game! … ‘not easy’.