lmi
[Top][All Lists]
Advanced

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

Re: [lmi] MinGW-w64 anomaly?


From: Vadim Zeitlin
Subject: Re: [lmi] MinGW-w64 anomaly?
Date: Mon, 19 Dec 2016 01:38:27 +0100

On Sun, 18 Dec 2016 22:18:07 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-18 20:54, Vadim Zeitlin wrote:
...
GC> > [End of the digression]
GC> 
GC> Thank you very much.

 I'm glad it was useful, I was afraid I just wasted a lot of time
unnecessarily...

GC> Then the anomaly really is upstream, in libstdc++.

 They don't seem to think it's an anomaly, at least according to the first
response I got to my bug. But maybe I didn't explain things clearly enough.

GC> Yet I really do want long doubles.

 This is the part which worries me because it means that either lmi will
need to continue to use x87 forever or will need to using something
non-standard like __float128. Shouldn't 52 bits of precision be enough for,
well, basically anything?

GC> This discussion leads me to think that instead of hoping for std::pow()
GC> to do exactly what I want, I might try [untested sketch]:
GC> 
GC> long double lmi_powli(long double base, int iexp)
GC> {
GC>     if(i < 0)
GC>       return 1.0L / lmi_powli(base, -iexp);
GC>     else
GC>       return std::pow(base, iexp);
GC> }
GC> 
GC> Then, when 'base' has an exact integer value, a standard-conforming
GC> implementation is at least highly likely to do what I want.

 Yes, I agree, this should indeed fulfill your requirements.

GC> It's probably time to reveal my motivation, which is to modernize and
GC> simplify 'round_to.hpp'. I didn't want to state that earlier because
GC> that file will soon become smaller and much clearer.

 I'm definitely looking forward to it, this is not a part of lmi I really
like delving into right now.

 Good luck!
VZ


reply via email to

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