153
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
m
→Input/Output: add to hdf5 note
(→Matlab-compatible ODE solvers in core-Octave: Update section.) |
m (→Input/Output: add to hdf5 note) |
||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 12: | Line 12: | ||
*Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html) | *Improve logm, and sqrtm (see this thread: http://octave.1599824.n4.nabble.com/matrix-functions-td3137935.html) | ||
*Use pairwise addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation). | *Use pairwise or block addition in sum() to mitigate against numerical errors without substantial performance penalty (https://en.wikipedia.org/wiki/Pairwise_summation), see bug {{bug|61143}} for prior discussion. | ||
*Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper. | *Review implementing algorithm in this 2009 paper (https://epubs.siam.org/doi/pdf/10.1137/080738490) for xsum (sum with extra accuracy). The existing implementation uses a 2005 paper. | ||
| Line 29: | Line 29: | ||
*Improve design of ODE, DAE, classes. | *Improve design of ODE, DAE, classes. | ||
*Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.) | *Evaluate harmonics and cross-correlations of unevenly sampled and nonstationary time series, as in http://www.jstatsoft.org/v11/i02 (which has C code with interface to R). (This is now partly implemented in the [http://octave.sourceforge.net/lssa/index.html lssa] package.) | ||
| Line 92: | Line 90: | ||
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 99: | Line 111: | ||
**Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors). | **Evaluate a line of code and return the output as a string (it would be best if it could provide three strings: output, warnings and errors). | ||
**Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals). | **Query defined variables, i.e. get a list of currently defined variables. Bonus points if it could tell you if anything had changed since the last time you checked the variables (could also be done with signals). | ||
== GUI Variable Editor and Property Inspector == | == GUI Variable Editor and Property Inspector == | ||
| Line 126: | Line 137: | ||
**minres | **minres | ||
**symmlq | **symmlq | ||
* Enable automatically broadcasting operators to work with sparse matrices that currently require the use of bsxfun. | |||
== SPQR Interface == | == SPQR Interface == | ||
| Line 165: | Line 178: | ||
* write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses]. | * write {{codeline|xmlread}} and {{codeline|xmlwrite}}. This could be done using [http://xerces.apache.org/xerces-c/ Xerces C++ interface] which apparently is what [http://octave.1599824.n4.nabble.com/xml-in-octave-td4663034.html Matlab uses]. | ||
* Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]). | * Implement hdf5 for .mat files (see [http://octave.1599824.n4.nabble.com/Reading-Matlab-td4650158.html this thread]), likely a necessary step to enable saving of classdef classes. | ||
=Interpreter= | =Interpreter= | ||
| Line 446: | Line 459: | ||
=Performance= | =Performance= | ||
* 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. | * 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 492: | ||
** 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= | ||
| Line 488: | Line 535: | ||
** RESOLUTION | ** RESOLUTION | ||
* Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences. | * Searching the m-files for use of {{Codeline|persistent}} should turn up other opportunities to use preferences. | ||
=Profiler Enhancement= | |||
Octave has a built in {{manual|profile|profiler}} thanks to a [[Summer of Code#GSoC 2011 | successful 2011 GSOC project by Daniel Kraft]]. But it really could use: | |||
* Better granularity: | |||
** It aggregates all calls to a function within at each level of the code, providing no way to know which call to a function might be more 'expensive'. | |||
** It aggregates all non-function-call overhead into time spent on 'self' without further detail to the user on what might be causing that overhead. | |||
** Associating time spent/function call count to line number would be a big plus. | |||
* A better interface. | |||
** The current CLI tool is good at determining time spent on function calls, providing both a summary output with {{manual|profshow}} and an interactive prompt that lets you dive down levels in the code with {{manual|profexplore}}. But this suffers from the aggregation limits mentioned above. | |||
** The profiler was written before the stable Octave GUI was released with Octave 4.0. This GUI now includes a built in editor with hooks to the interpreter. Better integration of the profiler output to the Octave GUI would be a significant functional improvement. (Current GUI integration is limited to an indicator light that shows the profiler is running.) | |||
** Enhancements are not strictly limited to using the current Octave GUI/Editor. Whatever helps users connect execution time to code location would be good. | |||
=Bugs= | =Bugs= | ||