243
edits
No edit summary |
No edit summary |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
<!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas --> | <!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas --> | ||
== Language and functions == | == Language and functions == | ||
Line 55: | Line 5: | ||
=== classdef issues === | === classdef issues === | ||
==== | ==== Compatibility issues ==== | ||
Make a list here, pointing to individual bug reports? | Make a list here, pointing to individual bug reports? | ||
==== | ==== Load/save for classdef ==== | ||
See also general load/save issues. | See also general load/save issues. | ||
==== Improve | ==== Improve / simplify implementation ==== | ||
Although the basic features that are implemented now appear to mostly work, the implementation seems overly complicated, making it difficult to debug and modify. There seems to be quite a bit of room for improvement here. | Although the basic features that are implemented now appear to mostly work, the implementation seems overly complicated, making it difficult to debug and modify. There seems to be quite a bit of room for improvement here. | ||
Line 69: | Line 19: | ||
=== Syntax, semantics, and data types === | === Syntax, semantics, and data types === | ||
==== | ==== Function handle refactoring ==== | ||
* Load/save for all types of function handles and all data formats (ascii, binary, hdf5, mat5) | * Load/save for all types of function handles and all data formats (ascii, binary, hdf5, mat5) | ||
Line 88: | Line 38: | ||
* timeseries | * timeseries | ||
==== | ==== single / integer valued ranges ==== | ||
This is a compatibility issue. | This is a compatibility issue. | ||
Line 97: | Line 47: | ||
* Should we really have ADD_PKG and DEL_PKG files? If so, how can we make them safe? | * Should we really have ADD_PKG and DEL_PKG files? If so, how can we make them safe? | ||
==== Eliminate special | ==== Eliminate special matrix types ==== | ||
Although | Although the special range, diagonal matrix, and permutation matrix data types in Octave require less memory than storing full matrices, they tend to cause trouble when people expect full compatibility or exactly the same results when performing arithmetic on Ranges vs. Matrices. Now that we have broadcasting operators, the need for diagonal matrices is not as great. | ||
==== | ==== Special case FOR loop limits ==== | ||
Currently, "for i = 1:N ..." uses a Range object for the "1:N" loop bounds. If we eliminate Ranges as a special space-saving type, then we should handle this syntax as a special case. Even if we don't eliminate Ranges, that might be a good idea, as we could handle "for i = 1:Inf ..." easily without having to worry about how to deal with that in an ordinary Range object vs. FOR loop bounds. | Currently, "for i = 1:N ..." uses a Range object for the "1:N" loop bounds. If we eliminate Ranges as a special space-saving type, then we should handle this syntax as a special case. Even if we don't eliminate Ranges, that might be a good idea, as we could handle "for i = 1:Inf ..." easily without having to worry about how to deal with that in an ordinary Range object vs. FOR loop bounds. | ||
Line 111: | Line 61: | ||
files. | files. | ||
==== Matlab packages | ==== Matlab packages ==== | ||
+DIR directories in the loadpath; related to classdef | |||
Octave already searches for files in package directories and | Octave already searches for files in package directories and | ||
Line 128: | Line 80: | ||
Broadcasting does not work for sparse matrices. This seems like a big missing feature. | Broadcasting does not work for sparse matrices. This seems like a big missing feature. | ||
==== | ==== Structural zeros ==== | ||
Octave currently skips structural zeros for most (all?) sparse matrix operations. Matlab returns a sparse matrix filled with NaNs for something like "sprand (5, 5, 0.1) .^ NaN". Should we go for full compatibility? Mathematical correctness? Traditional behavior of sparse matrix libraries? It seems no one really agrees on what is correct or best. Maybe compatibility should win? | Octave currently skips structural zeros for most (all?) sparse matrix operations. Matlab returns a sparse matrix filled with NaNs for something like "sprand (5, 5, 0.1) .^ NaN". Should we go for full compatibility? Mathematical correctness? Traditional behavior of sparse matrix libraries? It seems no one really agrees on what is correct or best. Maybe compatibility should win? | ||
==== | ==== Indexed assignment ==== | ||
In an assignment like Sparse_object(idx) = GrB_object(idx), Octave does not attempt to apply a conversion operator to transform the RHS type to the LHS type. Is this also a problem for assignments of objects with conversion operators to full matrix objects? | |||
==== graph and digraph ==== | |||
Would it be difficult to provide these objects? | |||
== GUI == | |||
=== | === Communication with interpreter === | ||
Currently, communication between the GUI and the interpreter | |||
mostly happens when the interpreter is otherwise idle and waiting | |||
for user input at the command prompt and the implementation is | |||
somewhat complicated. We need to determine whether this is the | |||
best we can do, or if there is some other implementation that | |||
would be more flexible and reliable. | |||
=== [[GUI terminal widget|GUI command window]] === | |||
The implementation of the GUI command window for Unix-like systems | |||
is a completely separate implementations from the one used on | |||
Windows systems. There should be only one, and the GUI should be | |||
completely in charge of user input and output. This will probably | |||
require implementing some kind of simple output pager internally | |||
instead of using an external program, but overall user interaction | |||
could be improved. | |||
=== GUI code editor === | |||
Make it possible to use external editors such as Emacs, vim, or | |||
others with the GUI in addition to Octave's built-in code editor | |||
== Graphics == | |||
=== Publication-quality figures === | |||
Generating EPS or PDF versions of figures needs improvement. | |||
=== OpenGL graphics === | |||
* Scaling plot data values/ranges to fit in single-precision OpenGL values | |||
* Performance issues | |||
* Lack of WYSIWYG | |||
=== FLTK widget === | |||
With the rest of the GUI using Qt widgets, we should eliminate the FLTK plotting widget. It duplicates functionality and requires additional effort to maintain. Maybe we no longer need the octave-cli binary (the one that is not linked with Qt libraries)? | |||
=== | === Qt toolkit threading === | ||
It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases. | |||
=== | === classdef graphics objects === | ||
This is a large project, but one that will likely have to be tackled at some point. | |||
=== Miscellaneous === | === Miscellaneous === | ||
==== Handle UTF-8 | ==== Handle UTF-8 ==== | ||
Try to do this in a Matlab-compatible way. | We need to handle UTF-8 (or whatever) characters properly in all parts of Octave. Try to do this in a Matlab-compatible way. | ||
==== | ==== Load / save for large files ==== | ||
* Make the load and save commands compatible with Matlab's HDF5-based file format. Matlab users expect this and we need something like this to support large arrays anyway. | * Make the load and save commands compatible with Matlab's HDF5-based file format. Matlab users expect this and we need something like this to support large arrays anyway. | ||
* Phase out Octave's own text and binary formats. Too much effort is required to maintain the code to support all the various formats. | * Phase out Octave's own text and binary formats. Too much effort is required to maintain the code to support all the various formats. | ||
==== | ==== RNG issues ==== | ||
RandStream and Other RNG issues | |||
This is likely a large project, but it would be nice to have updated, compatible interfaces. | This is likely a large project, but it would be nice to have updated, compatible interfaces. | ||
==== MEX Interface | ==== MEX Interface ==== | ||
Implement mxMakeReal and mxMakeComplex functions. | Implement mxMakeReal and mxMakeComplex functions. | ||
Line 179: | Line 175: | ||
and Octave internals. | and Octave internals. | ||
==== loadlibrary | ==== loadlibrary ==== | ||
This feature might be nice to have but it has a low priority. | This feature might be nice to have but it has a low priority. | ||
Line 187: | Line 183: | ||
Should we support this feature? Should we refactor the implementation of array objects to make this job easier? | Should we support this feature? Should we refactor the implementation of array objects to make this job easier? | ||
==== | ==== who -file option ==== | ||
Should just read file and list info, not create dummy scope. | Should just read file and list info, not create dummy scope. Likewise for whos function. | ||
=== Maintenance and packaging === | === Maintenance and packaging === | ||
==== General code quality | ==== General code quality ==== | ||
* Use C++11 features where possible. | * Use C++11 features where possible. | ||
Line 207: | Line 203: | ||
* Audit global variables and eliminate them where possible | * Audit global variables and eliminate them where possible | ||
==== Symbol visibility | ==== Symbol visibility ==== | ||
We really should be tagging the functions that we wish to export. | We really should be tagging the functions that we wish to export from shared libraries. | ||
==== | ==== Dispatch types for functions ==== | ||
Search for "classes:" in sources to find the few current examples. | Search for "classes:" in sources to find the few current examples. | ||
==== | ==== min/max nargin values ==== | ||
Should we do this, and allow the interpreter to automatically error when a function is given too few/many arguments? | Should we do this, and allow the interpreter to automatically error when a function is given too few/many arguments? |