lilypond-devel
[Top][All Lists]
Advanced

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

Re: GUB and mpfr/mpc


From: David Kastrup
Subject: Re: GUB and mpfr/mpc
Date: Sat, 06 Dec 2014 15:12:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> On Dec 5, 2014, at 06:22 , David Kastrup <address@hidden> wrote:
>> 
>> Masamichi HOSODA <address@hidden> writes:
>> 
>>> Therefore, robust treating for margin of error is necessary.
>> 
>> That does not help all that much: it just shifts the problem somewhere
>> else.  It will tend to fix known test cases and create a new set of
>> previously working failures.
>> 
>> Instead the algorithms have to be rewritten in a manner where their
>> termination does not depend on the reproducibility of floating point
>> operations.  There have been a few attempts of rewriting skyline code
>> that have fixed/created some problems without any real insights into
>> what caused the fix and what caused the new problems.
>
> I’ve only skimmed some web pages on this subject, but if the following
> can be tolerated, it seems like the simplest way to reduce pain in
> short order:
>
>     On more modern x86 processors that support SSE2, specifying
>     the compiler options -mfpmath=sse -msse2 ensures all float
>     and double operations are performed in SSE registers and
>     correctly rounded.
>     [https://gcc.gnu.org/wiki/FloatingPointMath]
>
> It worked for my example program.

"It will tend to fix known test cases and create a new set of previously
working failures".

I think there is a less architecture-dependent option that keeps gcc
from using any extra precision for intermediate results but it may be
somewhat expensive.  On the other hand, numerics are not where LilyPond
spends most of its time.

Probably

'-ffloat-store'
     Do not store floating-point variables in registers, and inhibit
     other options that might change whether a floating-point value is
     taken from a register or memory.

     This option prevents undesirable excess precision on machines such
     as the 68000 where the floating registers (of the 68881) keep more
     precision than a 'double' is supposed to have.  Similarly for the
     x86 architecture.  For most programs, the excess precision does
     only good, but a few programs rely on the precise definition of
     IEEE floating point.  Use '-ffloat-store' for such programs, after
     modifying them to store all pertinent intermediate computations
     into variables.

would do the trick.  But we really rather should try to become
independent from exact equalities as algorithm terminators.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]