Ed Schofield wrote:
On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de>> wrote:
Ed Schofield wrote: > > On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de> > <mailto:nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de>>> wrote: > > Hi Ed, > > Great ! > Thank you very much ! > It seems to work well with the exception of GMRES. > Please find attached a short test. > Am I missing something ?
> > > No, I agree. It seems that there's something wrong with GMRES
> ... Hi Ed,
Done. Maybe you can add some comments. Again thank you very much for the new functionality !!
http://projects.scipy.org/scipy/scipy/ticket/360
Actually, I'm mystified about the meaning of iter_ in gmres() and the others. Can anyone shed any light on this? Why is the output value of iter_ from revcom() used as the *input* value in the next iteration? Why is the maxiter argument only used once, for the first call to revcom(), and then apparently ignored for all subsequent calls?
The meaning of iter_ is the number of restarted GMRES iterations, not the total number. The bottom line is the nice property of GMRES that it can compute the residuals without updating the iterate x.
I'm inclined to revert the callback patch -- it seems broken. But if the revcom Fortran functions can perform multiple iterations each, we can't easily call back Python functions each iteration. Is there a better solution?
I've made a patch in http://projects.scipy.org/scipy/scipy/ticket/360 that gives the relative residual to the callback routine. -- bart