JDQR ?

[David Bateman]

Søren Hauberg wrote:
>> The downside is that jdqr is a rather long and messy m-file, with lots 
>> of functions for iterative sparse solvers that should be in Octave 
>> independently of jdqr itself. You also should try and get a better 
>> preconditioner into Octave if you want to go this way. So its not a 
>> trivial amount of work.. The code was written in 1998 and doesn't seem 
>> to have been changed since and so getting a license change will also be 
>> fun..
>>     
>
> Actually, I've browsing a bit around, and it seems the package appears
> on another one of the authors web pages [1], where it is available as
> GPLv2 (or later), so no change in license seems necessary. There is also
> another package available at the same site for similar problems [2]
> (again GPLv2 or later).
>
>   

Ok, then it might indeed be a good idea to change to using JDQR, but 
probably the fortran code that is on this web site instead of ARPACK. 
However, you'd still need better iterative solvers and preconditioners 
in Octave in a general sense, since it doesn't make sense to ad the 
iterative solvers in an adhoc way just for JDQR....

Cheers
David



-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary