1,072
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
m
Add new project
m (Add new project) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 85: | Line 85: | ||
* <strike> Adapt the interface of "ode45" in odepkg to be completely Matlab compatible, fix its code and documentation style and move it to Octave-core. </strike> | * <strike> Adapt the interface of "ode45" in odepkg to be completely Matlab compatible, fix its code and documentation style and move it to Octave-core. </strike> | ||
* <strike> Build Matlab compatible versions of "ode15s" and "ode15i". jwe has prototype implementations [https://savannah.gnu.org/patch/?8102 here] of these built as wrappers to "dassl" and "daspk". An initial approach could be to just improve these wrappers, but eventually it would be better to have wrappers for "IDA" from the sundials library. </strike> | * <strike> Build Matlab compatible versions of "ode15s" and "ode15i". jwe has prototype implementations [https://savannah.gnu.org/patch/?8102 here] of these built as wrappers to "dassl" and "daspk". An initial approach could be to just improve these wrappers, but eventually it would be better to have wrappers for "IDA" from the sundials library. </strike> | ||
* Improve handling of sparse Jacobians in IDE/DAE solvers | |||
** Currently, in the IDA wrapper function __ode15__ an over conservative guess for the amount of memory to be allocated when assembling a sparse jacobian is used, essentially allocating enough space for a full jacobian then freeing the excess memory, an initial patch for fixing this has been posted on the tracker, for integrating this into Octave it must be generalized to support prior versions of SUNDIALS | |||
** Currently Jacobians passed by the user in Octave's sparse matrix format are copied into SUNDIALS own sparse matrix format. Newer versions of SUNDIALS (5.x or higher) support letting the user take care of the linear algebra data structures and methods thus removing the need for the copy. Taking advantage of this feature would improve the solver performance both in terms of memory footprint and speed. | |||
** References | |||
***[https://savannah.gnu.org/bugs/?func=detailitem&item_id=55905 tracker post about memory allocation] | |||
***[https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history] | |||
* Implement Matlab compatible versions of "deval". | * Implement Matlab compatible versions of "deval". | ||
* Complete transition of ode23s into core Octave | |||
** [https://savannah.gnu.org/bugs/?57309 Bug tracker entry discussing ode23s] | |||
== High Precision Arithmetic Computation == | == High Precision Arithmetic Computation == | ||
| Line 380: | Line 388: | ||
**Tests for various functions. Would be nice to have a test file corresponding to every function (see below) | **Tests for various functions. Would be nice to have a test file corresponding to every function (see below) | ||
**Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != ! | **Tests for element by element operators: + - .* ./ .\ .^ | & < <= == >= > != ! | ||
*** thorough tests for power operator including corner cases and strange combinations such as complex .^ range. | |||
**Tests for boolean operators: && || | **Tests for boolean operators: && || | ||
**Tests for other operators: * / \ ' .' | **Tests for other operators: * / \ ' .' | ||
| Line 427: | Line 436: | ||
*Reduce the amount of datatypes in liboctave. | *Reduce the amount of datatypes in liboctave. | ||
*Re-implement operators using templates and modern C++. Current system evolved before templates and makes extensive use of macros to define interactions between scalar<->scalar, scalar<->matrix, scalar<->float, etc., etc. | |||
**In liboctave, the directory to work on is liboctave/operators | |||
**In libinterp, the directory to work on is libinterp/operators | |||
**In libinterp, there is also xpow.cc, xdiv.cc in libinterp/corefcn | |||
=Miscellaneous= | =Miscellaneous= | ||
| Line 478: | Line 492: | ||
=Performance= | =Performance= | ||
*A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface. | * A profiler for Octave would be a very useful tool. And now we have one! But it really needs a better interface. | ||
*Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this. | * Having {{Codeline|parfor}} functioning would speed code development and execution now that multicore architectures are widespread. See [http://octave.1599824.n4.nabble.com/Parfor-td4630575.html here] and [http://stackoverflow.com/questions/24970519/how-to-use-parallel-for-loop-in-octave-or-scilab here]. Existing code from the [[Parallel package | parallel]] and [http://octave.sourceforge.net/mpi/index.html mpi] packages could perhaps be adapted for this. | ||
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance. | |||
=Packaging= | =Packaging= | ||