[Top][All Lists]

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

Re: [Help-gsl] Fwd: Modifying adaptive integration function

From: Patrick Alken
Subject: Re: [Help-gsl] Fwd: Modifying adaptive integration function
Date: Fri, 11 May 2018 13:12:59 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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:
>> #define GSL_COERCE_DBL(x) (gsl_coerce_double(x))  // used with gcc 
>> #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 
> Patrick Alken's answer seems to suggest it is ok not to match QUADPACK 
> results; if it is correct it would work for me.

reply via email to

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