[Libreoffice-bugs] [Bug 143888] New: enhancement: CALCULATION: implement a function 'rawsum', working without prettyfying as rawsubtract does

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 143888
           Summary: enhancement: CALCULATION: implement a function
                    'rawsum', working without prettyfying as rawsubtract
                    does
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: newbie-02 at gmx.de

Description:
this is a twofold request, 
- for some improvements i'm going to propose i'd like to have better access to
the 'raw' IEEE / c-library calculation functions, 
- for the same purpose i need to learn how to throw patches into git. 

to check if a calculation scheme for e.g. rounding or 'kahaning' works well
it's much faster to test it in a worksheet than by coding - compiling -
testing. 

but multiple operations in Calc are 'prettyfied' with 'approx~' and/or
'snap-to-zero' and/or 'roundsig' functionalities which produce different
results than 'pure code', that often blocks meaningful evaluation. 

for subtractions @erAck implemented 'rawsubtract' some time ago. that can be
used for additions too ('rawsubtract(a,-b)' instead of 'a+b') but it's somewhat
error prone to work with additional negations. 

thus i'd like to implement a function 'rawsum' or similar which works without
prettyfying. i have a draft ready (cloned from rawsubtract), but would need
advice if it's 'all correct', and e.g. if and how rawsum might be defined for 
a: a single operand, 
b: arrays as input. 

there won't be many cases where rawsum differs from '+', but having a more
meaningful result than '0' for 
'=2.000000000000002 + -2.000000000000001' would be some help. 


Steps to Reproduce:
see above description, 
test e.g. '=2.000000000000002 + -2.000000000000001' -> '0' which is violating
IEEE 16 digit accuracy ... 
or check '=8.00000000000002 + -8', there the digits stay visible, 

Actual Results:
'0'

Expected Results:
'0.000000000000001' / '0.00000000000002'


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: b5eb15a21d89d5c4bb45122f68e68944ab8ffe42
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

-- 
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/20210815/2aac98b4/attachment.htm>