hey hey,
my learning curve goe's up ?!?! (all below 'WIP', may include errors).
I can confirm comments like:
'Long double support is experimental -- expect problems'.
in e.g. configure(.ac), but made some progress, see below.
autogen.sh or configure with '--with-long-double' went into errors for gnumeric (erfl, erfcl), see report at bottom of this post, but for goffice it worked, and defining: only! '#define GNM_WITH_LONG_DOUBLE 1' in 'gnumeric-features.h.in' without the other features survived make and install and changed something (not re-checked if already effective from changed goffice).
(found later: goffic has a similar switch in goffice/goffice-features.h.in)
improvement: :-) :-) :-)
'=0.1 + 0.2' now -> 0.300000000000000000010842022, the same as '=0.3'
that gives hope to enable less complex 'correction calculations' than i use yet.
Unfortunately, there is some water in the wine, the (much harder) error '=3.2 + 4.4' != 7.6 survives in long doubles, now in the form of -> 7.600000000000000000346945 instead of -> 7.599999999999999999913264.
And i lost my reference system, something in the process changed my 'standard' gnumeric from 1.12.50 to 1.12.51 :-(
But I have one more foot in the door, one more tool at hand, 'there is more'.
Questions:
- still how to build automated tests for calculations / features to avoid time consuming and error prone manual tests after each change,
- if i want to try 'go-accumulator' instead of long doubles as i need only a few calculations with better precision - how do i feed data there? I think 'SUM' which uses it is starting somewhere in range functions? But am missing a starting point to say e.g. 'add theese four doubles with higher precision' (and get a rounded double back).
- or can an experienced programmer provide a snippet that can be placed peacefully in a 'non-long' configured version, takes some doubles as input, converts them into long doubles, adds them with good precision, and converts the result back into a double.
(my correction calculations can even catch 3.2+4.4, but grew somewhat complex for that, having above possibilities at hand would be 'smarter'.)
Explanation:
'=3.2 + 4.4' != 7.6 is 'harder' (in doubles) because it consists of 'only' conversion deviations, adding up to more than 0.5 ULP, while '=0.1 0.2' is puzzled together from approximately the same approx. +39/64 ULP deviation induced by the operands, which is reduced in the binary range change from '-3' of the larger operand to '-2' of the result to ~19.5/64 ULP there and is only reflected in the result by the additional 0.5 ULP devia from the round-on in the addition. That last round-on can be calculated back, it is visible that! a FP error stepped in, and! in which direction (is the result rounded up or down). That isn't possible for 3.2+4.4 in doubles, no range change from bigger operand to result (both +2), thus no FP-'calculation error', not re-calculateable. In long doubles the error is calculateable, and can be corrected by just adding it to the result. The last makes me a little confused ...
Report about enabling long doubles:
goffice:
git checkout master
git checkout -b temporary_branch
./autogen.sh --with-long-double
cd ..
./WHENCE make -s goffice
./WHENCE install -s goffice
AFAIS no complaints,
( ? './WHENCE' ?: working with the setup proposed by John Denker having a separate development installation.)
gnumeric:
git checkout master
git checkout -b temporary_branch
./autogen.sh --with-long-double
after:
'checking checking for working erfl and erfcl... yes'
an endless loop of:
'= no
= no
= no
= no
= no
= no
= no
= no'
./configure --with-long-double
same error,
autogen.sh without long double, then make and install of gnumeric work,
and run well even 'on top' of the 'long activated' goffice,
