Hi K.Frank
It's absolutely your (community) choice of course and fairly unproblematic
if you stay inside the mingw-w64 system.
It is however incompatible for MSVC compatibility even in case you never
touch long doubles, as it affects double precision computation. See
random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx
<http://blogs.msdn.com/b/dougste/archive/2008/11/12/random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx>
or https://github.com/numpy/numpy/issues/5194 . At least it is a matter of
documentation.
I would like to ask you for an item in the mingw-w64 FAQ to explain the
difference between the settings and how to choose double precision instead
(linking CRT_fp8.o AFAIK)
Cheers,
Carl
2014-11-24 15:01 GMT+01:00 K. Frank <kfrank2...@gmail.com>:
> Hi Carl!
>
> I very much think that 80 bits should be the default for
> long doubles, even if Microsoft does differently.
>
> On Mon, Nov 24, 2014 at 3:57 AM, Carl Kleffner <cmkleff...@gmail.com>
> wrote:
> > I don't see the point, why computation accuracy has to be set to 0x37f
> per
> > default. Usually computations are done with single or double precision
> > today. Using 80bit long double precision is outdated
>
> 80-bit long doubles are hardly outdated. Many people use
> them and rely on them.
>
> > and non portable.
>
> That's quite a specious argument, given x86 (and other)
> support for 80-bit precision dating back to the 8087.
>
> Sure, hardware support for 80-bit doubles is not portable across
> all platforms (nor is support for 64-bit doubles, nor for 32-bit
> doubles, etc., etc.), but that's no reason to make mingw-w64
> run suboptimally on very widespread hardware. The article by
> Kahan that Yaron linked to makes a very good argument (in the
> context of java) that exact compatibility / portability is a bad idea
> (and an illusory goal in any event). (He also has a few choice words
> about Microsoft's bad choice on this issue, as well he should.)
>
> > It is
> > just fine to have the possibilty to use 80bit longs doubles if needed
> (not
> > possible with MSVC). Nevertheless I suggest double computation precision
> > should be the default and extended double computation precision an
> option.
> > Silently change the FPU settings can cause bad side effects (see the
> link on
> > my first posting).
>
> Although polemical in tone, Kahan's explains things very well.
> Not using extended precision is sufficiently worse than using
> it that not doing so can be considered wrong.
>
> So, if Microsoft had a sqrt function that gave sqrt(16) == 5,
> would you ask that mingw-w64 do the same in the name of
> compatibility with Microsoft?
>
> On common modern hardware, float is 32 bits, double is 64 bits,
> and common modern hardware supports 80-bit doubles. long double
> is a different type from double. Why force long double and double
> to be the same 64 bits, when 80 bits is supported by hardware?
>
> You want 64 bits, use double. I want 80 bits, I'll use long double.
> Why make it hard (or impossible) for me to use 80-bit long doubles
> just because you want 64-bit doubles even if you accidentally type
> "long double"?
>
> Read Kahan. He is absolutely an expert in this kind of thing (and
> has been making these kind of arguments since before I was born,
> which is saying something).
>
> Mingw-w64 has the choice of doing what Microsoft does, or following
> Kahan's recommendation. Given that choice, it's Kahan, hands down.
>
> Trust me -- if you become an expert on numerical analysis and
> floating-point computation, you will agree with Kahan. But you
> don't need to become an expert -- just follow the experts' advice.
>
> (And if the experts' advice differs from what Microsoft and python
> and java, etc., etc. do, follow the experts' advice anyways.)
>
> >
> > 2014-11-23 17:39 GMT+01:00 Yaron Keren <yaron.ke...@gmail.com>:
> >>
> >> It is a real incompatibility between VC and mingw. Visual C++ dropped
> >> support for 80 bit long doubles on x87 many years ago, in VC long
> doubles
> >> are 64 bit, which is why they use 0x27F. mingw still supports 80 long
> >> doubles on x87. As long this is the case, it is incosistent for mingw
> to set
> >> computation accuracy to 0x27f.
> >>
> >> The 'long double' size incompatibility requires mingw to implement
> various
> >> long-double functions including printf and scanf, independently of
> MSVCRT.
> >>
> >> So the decision is whether long doubles should be 64 or 80 bits. The
> >> control word is simply the result of this decision.
> >>
> >> BTW. see Kahan about long doubles (in Java, though),
> >> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> Thank you Yaron -- this is an excellent reference. It's well worth
> reading (as is most anything by Kahan).
>
>
> Happy Floating-Point Hacking!
>
>
> K. Frank
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
