Projects: Difference between revisions

Jump to navigation Jump to search
4,507 bytes added ,  28 June 2023
(→‎Numerical: Move projects from GSoC page.)
 
(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.
*Make QR more memory efficient for large matrices when not all the columns of Q are required (apparently this is not handled by the lapack code yet).


*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 95: Line 93:
== Improve logm, sqrtm, funm ==
== 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"].
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 ==
== Improve iterative methods for sparse linear systems ==
Line 113: 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).
* Create a better (G)UI for the {{manual|profile|profiler}}. This may be done with Qt, but not necessarily.
*Allow side-by-side editing
**Allow multiple Editor windows, so source files can be edited side-by-side within the GUI.
**Add a vertical window splitter to the Editor so you can see the initialization code at the top while you type at the bottom.
**Ensure that any particular file is only open in one tab at a time!


== GUI Variable Editor and Property Inspector ==
== GUI Variable Editor and Property Inspector ==
Line 140: Line 141:
**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 179: Line 182:
* 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 460: Line 463:
=Performance=
=Performance=


* 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.
* 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=
= 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 477: Line 496:
** 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 502: Line 539:
** 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=
Anonymous user

Navigation menu