Re: Hubble cst as absolute error for integration

From: Johan Maes <>
Date: Fri, 20 Mar 2009 12:19:07 +0100

Hm apparently the approximation is ok if either one of the error limits
is satisfied:

/Each algorithm computes an approximation to a definite integral of the
form, /

/I = \int_a^b f(x) w(x) dx

/ where w(x) is a weight function (for general integrands w(x)=1). The
user provides absolute and relative error bounds (epsabs, epsrel) which
specify the following accuracy requirement, /

/|RESULT - I| <= max(epsabs, epsrel |I|)

/ where RESULT is the numerical approximation obtained by the algorithm.

/So, in order to make the absolute error a dummy, one could just set it
to 0....right?

/Johan Maes wrote:
> Hi all,
> This may be a minor thing, well this is a minor thing, but still, I'm
> wondering why in init_drift_table (in driftfac.c), the Hubble constant
> is used as absolute error for the integrations. Here's a description
> of adaptive gsl integration taken from
> /This function applies an integration rule adaptively until an
> estimate of the integral of f over (a,b) is achieved within the
> desired absolute and relative error limits, epsabs and epsrel
> /
> In the code it says the absolute error is just used as a dummy, so I
> guess the goal is to make it as big as possible (compared to the
> result) so the above is always ok. But since the results have
> dimension of time, I would rather expect some fraction of the Hubble
> time then...what am I missing here? I'm doing something similar now to
> convert a to t, using the integration in Gadget as an example, that's
> why I noticed.
> Thx & cheers,
> Johan
> --
> En toen zei de kikker: "Voor mij ne kleine me stoverij, alstublieft."

En toen zei de kikker: "Voor mij ne kleine me stoverij, alstublieft."
Received on 2009-03-20 12:40:57

This archive was generated by hypermail 2.3.0 : 2022-09-01 14:03:42 CEST