3.1 status report

[David Bateman]

Dmitri A. Sergatskov wrote:
> On Wed, Jul 16, 2008 at 5:04 PM, David Bateman <adb014 at gmail.com> wrote:
>   
>> Jaroslav Hajek wrote:
>>
>>     
>>> I see, however, a couple drawbacks:
>>> 1. most of GSL uses hard-coded double as the real type. Now that we
>>> have true single precision, this is really a big drawback. I don't
>>> reckon there are plans to change this state in GSL. And I can't see
>>> any good way out of this.
>>> 2. the "core" linear algebra operation of the MINPACK algorithms
>>> (trust-region Levenberg-Marquardt and Powell's hybrid method) is the
>>> QRP factorization. GSL has its own QRP code (as well as other linear
>>> algebra codes) and employs it here. I think, however, that LAPACK is
>>> fairly better.
>>>       
>> To me these are both good reasons not to use GSL. What I thought we were
>> gaining with GSL was
>>
>> * upto date and maintained code
>> * code that generally performed better
>> * code that returned valid results for a wider range of input values.
>>
>> Though given the two points above I'm not sure GSL is worth it.
>>
>>     
>
> I guess one option is to lift the relevant code from GSL and adapt
> it for octave data type and lapack. I think it is still better than carry
> along the old Fortran code.

Ultimately it would be better if we could get the GSL maintainers to 
reintegrate any such changes and support it themselves. Both float and 
accelerated lapack libraries make sense for GSL to support and so I 
think its probably a bad idea to bring this code into Octave itself.

D.
> de.
>