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: Tue, 13 Nov 2007 14:11:28 -0500

I'd like to have a fairly small list of key goals for 3.1 so that we
can make another release 6 months or so after 3.0.  Here's my current
list:

  * Objects:
      -- merge object-branch
      -- implementation of superiorto/inferiorto
      -- operator overloading vs. constant folding

  * Graphics:
      -- specific types for properties with improved property value checking

  * 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?

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

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

  * Move code to external packages
      -- control
      -- finance
      -- optimization?
      -- signal?
      -- statistics?
      -- quaternions

  * Handle block comments

  * Implement nested functions

  * Make mapper functions work like other built-in functions?

  * Eliminate __gnuplot_X__ functions from Octave

  * fsolve compatibility
      -- input/output args should be compatible
      -- use optimset for options

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

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

I'm willing to drop some of these or add other items, but I think we
should try to agree on the list of items by the time 3.0 is released,
and then stick to it.  Once all the items on the list have been done
we can make another release and pick another set of goals for 3.2.

Comments or suggestions?

Thanks,

jwe


reply via email to

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