octave-maintainers
[Top][All Lists]
Advanced

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

goals for 3.1


From: John W. Eaton
Subject: goals for 3.1
Date: Thu, 20 Dec 2007 13:31:23 -0500

OK, after seeing the various comments in this thread, I've revised my
list of goals for 3.1 and given each item a tentative priority rank
(see below).

Most of the first five items are fairly straightforward and I think
should be done right after the 3.0 release.  Getting
superiorto/inferriorto and some other OO features implemented
"correctly" (i.e., in a compatible way) may turn out to be
non-trivial, but merging the branch should at least be fairly quick.

I've cut off the list at 11 because I think we need to have a
manageable list so we can make the 3.1 release in 6-9 months rather
than 6-9 years.  Other items are welcome of course, but I don't think
we should allow a long wish list delay the next release for a long
time.

   1. Objects:
        -- Merge object-branch
        -- Implementation of superiorto/inferiorto
        -- Operator overloading vs. constant folding

   2. Handle block comments

   3. 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.

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

   8. Make mapper functions work like other built-in functions?

   9. 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

----------

  12. Implement nested functions

  13. Eliminate explicit dispatch on type in various functions (for
      example, the NATIVE_REDUCTION macro in data.cc, the if/else mess
      in sort, or any other similar constructs) in favor of dispatch
      via virtual functions in the octave_value class.

  14. Write tree-walker evaluator class that can be used for profiling
      and debugging evaluators, and maybe also as the basis for an
      m-file to oct-file compiler

  15. BLAS/LAPACK:
        -- Stop distributing Fortran sources?  If we do this, should
           we make it possible to compile Octave without any
           BLAS/LAPACK library, or should BLAS/LAPACK be required?
        -- Use cblas interface?

  16. Update the configure script and make checks for header files and
      libraries more consistent (maybe we could recruit an autoconf
      expert to help with this job).



Comments or suggestions?

Thanks,

jwe




reply via email to

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