Boost logo

Boost :

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-29 05:24:47

Somewhere in the E.U., le 29/05/2001


--- In boost_at_y..., Peter Schmitteckert (boost) <boost_at_s...> wrote:
> Salut,
> > > for x=sqrt( sqrt(epsilon) ), the x*x will be of the order of epsilon,
> > > due to the small prefactor of the next term, you could extend my idea
> > > even to pow( eps, 1/6 ), when x^6 = epsilon.
> >
> > OK. I'll add one or more zones where I compute the result via
> > Taylor expansion That really seems necessary. I'll see if the
> > continuity matching zones are really necessary too, however.
> I'm not quite sure if I understand you correctly, what do you exactly
> mean with 'continuity zones' (the plural). One for each function, or several
> for one function ?

                The terminology may not be the correct one, but what I meant
was the following:

                If I create a piecewise approximation to a function, say with
one definition on [0;1] and another on ]1;2], then there is a risk of
discontinuity at 1, and that's bad if what I intended to model was in
fact continuous. So instead I find one approwimation on [0;3/2],
another on [1/2;2], and interpolate between the two approximations on
[1/2;3/2] (which I called the "continuity" or "matching" zone). This
generalises readilly.

                We get better (order-0) behaviour, at the cost of more
computation (especially in the matching zone).

> > > I was only confused, that's all. SInce you introduced the sinc_a family,
> > > I was always searching for one a != pi.
> >
> > Slated for later, provided this library doe make the cut.
> What is the advatage of sinc_a(x) ? To address rounding problems for very
> large x ? Then it would be more important to improve sin(x) for very large
> arguments.

                The main interest of this particular member of the family is
that it requires fewer computations, and that, in itself it is a
special function as it is far more common than its brethren.

                That being said, improvements to sin and other common
functions are indeed needed in legion. Apart from accuracy for large
values, and the fact that it is not templated (I am still not sure
::std::sin always picks up the best underlyingimplementation for its
signature), there are specialized, yet immensely common, occurences
such as computing a great many values for extremely close values of the
argument (to draw a circle for instance) that are not taken into
account (I do have a good solution to this one, though).

                We are just standing at the foot of the numerics pyramid.
There's work, literraly, for years to come.

> >
> > Amicalement
> Someone writing sources for octonions had to be a french person.


> Amicalement
> Peter Schmitteckert


                        Hubert Holin

Boost list run by bdawes at, gregod at, cpdaniel at, john at