Re: 3.2 status report

[Jaroslav Hajek]

On Wed, Jul 30, 2008 at 9:23 PM, John W. Eaton <address@hidden> wrote:
> Here is an update of the goals for 3.2.  Previous postings referred to
> version 3.1, but the version number of the next stable release will be
> 3.2.0 since we decided to release development snapshots with versions
> numbered 3.1.x.
>
> I've tagged completed items with an "X" and items for which some work
> has been done with a "+".  Please let me know if I've missed anything.
>
>   1. Objects:
>        X Merge object-branch
>        X Implementation of superiorto/inferiorto
>        - Operator overloading vs. constant folding
>
>   +. Handle block comments.  This is not quite finished as block
>      comments inside [] or {}, and also in the group of comments
>      following a continuation character, etc., are not handled.  See
>      the FIXME comments in lex.l.
>
>   X. Eliminate __gnuplot_X__ functions from Octave
>
>   4. Move code to external packages
>        X control
>        X finance
>        - optimization?
>        - signal?
>        - statistics?
>        X quaternions
>
>   +. 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:
>        + Refactor base_properties
>        + 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
>        + Clean separation of backend from property database
>        + Implement experimental backend based on OpenGL and GUI
>          toolkit
>
>  Other tasks that should be considered before the release:
>
>    * Document the graphics changes made by Shai/Michael as needed.
>
>    * Document the object oriented stuff in a new chapter.
>
>    * Document the use of private directories.
>
>    * Document other functions that were ported from octave-forge (eg
>      imread, dlmwrite, etc)
>
>    + Update the NEWS file.
>
>
> I think we decided that for now we will keep the statistics, signal,
> and optimization functions in Octave, so I will remove those from my
> list of things to do for 3.2.
>
> I'm still hopeful that we can have a release within a month or two.
> Although it may contain the OpenGL graphics code, I'm not expecting
> that we will make that the default graphics backend.
>
> To me, the most important items are 5, 6, and 10.  I started working
> on item 6 and will start a separate thread about that.
>
> Would someone like to work on finishing the imwrite function (item 5)?
> I checked in a start, but there is some more work that needs to be
> done.
>
> How about fsolve (item 10)?  Is anyone interested in working on it?
>

I intend to handle this as part of the project to implement Matlab-compatible
fzero, fminbnd, fsolve and lsqnonlin:
http://www.nabble.com/List-of-most-highly-used-matlab-functions.-to18693110.html
We intend to build some custom optimization scripts that probably will
make use of these functions as a part of our research, so I'm
definitely not going to drop this. I'm not, however, sure that I can
get this into 3.2 within a month (given that I also intend to do the
release management). Is there any reason why you want to have this in
3.2? It's hard to predict how much time I'll be able to spare for this
project within this month.
Sigh. So much exciting work and so little time...


> Comments?
>
> Thanks,
>
> jwe
>



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