JWE Project Ideas: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
== GUI ==
=== Improve interface for communication between GUI and interpreter ===
=== Improve interface for communication between GUI and interpreter ===


Line 17: Line 19:
instead of using an external program, but overall user interaction
instead of using an external program, but overall user interaction
could be improved.
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 ==


=== Generating publication-quality figures ===
=== Generating publication-quality figures ===
Line 28: Line 37:
* Lack of WYSIWYG
* Lack of WYSIWYG
* Duplication of effort with FLTK and Qt widgets.  With the rest of
* Duplication of effort with FLTK and Qt widgets.  With the rest of
* the GUI using Qt widgets, we should eliminte the FLTK plotting widget.  To do that, we will need to make the Qt plotting widget work when Octave is started with --no-gui and ensure that all features in the FLTK widget are also present in the Qt widget.
* With 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)?
 
=== Threading Issues for Qt Graphics Toolkit ===
 
It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
 
=== Use classdef for Graphics Objects ===
 
This is a large project, but one that will likely have to be tackled at some point.
 
== Language ==


=== Improvements to classdef (the Matlab object-oriented programming framework) ===
=== Improvements to classdef (the Matlab object-oriented programming framework) ===
Line 38: Line 57:
=== String class ===
=== String class ===


Matlab now uses "" to create string objects that behave differently from Octave double-quoted strings.
Matlab now uses "" to create string objects that behave differently from Octave double-quoted strings.  We could start by creating a compatible string class, then hooking it up to the "" syntax.  No matter what, the transition will be difficult because Matlab's "" strings still treat "\n" as two characters (backslash and n) rather than a single character (newline).


=== Handle UTF-8 (or whatever) characters properly ===
=== Handle UTF-8 (or whatever) characters properly ===
Line 45: Line 64:


=== Handle single and integer values for ranges ===
=== Handle single and integer values for ranges ===
This is a compatibility issue.
=== Eliminate Special Range, Diagonal Matrix, and Permutation Matrix Data Types
Although these 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.
=== Use Special Case Instead of Range for FOR loops ===
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.


=== Local functions ===
=== Local functions ===
Line 54: Line 83:
=== Allow large files to be loaded and saved ===
=== Allow large files to be loaded and saved ===


Make the load and save commands compatible with Matlab's
* 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.
HDF5-based file format.  Matlab users expect this and we need
* Phase out Octave's own text and binary formats.  Too much effort is required to maintain the code to support all the various formats.
something like this to support large arrays anyway.


=== Matlab packages (+DIR directories in the loadpath; related to classdef) ===
=== Matlab packages (+DIR directories in the loadpath; related to classdef) ===
Line 64: Line 92:
piece is implementation of the "import" functionality and handling
piece is implementation of the "import" functionality and handling
it efficiently and in a way that is compatible with Matlab.
it efficiently and in a way that is compatible with Matlab.
=== Broadcasting for Sparse Matrices ===
This seems like a big missing feature.
=== Refactor Broadcasting ===
Are there better ways to use templates to handle function calls rather than using macros to define a set of functions for array/array, array/scalar, and scalar/array ops as in DEFMXBINOP in mx-inlines.cc?
=== Compatibility of .^ for Sparse Matrices ===
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".
=== etree for Sparse Logical ===
Matlab's etree function appears to handle sparse logical arrays.
=== Type Conversion for Indexed Sparse 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?
=== 5th and 6th Outputs for dmperm ===
Octave doesn't support those.
=== graph and digraph Functions ===
Would it be difficult to provide these?
=== RandStream and Other RNG issues ===
This is likely a large project, but it would be nice to have updated, compatible interfaces.
== Miscellaneous ==
=== MEX Interface Changes ===
Implement mxMakeReal and mxMakeComplex functions.


=== Toolboxes ===
=== Toolboxes ===
Line 81: Line 147:
* Better use of C++ features.  Especially standard library features as their implementation becomes more widely available.  For example, we might be able to simplify some things in Octave by using the C++17 filesystem and special functions libraries, if they provide results that are at least as good what we are using now.
* Better use of C++ features.  Especially standard library features as their implementation becomes more widely available.  For example, we might be able to simplify some things in Octave by using the C++17 filesystem and special functions libraries, if they provide results that are at least as good what we are using now.
* Eliminate C preprocessor macros where possible
* Eliminate C preprocessor macros where possible
=== 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


=== Documentation ===
=== Documentation ===