1,847
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
m
Reverted edits by 87.129.56.220 (talk) to last revision by Philipn
m (Reverted edits by 87.129.56.220 (talk) to last revision by Philipn) Tag: Rollback |
|||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 81: | Line 81: | ||
== Matlab-compatible ODE solvers in core-Octave == | == Matlab-compatible ODE solvers in core-Octave == | ||
* Improve handling of sparse Jacobians in IDE/DAE solvers | * Improve handling of sparse Jacobians in IDE/DAE solvers '''(2021-01-21 Still an issue? See bug {{bug|55905}}.)''' | ||
** 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, 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. | ** 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. | ||
** | ** See also [https://computing.llnl.gov/projects/sundials/release-history SUNDIALS release history]. | ||
* Implement Matlab compatible versions of "deval". | * Implement Matlab compatible versions of "deval". | ||
== High Precision Arithmetic Computation == | == High Precision Arithmetic Computation == | ||
| Line 96: | Line 92: | ||
The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave. | The architecture consists of an Octave class interface implementing "mp" (multi-precision) objects. Arithmetic operations are forwarded to MPL using MEX files. This is totally transparent to the end user, except when displaying numbers. This implementation needs to be ported and tested under Octave. | ||
== Improve logm, sqrtm, funm == | |||
The goal here is to implement some missing Matlab functions related to matrix functions like the [https://en.wikipedia.org/wiki/Matrix_exponential matrix exponential]. There is [https://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html a general discussion] of the problem and [https://octave.1599824.n4.nabble.com/Re-GSOC-16-Improvements-to-sqrtm-logm-and-funm-td4675180.html a thread on a GSOC project that never took off] (together with [https://github.com/RickOne16/matrix working funm.m code]). A good starting point for available algorithms and open-source implementations is Higham and Deadman's [http://eprints.maths.manchester.ac.uk/2102/1/catalog.pdf "A Catalogue of Software for Matrix Functions"]. | |||
== Improve iterative methods for sparse linear systems == | |||
GNU Octave currently has the following Krylov subspace methods for sparse linear systems: pcg (spd matrices) and pcr (Hermitian matrices), bicg, | |||
bicgstab, cgs, gmres, and qmr (general matrices). The description of some of them (pcr, qmr) and their error messages are not aligned. Moreover, they have similar blocks of code (input check for instance) which can be written once and for all in common functions. The first step in this project could be a revision and a synchronization of the codes, starting from the [https://socis16octave-improveiterativemethods.blogspot.com/ SOCIS2016] project, which is already merged into Octave (cset {{cset|6266e321ef22}}). | |||
In Matlab, some additional methods are available: minres and symmlq (symmetric matrices), bicgstabl (general matrices), lsqr (least | |||
squares). The second step in this project could be the implementation of some of these missing functions. | |||
The [https://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf reference book by Yousef Saad] is available online. | |||
=GUI/IDE= | =GUI/IDE= | ||
| Line 355: | Line 365: | ||
* Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts. | * Implement a coverage tool for collecting coverage data and generating code coverage reports on m-file functions and scripts. This would be very useful for Octave development as well as for users who want a code coverage report for their own functions and scripts. | ||
* Implement test for plotting and graphics functions that might currently only have basic input checking and/or demos for human inspection. Possibly create tests that probe properties of the handles created and returned by most such functions, such that test plots can be checked for correct feature size/location, etc. | |||
We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests. | We are far from even having one test for every function, so focus should be on getting the breadth of coverage first before trying to get the depth of 100% statement coverage. As of Dec 2015, 202 of 1020 m-files have no tests. Some of these will be plotting functions which have demos instead, but that leaves enough functions to be an interesting project. As of Dec 2015, there are 485 instances of C++ functions which need tests. | ||
| Line 452: | Line 464: | ||
* 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. | * 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. | ||
= | = Octave Package management = | ||
[[Packages]] are extensions for Octave. To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything. | |||
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite. | |||
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke. | |||
The planned improvements are: | |||
* install and update from repositories (hg and git) | |||
* automatic handling of dependencies | |||
* easily load, update or check specific package versions | |||
* management of tests and demos in C++ sources of packages | |||
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages | |||
* support for multiple version packages | |||
* support for multiple Octave installs | |||
* support for system-wide and user installed packages | |||
* testing packages (<code>pkg test <package-name></code>) | |||
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/ | |||
* create a system that allows packages to deprecate functions as in core. Possibilities are: | * create a system that allows packages to deprecate functions as in core. Possibilities are: | ||
| Line 465: | Line 494: | ||
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute? | ** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute? | ||
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?) | * make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?) | ||
The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave. | |||
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not. | |||
Instead a package for developers should be created with such tools. | |||
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]). | |||
Many of these problems have been solved in other languages. | |||
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions. | |||
In some cases, there are standards to follow. | |||
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]), and Windows seems to have its own standards. | |||
See bugs {{bug|36477}} and {{bug|40444}} for more details. | |||
In addition, package names may start to collide very easily. | |||
One horrible way to work around this by is choosing increasingly complex package names that give no hint on the package purpose. | |||
An option is providing an "Authority" category like Perl 6 does. | |||
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}). | |||
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time. | |||
Read the [[OEP:pkg|unfinished plan]] for more details. | |||
=Preferences= | =Preferences= | ||