1,847
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
→Packaging: Merge GSoC Octave Package management.
(→Matlab-compatible ODE solvers in core-Octave: Update section.) |
(→Packaging: Merge GSoC Octave Package management.) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 92: | 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. 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 450: | 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 463: | 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= | ||