Aw: Re: where can / must one activate 'LONG DOUBLES'? - works to some extend, feedback and additional questions

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. 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 '' 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/
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'.

- 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'.)

'=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:
git checkout master
git checkout -b temporary_branch
./ --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.)

git checkout master
git checkout -b temporary_branch
./ --with-long-double
'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, without long double, then make and install of gnumeric work,
and run well even 'on top' of the 'long activated' goffice,
i am extremely grateful for all the help and hope i can reflect something back with the feedbacks.

best regards,

Gesendet: Sonntag, 19. September 2021 um 03:03 Uhr
Von: "Morten Welinder" <mortenw gnome org>
An: "newbie nullzwei" <newbie-02 gmx de>
Cc: "Gnumeric Forum" <gnumeric-list gnome org>
Betreff: Re: where can / must one activate 'LONG DOUBLES'?
configure --with-long-double

(or --with-long-double if you are running from the git tree
which, since you were looking for the test suite
the other day you should be)

goffice will need to have been compiled with --with-long-double also.

Note: this code path isn't tested terribly often.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]