JWE Project Ideas: Difference between revisions

JWE Project Ideas (view source)

Revision as of 14:01, 4 June 2020

290 bytes removed , 4 June 2020

no edit summary

Jwe

Bureaucrats, Administrators

252

edits

@@ Line 1: / Line 1: @@
 <!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas -->
+{{TOC left|width=10%}}
 == Language and functions ==
@@ Line 5: / Line 7: @@
 === classdef issues ===
-==== Resolve remaining Matlab compatibility issues ====
+==== Compatibility issues ====
 Make a list here, pointing to individual bug reports?
-==== Make it possible to load and save classdef objects ====
+==== Load/save for classdef ====
 See also general load/save issues.
-==== Improve and simplify the implementation ====
+==== 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.
@@ Line 19: / Line 21: @@
 === Syntax, semantics, and data types ===
-==== Finish refactoring of function handles ====
+==== Function handle refactoring ====
 * Load/save for all types of function handles and all data formats (ascii, binary, hdf5, mat5)
@@ Line 38: / Line 40: @@
 * timeseries
-==== Handle single and integer values for ranges ====
+==== single / integer valued ranges ====
 This is a compatibility issue.
@@ Line 47: / Line 49: @@
 * Should we really have ADD_PKG and DEL_PKG files?  If so, how can we make them safe?
-==== Eliminate special range, diagonal matrix, and permutation matrix data types ====
+==== Eliminate special matrix 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.
+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.
-==== Use Special Case Instead of Range for FOR loops ====
+==== 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.
@@ Line 61: / Line 63: @@
 files.
-==== Matlab packages (+DIR directories in the loadpath; related to classdef) ====
+==== Matlab packages ====
++DIR directories in the loadpath; related to classdef
 Octave already searches for files in package directories and
@@ Line 78: / Line 82: @@
 Broadcasting does not work for sparse matrices.  This seems like a big missing feature.
-==== Treatment of structural zeros ====
+==== 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?
@@ Line 86: / Line 90: @@
 Matlab's etree function appears to handle sparse logical arrays.
-==== Type Conversion for Indexed Sparse 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?
-==== 5th and 6th Outputs for dmperm ====
+==== 5th and 6th outputs for dmperm ====
 Octave doesn't support those.
-==== graph and digraph Functions ====
+==== graph and digraph ====
 Would it be difficult to provide these objects?
@@ Line 100: / Line 104: @@
 == GUI ==
-=== Improve interface for communication between GUI and interpreter ===
+=== Communication with interpreter ===
 Currently, communication between the GUI and the interpreter
@@ Line 130: / Line 134: @@
 Generating EPS or PDF versions of figures needs improvement.
-=== OpenGL graphics system issues ===
+=== OpenGL graphics ===
 * Scaling plot data values/ranges to fit in single-precision OpenGL values
@@ Line 136: / Line 140: @@
 * Lack of WYSIWYG
-=== Duplication of effort with FLTK and Qt widgets ===
+=== 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)?
-=== Threading issues for Qt graphics toolkit ===
+=== Qt toolkit threading ===
 It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
-=== Use classdef for graphics objects ===
+=== classdef graphics objects ===
 This is a large project, but one that will likely have to be tackled at some point.
@@ Line 154: / Line 158: @@
 Try to do this in a Matlab-compatible way.
-==== Allow large files to be loaded and saved ====
+==== 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.
 * Phase out Octave's own text and binary formats.  Too much effort is required to maintain the code to support all the various formats.
-==== RandStream and Other RNG issues ====
+==== RNG issues ====
+RandStream and Other RNG issues
 This is likely a large project, but it would be nice to have updated, compatible interfaces.
-==== MEX Interface Changes ====
+==== MEX Interface ====
 Implement mxMakeReal and mxMakeComplex functions.
@@ Line 179: / Line 185: @@
 and Octave internals.
-==== loadlibrary interface ====
+==== loadlibrary ====
 This feature might be nice to have but it has a low priority.
@@ Line 187: / Line 193: @@
 Should we support this feature?  Should we refactor the implementation of array objects to make this job easier?
-==== Fix who and whos with -file option ====
+==== 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 ===
-==== General code quality improvements ====
+==== General code quality ====
 * Use C++11 features where possible.
@@ Line 207: / Line 213: @@
 * Audit global variables and eliminate them where possible
-==== Symbol visibility in shared libraries ====
+==== 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.
-==== List dispatch types for functions in source files ====
+==== Dispatch types for functions ====
 Search for "classes:" in sources to find the few current examples.
-==== Tag functions with min/max nargin values ====
+==== min/max nargin values ====
 Should we do this, and allow the interpreter to automatically error when a function is given too few/many arguments?