Re: [Help-gsl] Fwd: Modifying adaptive integration function
Just one last note, I assume you found this already, but the gsl_coerce_double() function is located in sys/coerce.c. You could try calling this function directly. On 05/11/2018 01: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. >
Re: [Help-gsl] Fwd: Modifying adaptive integration function
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.
Re: [Help-gsl] Fwd: Modifying adaptive integration function
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
Re: [Help-gsl] Fwd: Modifying adaptive integration function
> Hello,
>
> What exactly are you trying to do that QAG cannot? Perhaps there is
> an alternate way without rewriting the function.
I have to compute (for many t ∈ [0,1]) exp(∫_0^t f(x) dx), where lim_{x→1}
f(x)=-∞.
Any adaptive quadrature computing the integral will use many intervals near the
singularity, since it is the greatest source of errors; however, the
exponential actually makes most errors int that region negligible.
What about my other question? I.e. I noticed that `retrieve (workspace, &a_i,
&b_i, &r_i, &e_i);' is called at both the beginning and the end of the `do..,
while' iteration (lines 181 and 231), and the second call seems useless. Is
that correct?
Thank you
--
Francesco Florian
Re: [Help-gsl] Fwd: Modifying adaptive integration function
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
Re: [Help-gsl] Fwd: Modifying adaptive integration function
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 -- Francesco Florian On Monday, April 16, 2018 10:43:23 AM CEST Francesco Florian wrote: > Hello, > I'm currently trying to write a modified version of the functions in > integration/qag.c to solve a problem I have, but I ran into this problem: > qag uses the `GSL_COERCE_DBL' macro, which is defined in configure.ac (the > relevant code follows) > > #if HAVE_EXTENDED_PRECISION_REGISTERS > #define GSL_COERCE_DBL(x) (gsl_coerce_double(x)) > #else > #define GSL_COERCE_DBL(x) (x) > #endif > > How should I test my compiler (GCC) to get the right version to use? > > Moreover, I noticed that `retrieve (workspace, &a_i, &b_i, &r_i, &e_i);' is > called at both the beginning and the end of the `do.., while' iteration > (lines 181 and 231), and the second call seems useless. Is that correct? > Thank you >
[Help-gsl] Fwd: Modifying adaptive integration function
Hello, I'm currently trying to write a modified version of the functions in integration/qag.c to solve a problem I have, but I ran into this problem: qag uses the `GSL_COERCE_DBL' macro, which is defined in configure.ac (the relevant code follows) #if HAVE_EXTENDED_PRECISION_REGISTERS #define GSL_COERCE_DBL(x) (gsl_coerce_double(x)) #else #define GSL_COERCE_DBL(x) (x) #endif How should I test my compiler (GCC) to get the right version to use? Moreover, I noticed that `retrieve (workspace, &a_i, &b_i, &r_i, &e_i);' is called at both the beginning and the end of the `do.., while' iteration (lines 181 and 231), and the second call seems useless. Is that correct? Thank you
