[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goals for 3.1
From: |
Shai Ayal |
Subject: |
Re: goals for 3.1 |
Date: |
Thu, 20 Dec 2007 21:01:11 +0200 |
On Dec 20, 2007 8:31 PM, John W. Eaton <address@hidden> wrote:
> 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
I would like to add some detail as to the feasibility of this last point:
I think writing the actual drawing code will be relatively easy and
can easily be accomplished even by me alone in the 6 month time-frame
(and I'm sure I'll have help). However today the gnuplot backend does
a lot more then drawing -- The first thing that comes to mind is
determining tick marks, but I'm sure that other things will pop-up.
For each of these things design decisions would have to be taken -- is
it the backend's responsibility or octave's responsibility. This might
slow things up a bit (a discussion on the mailing list is always
slower than frantic coding by a single person). All that being said I
still think that a 6-9 month milestone is reasonable for this point
Shai
> ----------
>
> 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
>
>
>
Re: goals for 3.1, Søren Hauberg, 2007/12/21
Re: goals for 3.1, Tatsuro MATSUOKA, 2007/12/24