[Top][All Lists]

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

Re: [Help-gsl] test release for GSL 2.4

From: sisyphus1
Subject: Re: [Help-gsl] test release for GSL 2.4
Date: Fri, 23 Jun 2017 20:41:18 +1000

From: Max Gaspa
Sent: Friday, June 23, 2017 7:50 PM
To: address@hidden
Cc: address@hidden
Subject: Re: [Help-gsl] test release for GSL 2.4

sisyphus1 wrote

This would make it a bug in the mingw runtime, right ?

I wouldn't agree with you. The difference you are observing is related to the computation of sin(x) and cos(x) at compilte time (using MPFR) when optimization is used. Without optimization the sin(x) and cos(x) are computed at runtime using sin and cos from the runtime library provided by Microsoft (not MinGW64). MinGW is just providing import libraries for the Microsoft Runtime dll.

Try to input, in your test case, the value of x using scanf, instead of assigning the value during declaration. You get wrong values regardless the used optimization flag, because now sin and cos are computed at runtime even using optimization.

Yes, as I said in my last post:

The key to getting the correct result is in doing the calculations at compile-time. If the calculations can't be done at compile-time, then you get an incorrect result (irrespective of optimization level).
[end quote]

So I think we're agreeing there.

In my humble opinion the "bug" (I mean bad sin(x) and cos(x) values)

1) is not in GSL
2) is not in MinGW64
3) is due to the older runtime library provided by Microsoft in the OS

Your first point is certainly correct.
You could well be right about points 2) and 3) as well. It's not unusual for me to be wrong.

Now I am compiling GSL 2.4 (latest commit) using the newer Microsoft Runtime DLL, I hope to fix the failing test during "make check".

If that fixes the problem, then I think that would pretty much prove that the bug is in the MS runtime.
So please let me know how that goes.


reply via email to

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