[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
- Re: GUB and mpfr/mpc, (continued)
- Re: GUB and mpfr/mpc, David Kastrup, 2014/12/02
- Re: GUB and mpfr/mpc, Masamichi HOSODA, 2014/12/03
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/04
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/04
- Re: GUB and mpfr/mpc, Masamichi HOSODA, 2014/12/04
- Re: GUB and mpfr/mpc, Masamichi HOSODA, 2014/12/04
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/04
- Re: GUB and mpfr/mpc, Masamichi HOSODA, 2014/12/05
- Re: GUB and mpfr/mpc, David Kastrup, 2014/12/05
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/05
- Re: GUB and mpfr/mpc,
David Kastrup <=
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/06
- Re: GUB and mpfr/mpc, Masamichi HOSODA, 2014/12/08
- Re: GUB and mpfr/mpc, David Kastrup, 2014/12/08
- Re: GUB and mpfr/mpc, Dan Eble, 2014/12/08
- Re: GUB and mpfr/mpc, Keith OHara, 2014/12/21
Re: GUB and mpfr/mpc, Masamichi Hosoda, 2014/12/28