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:21:34 +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 #2, patch #8047 (project octave):

Re-posted for Sebastian Schöps <address@hidden>:
-------------------------------------------------------------

The backward Euler that I have written (odebwe.m) uses a private Newton scheme
to avoid dependencies. I would encourage to merge the two integrators.

Instead there should be a switch in odeset to choose the nonlinear solver
(fixed point, Newton, simplified Newton, Krylov) as suggested by Olaf. I would
prefer
+to keep the classical Newton build-in and the others could be made optional
with something like "if !exist(...,'file') warning('Install Optim')".

Best regards,
Sebastian

Am 14.05.2013 um 08:25 schrieb "c." <address@hidden>:

>
> 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]