252
edits
JWE Project Ideas: Difference between revisions
Jump to navigation
Jump to search
→Syntax, semantics, and data types
No edit summary |
|||
| (9 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 --> | ||
'''2021-11-19: This page is out of date -- jwe''' | |||
== Language and functions == | == Language and functions == | ||
| Line 20: | Line 20: | ||
=== Syntax, semantics, and data types === | === Syntax, semantics, and data types === | ||
==== Matlab-compatible argument validation blocks ==== | |||
New language feature, syntax is accepted by parser now but argument validation is not performed. | |||
==== Function handle refactoring ==== | ==== Function handle refactoring ==== | ||
| Line 85: | Line 89: | ||
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 ==== | ==== 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? | 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 ==== | ==== graph and digraph ==== | ||
| Line 152: | Line 148: | ||
This is a large project, but one that will likely have to be tackled at some point. | This is a large project, but one that will likely have to be tackled at some point. | ||
== Miscellaneous == | |||
=== Handle UTF-8 === | |||
We need to handle UTF-8 (or whatever) characters properly in all parts of Octave. 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 === | |||
* 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. As much as possible, the initial implementation should be written in Octave's scripting language and the proposed [[Low-level interface to HDF5 functions]] so that it can easily be updated and patched as needed while we are still working out the details. Only later should we consider translating performance-critical parts to C++, and then, only if really necessary. | ||
* 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 | === Low-level interface to HDF5 functions === | ||
Create a thin wrapper for the HDF5 library. As much as possible, make it compatible with the [https://www.mathworks.com/help/matlab/low-level-functions.html Matlab interface to HDF5]. However, we may support newer functions (as of 2020/10/30, the list of Matlab functions appears to correspond to an older version of the library than is presently available in the HDF5 library itself) and support for legacy functions has a low priority. | |||
Also as of 2020/10/30, [[User:jwe|jwe]] is working on this project. Help is welcome! | |||
=== RNG issues === | |||
RandStream and Other RNG issues | RandStream and Other RNG issues | ||
| Line 169: | Line 171: | ||
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 === | |||
Implement mxMakeReal and mxMakeComplex functions. | Implement mxMakeReal and mxMakeComplex functions. | ||
=== JIT compiler === | |||
A proof-of-concept implementation was done several years ago by a | A proof-of-concept implementation was done several years ago by a | ||
| Line 185: | Line 187: | ||
and Octave internals. | and Octave internals. | ||
=== 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. | ||
=== Complex integers === | |||
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. Likewise for whos function. | Should just read file and list info, not create dummy scope. Likewise for whos function. | ||
== Maintenance and packaging == | |||
=== General code quality === | |||
* Use C++11 features where possible. | * Use C++11 features where possible. | ||
| Line 213: | Line 215: | ||
* Audit global variables and eliminate them where possible | * Audit global variables and eliminate them where possible | ||
=== Symbol visibility === | |||
We really should be tagging the functions that we wish to export from shared libraries. | 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? | ||
=== Toolboxes === | |||
Move some core toolboxes (communications, control systems, image | Move some core toolboxes (communications, control systems, image | ||
| Line 235: | Line 237: | ||
equations package have already been moved to Octave. | equations package have already been moved to Octave. | ||
=== Documentation === | |||
* Docs for call stack with examples and illustrations | * Docs for call stack with examples and illustrations | ||
| Line 246: | Line 248: | ||
* Improve other Doxygen docs for internals to make it easier for new contributors to understand the Octave code base. | * Improve other Doxygen docs for internals to make it easier for new contributors to understand the Octave code base. | ||
=== Windows distribution === | |||
Eliminate the following msys packages. Some might be removed | Eliminate the following msys packages. Some might be removed | ||