Re: [submit] gsl_interp_polynomial, gsl_polynomial types

["Dan, Ho-Jin" <hjdan at sys713 dot kaist dot ac dot kr>]

I have a trouble in building cvs sources as

Making all in interpolation
make[2]: Entering directory `/usr/local/gnu/src/cvs/gsl/interpolation'
make[2]: *** No rule to make target `poly.c', needed by `poly.lo'.  Stop.
make[2]: Leaving directory `/usr/local/gnu/src/cvs/gsl/interpolation'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/gnu/src/cvs/gsl'
make: *** [all-recursive-am] Error 2

poly.c couldn't be found in the cvs tree. what's wrong?

By the way, I found the line search (one dimensional min.) routines
are difficult to use in the multidimensional optimization. For example,
gsl supplied unconstraint min. routines have its own directional minimizer.
I have also similar one for me (quadratic or brent minimizer).
One-D directional minimizers seems to be collected into one-dimensional
minimization category which has routines for minimizing f(x) on [a, b]
and finding the interval [a, b]. I think that one-D directional minimizer
is carefully organized to minimizer the number of the object function call,
practically, calling objective function are expensive except the 
mathematical
functions. I attache the experimental source for directional search.
in min_quad.c, commented out main funcition has simple usage for it.
for complex application, steepest-descent.c is provided.

in summary, directional line search controlled with the trial step size
is needed in the future.


Brian Gough wrote

>
>I haven't added the gsl_polynomial functions -- generally I like to
>keep GSL routines at a fairly low-level. In this case it should be
>sufficient for the user to pass the array of coefficients to the
>low-level gsl_poly routines or use gsl_spline.
>
yes, indeed low-level routines are sufficient in this case.

>
>
>Brian
>
>

Attachment: directional_min.tar.bz2
Description: BZip2 compressed data