From bug-request at octave dot org Thu Nov 24 12:50:01 2005 Subject: Re: trigonometric and hyperbolic functions From: Paul Kienzle To: "John W. Eaton" Cc: William Poetra Yoga H , bug@octave.org Date: Thu, 24 Nov 2005 13:49:02 -0500 John, The main reason I see for using GSL is that it provides many of the underlying functions that Octave, SciPy, R, etc. need and that we should be pooling our efforts to create a common infrastructure which can therefore be more complete, more robust, better tested and use the best algorithms available. I can understand your reluctance to add dependencies to the octave core. Fortran, readline and gnuplot already cause enough maintenance problems on OS X systems. Still, you could ship a subset of GSL in libcruft in lieu of blas, lapack, ranlib, minpack, quadpack and maybe some of the ODE solvers. This assumes of course that someone steps up to patch liboctave to use GSL instead of netlib, but they will want some indication if you would be interested in such a patch before starting. I don't know if GSL is there yet in terms of numerical accuracy and speed of all its functions. For example, last I looked they were not using Marsaglia's ziggurat for their normal RNG, though they may be by now. Rather than implementing this in octave-forge for octave only like we have, putting it in GSL and wrapping GSL in octave makes it available to the larger community. Similarly for sqrtm, expm, powm, and any other significant algorithms we have implemented in C/C++ for Octave (m-files are a separate issue). - Paul On Nov 24, 2005, at 9:47 AM, John W. Eaton wrote: > On 24-Nov-2005, William Poetra Yoga H wrote: > > | --- "John W. Eaton" wrote: > | > | > I'd rather not do that, since it is more work for us to include > | > external packages in the distribution. Should we also include > copies > | > of ATLAS, fftw, ufsparse, etc.? > | > > | > | But Octave doesn't depend on those... If we make Octave use GSL > | functions (as in being dependant on GSL for core functions), we > | could do this (or better, the alternative I say below). > > Yes, it does. Without them, you can't have full functionality. > You can't build Octave at all without some version of blas+lapack > (though we do currently include the reference blas+lapack, but you > really should be using ATLAS instead). > > | > Yes, Octave does currently include some external software, but I'd > | > like to minimize that if possible, and perhaps even eliminate some > of > | > the things that are currently included. > | > | Well, what about only making it a requirement for those who build > | from source, and provide a statically linked binary for those who > | don't want to compile from sources? > > Binary for what platform? Distributing binaries is something that is > better handled by people who build packages for various systems. > > | Using GSL can slim Octave down, for example by replacing functions in > | libcruft/blas (well, not everyone uses ATLAS...). > > What are the reasons for preferring the GSL lapack+blas implementation > over ATLAS? > > jwe > > > > ------------------------------------------------------------- > Octave is freely available under the terms of the GNU GPL. > > Octave's home on the web: http://www.octave.org > How to fund new projects: http://www.octave.org/funding.html > Subscription information: http://www.octave.org/archive.html > ------------------------------------------------------------- > ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------