octave-maintainers
[Top][All Lists]
Advanced

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

Re: 3.1 status report


From: Jaroslav Hajek
Subject: Re: 3.1 status report
Date: Thu, 3 Apr 2008 07:57:03 +0200

On Thu, Apr 3, 2008 at 12:55 AM, John W. Eaton <address@hidden> wrote:
> Here is an update of the goals for 3.1 that I posted here:
>
>   
> http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-December/005354.html
>
>  I've tagged completed items with an "X" and items for which some work
>  has been done with an "x".
>
>    1. Objects:
>         X Merge object-branch
>         - Implementation of superiorto/inferiorto
>         - Operator overloading vs. constant folding
>
>    2. Handle block comments
>
>    X. Eliminate __gnuplot_X__ functions from Octave
>
>    4. Move code to external packages
>         - control
>         - finance
>         - optimization?
>         - signal?
>         - statistics?
>         - quaternions
>
>    5. Move imread/imwrite functions from Octave Forge to Octave.
>
>    6. Improve traceback error messages.  The messages should list the
>       exact line where an error occurred, then only print function
>       traceback info and not information about which
>       if/for/while/etc. statement includes the error.  That extra
>       information just seems to confuse users, and the current
>       messages don't always clearly describe the actual location of
>       the error.
>
>    X. Ensure that all operations which work on dimensions alone
>       (squeeze, numel, triu, etc.) work for all objects and preserve
>       type.  Should these functions all be built-in?  Possibly they
>       should all be provided by the octave_value class interface.
>
>    X. Make mapper functions work like other built-in functions?
>
>    X. Mapper functions like real, imag, and mod should preserve type
>       (are there others?)
>
>   10. Improve compatibility of fsolve
>         - input/output args should be compatible
>         - use optimset for options
>
>   11. Graphics:
>         x Refactor base_properties
>         x Specific types for properties with improved property value
>           checking
>         - Implement the addprops function allow additional properties
>           to objects
>         - add the hggroup object that has no fixed properties for use
>           by barseries, etc.
>         - Add callback DeleteFcn/CreateFcn to objects
>         - Allow listener functions to be added to objects
>         x Clean separation of backend from property database
>         x Implement experimental backend based on OpenGL and GUI
>           toolkit
>
>  Is anyone interested in helping to move the control, finance, and
>  quaternion functions into separate packages?
>
>  Should we move the statistics, signal, and optimization functions to
>  separate packages?
>
>  I'm still hopeful that we can have a release by the end of June.
>  Although it may contain the OpenGL graphics code, I'm not expecting
>  that we will make that the default graphics backend.
>
>  Would someone like to work on integrating the imread and imwrite
>  functions?  I think these are essential for 3.1 since "how do I read
>  image data?" is becoming a very frequently asked question.
>
>  Another small but fairly important project is improving the
>  compatibility of fsolve.  Is anyone interested in working on that?
>

I volunteer for this one (unless anyone else is working on that).

As a future project, what about making fsolve reentrant? That would
probably involve modifications to the MINPACK subroutines, but since
MINPACK is not officially
maintained anymore, I think that is hardly a problem.

Further, what about including also the nonlinear least squares part of
MINPACK (LMDIF/LMDER) to implement lsqnonlin?

I see fzero, fmins and fminbnd are also missing. There may be some
state-of-the art implementations of fzero and fminbnd available, or
can be implemented according to the well-known books...


>  I hope to have some time to work on items 1, 2, and 6, but if someone
>  else would like to work on them, please let me know so we don't
>  duplicate efforts.
>
>  Comments?
>
>  Thanks,
>
>  jwe
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

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