On 5/11/2018 12:35 AM, Francesco Florian wrote:
On Thursday, May 10, 2018 8:17:47 PM CEST lostbits wrote:
On 5/10/2018 8:08 AM, Patrick Alken wrote:
On 05/10/2018 04:18 AM, Francesco Florian wrote:
Hello!
Since I have received no answer, I wonder whether this is the right
mailing list for this question. If it is not, can you please point me
to the right one?
Thank you
Hello,
What exactly are you trying to do that QAG cannot? Perhaps there is
an alternate way without rewriting the function. My guess is you could
get away with just removing the GSL_COERCE_DBL wrappers from the code,
but it may not match the original QUADPACK results, according to the
comments in qag.c.
Patrick
My guess is that gcc -DHAVE_EXTENDED_PRECISION_REGISTERS ... would
define the pre-process variable, if that's what you want. If you do
nothing then the variable is not defined. More to the point:
#if HAVE_EXTENDED_PRECISION_REGISTERS
#define GSL_COERCE_DBL(x) (gsl_coerce_double(x)) // used with gcc
--DHAVE_EXTENDED_PRECISION_REGISTERS
#else
#define GSL_COERCE_DBL(x) (x) // used without defining the variable
#endif
I was looking for a way to check if the compiler actually supports it. The
method above seems to rely on me knowing that, and then passing
-DHAVE_EXTENDED_PRECISION_REGISTERS to gcc if appropriate.
Patrick Alken's answer seems to suggest it is ok not to match QUADPACK results;
if it is correct it would work for me.
The compiler does support -D...The code probably supports the option
also. If the code has a function gsl_coerce_double then the coe supports
the option. As to the correct functionality, to wit, the code is correct
but the operations are incompatible, perhaps the easiest way to to this
check is to compile and execute and observe (or digitally check) the
results. I am not knowledgeable on the options and don't know enough
other than to suggest that you try and check.
