[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gsl] Fwd: Modifying adaptive integration function
From: |
Francesco Florian |
Subject: |
Re: [Help-gsl] Fwd: Modifying adaptive integration function |
Date: |
Fri, 11 May 2018 09:35:45 +0200 |
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.
--
Francesco Florian