octave-maintainers
[Top][All Lists]
Advanced

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

Re: Moving ode changes to default branch


From: Jacopo Corno
Subject: Re: Moving ode changes to default branch
Date: Wed, 12 Oct 2016 09:23:41 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Il 11/10/2016 17:55, Rik ha scritto:
10/11/16

Carlo,

I'm concerned that the latest changes to the ode functions made just five
days ago are too speculative for the stable branch and should be re-located
to the development branch.  As Carnë noted in a separate e-mail, feature
freeze has already happened and the stable branch is now just for bug fixes
and documentation updates.

I'm not saying that the changes are bad, but it's clear that there hasn't
been enough time to test things.  The first commit broke 'make check' and
that had to be quickly patched.  If I look at the code for odedefaults.m I
see that there is no indentation for code within the function block, single
quotes are used instead of double quotes, and there is no space between the
function name and the opening parenthesis.  This is small stuff, and can be
corrected, but it is an indication that a thorough review has not
happened.  Similarly, ode23.m has a typo in the docstring:
<@qcode{"AbsTol"},.>.  The comma before the period is not grammatically
correct.  With more testing time I'm sure this would be caught.  Finally, I
did some benchmarking of odeset because I remember that I had to do some
tricks to get it to run quickly.  The following code

tic; x = odeset (); toc

runs in 0.00015 seconds with the old code, but now takes .0058 seconds.
That's a 39X slowdown.  Of course the absolute time of five milliseconds is
probably unimportant to a human, but I want to understand whether we must
accept that slowdown, or whether there is a better way to code this.
Perhaps the use of persistent variables in odedefaults would help.

If you have a plan on how we could become comfortable with the idea of
keeping this code on the stable branch we will listen.  Otherwise, it seems
like the best course is to move the changes to the default branch where
they can simply have more time to mature into solid code.

--Rik


Dear all,

I am not sure if it counts as testing, but in the last few days I updated almost all the solver in odepkg to the new options handling by Francesco and Carlo and everything seems to be working fine.

Regarding the slow down in odeset, Carlo and I expected this, but for any reasonable problem it is in my opinion negligible. Furthermore the checking of the options is now more sound than before. I recall that there are some proposition on improving the performances as the next step for Octave development and surely we can look into ode as well...

Let me know what will be the final choice for stable so that I can either keep working on odepkg as is or go back and fix it starting from the old version.

One final comment:
Maybe in the future we could better synchronize the release with the end of the GSOC/SoCiS projects. My guess is that seeing their contribution in core would increase the students interest in keeping involved in Octave.

Cheers,
Jack


--
Jacopo Corno M.Sc.
Technische Universität Darmstadt
Graduate School of Computational Engineering
Dolivostraße 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 24414
Email: address@hidden




reply via email to

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