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
Eike, Mike, what do you think about this suggestion?
I'm unbiased. What comes next, RAWEQUAL()? Btw, > which is violating IEEE 16 digit accuracy is not true. There is no such thing. There's a theoretical *average* precision of 15.95 decimal digits (=LOG10(2^53)) but that doesn't hold true either. Read https://www.exploringbinary.com/decimal-precision-of-binary-floating-point-numbers/ Summarizes best with "The three reasonable answers are 15 digits, 15-16 digits, and slightly less than 16 digits on average. The safe answer is 15 digits."
> RAWEQUAL()? _is_ an idea, > 15 / 16 digit accuracy? in this range! the precision is some 16+ digits, 2.000000000000000, 2.000000000000001, 2.000000000000002, 2.000000000000003, 2.000000000000004, 2.000000000000005, 2.000000000000006, 2.000000000000007, 2.000000000000008, 2.000000000000009, and 2.000000000000010, are representable, and additional we have 2.0000000000000013, 2.0000000000000018, 2.0000000000000027, 2.0000000000000036, 2.0000000000000044, 2.0000000000000053, 2.0000000000000058, 2.0000000000000067, 2.0000000000000075, 2.0000000000000084, 2.0000000000000093, 2.0000000000000098,