octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #8047] New function for odepkg


From: Olaf Till
Subject: [Octave-patch-tracker] [patch #8047] New function for odepkg
Date: Tue, 14 May 2013 12:23:43 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121207 Iceweasel/3.5.16 (like Firefox/3.5.16)

Follow-up Comment #3, patch #8047 (project octave):

Re-posted for Carlo de Falco <address@hidden>
(Actually the order of this and the previous post was reversed, sorry.):
---------------------------------------------------------------

On 13 May 2013, at 22:10, Olaf Till <address@hidden> wrote:

> Follow-up Comment #1, patch #8047 (project octave):
>
> As I understand, the inexact Newton method, as well as the ODE solver which
> uses it, is meant for large scale problems --- is that right?

Yes it is meant for problems with large, sparse jacobians

> If specially suitable for large scale problems, I think 'inexact_newton'
could
> be a valuable alternative to 'fsolve', and so would fit well into the
'optim'
> package (I believe it would be the first zero-finder there, except a
> vectorized clone of 'fzero').

indeed it is a zero-finder but many ptimization functions could made to
optionally
use it when dealing with large problems. I'd like the function to be given
more testing
before such changes are done, though.

> The dependency on other packages can sometimes be a problem, though.
'optim'
> sometimes makes problems on some systems due to its use of LAPACK, and it
in
> turn depends on further packages, partially due to some older code. Maybe
> eventually some reorganization will happen; until that, duplicating the
code
> of 'inexact_newton' in the 'odepkg' package could be an (ugly) solution for
> being independent …

so you suggest adding inexact_newton both in odepkg and optim?
I think it could be done if we make it private in odepkg to avoid conflicts
...

> Or 'inexact_newton' might actually go into Octave core, if it is really
good
> for large scale problems.

I don't think it fits in Octave core, its scope does not seem general enough
to me
and there is not an equivalent function in Matlab

> But that is not mine to decide. Its interface would
> probably have to be changed for that in favor of 'optimset' (and maybe this
> would even be better anyway).

that is a good idea.

> Olaf
c.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8047>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]