Projects: Difference between revisions
Jump to navigation
Jump to search
→GUI/IDE
ArunGiridhar (talk | contribs) (→Numerical: removed a project that is already implemented in Octave) |
|||
| (4 intermediate revisions by one other user 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 111: | 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). | ||
* | *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 138: | 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 177: | 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 458: | Line 463: | ||
=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. | ||
| Line 535: | 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= | ||