JWE Project Ideas: Difference between revisions

Jump to navigation Jump to search

JWE Project Ideas (view source)

Revision as of 13:45, 4 June 2020

2,568 bytes added ,  4 June 2020
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
<!-- This file should be edited at https://wiki.octave.org/JWE_Project_Ideas -->
== GUI ==
== GUI ==


Line 36: Line 38:
* Performance issues
* Performance issues
* Lack of WYSIWYG
* Lack of WYSIWYG
* Duplication of effort with FLTK and Qt widgets.  With the rest of
* 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 ===
=== Duplication of effort with FLTK and Qt widgets ===
 
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 ===


It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.
It seems likely that the locking of the gh_manager object is insufficient or even incorrect in some cases.


=== Use classdef for Graphics Objects ===
=== Use classdef for graphics objects ===


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.


== Language ==
== Language and functions ==
 
=== classdef issues ===
 
==== Resolve remaining Matlab compatibility issues ====
 
Make a list here, pointing to individual bug reports?
 
==== Make it possible to load and save classdef objects ====
 
See also general load/save issues.
 
==== Improve and simplify the 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.


=== Improvements to classdef (the Matlab object-oriented programming framework) ===
=== Syntax, semantics, and data types ===


* Resolve remaining Matlab compatibility issues.
==== Finish refactoring of function handles ====
* Make it possible to load and save classdef objects.
* Improve and simplify the 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.


=== String class ===
* Load/save for all types of function handles and all data formats (ascii, binary, hdf5, mat5)
* Use std::shared_ptr for function objects instead of bare pointer to octave_function.
 
==== String class ====


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).
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 ===
==== Other new data types ====


Try to do this in a Matlab-compatible way.
Andrew Janke has implementations of these classes (FIX: link to repos here)
 
* table
* datetime, duration, calendarDuration
* categorical
* timetable
* timeseries


=== Handle Single and Integer Values for Ranges ===
==== Handle single and integer values for ranges ====


This is a compatibility issue.
This is a compatibility issue.


=== Eliminate Special Range, Diagonal Matrix, and Permutation Matrix Data Types ===
==== Refactor load-path ====
 
* Directories are not properly removed from load path (FIX: link to bug report here)
* 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 ====


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 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 ===
==== 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.
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 ====


The semantics for local functions in scripts is different from the
The semantics for local functions in scripts is different from the
Line 81: Line 111:
files.
files.


=== Allow large files to be loaded and saved ===
==== Matlab packages (+DIR directories in the loadpath; related to classdef) ====
 
* 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.
 
=== 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 93: Line 118:
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 ===
==== Refactor broadcasting ====


This seems like a big missing feature.
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?


=== Refactor Broadcasting ===
==== Sparse matrix issues ====


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?
==== Broadcasting ====
 
Broadcasting does not work for sparse matrices.  This seems like a big missing feature.


=== Compatibility of .^ for Sparse Matrices ===
==== Treatment of 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".
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?


=== etree for Sparse Logical ===
==== etree for sparse logical ====


Matlab's etree function appears to handle sparse logical arrays.
Matlab's etree function appears to handle sparse logical arrays.


=== Type Conversion for Indexed Sparse Assignment ===
==== 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?
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.
Octave doesn't support those.


=== graph and digraph Functions ===
==== graph and digraph Functions ====


Would it be difficult to provide these?
Would it be difficult to provide these objects?


=== RandStream and Other RNG issues ===
=== Miscellaneous ===


This is likely a large project, but it would be nice to have updated, compatible interfaces.
==== Handle UTF-8 (or whatever) characters properly ====


== Miscellaneous ==
Try to do this in a Matlab-compatible way.


=== MEX Interface Changes ===
==== Allow large files to be loaded and saved ====


Implement mxMakeReal and mxMakeComplex functions.
* 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.


=== Toolboxes ===
==== RandStream and Other RNG issues ====


Move some core toolboxes (communications, control systems, image
This is likely a large project, but it would be nice to have updated, compatible interfaces.
processing, optimization, signal processing, and statistics), to
core Octave so development is managed along with Octave.  Core
Octave developers are already responsible for these packages
anyway, and users don't seem to understand why they need to
install them separately.  Core parts of the ordinary differential
equations package have already been moved to Octave.


=== General code quality improvements ===
==== MEX Interface Changes ====


* Use C++11 features where possible.
Implement mxMakeReal and mxMakeComplex functions.
* Better and more complete use of C++ namespaces.
* 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


=== Documentation ===
==== JIT compiler ====
 
* Continue to improve Doxygen documentation for Octave internals to make it easier for new contributors to understand the Octave code base.
 
=== 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 164: Line 179:
and Octave internals.
and Octave internals.


=== Windows distribution ===
==== loadlibrary interface ====
 
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?
 
==== Fix who and whos with -file option ====
 
Should just read file and list info, not create dummy scope.
 
=== Maintenance and packaging ===
 
==== General code quality improvements ====
 
* Use C++11 features where possible.
* Better and more complete use of C++ namespaces.
* 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
* added_static must go! (not sure about this now)
* Should not expose symbol_record in call_stack functions if possible
* Remove unused symbol_table/scope/record functions
* Use const in more parse tree functions
* Do recursive functions work properly with load/save now?
* Use enums for options internally (typically to replace bool values)
* Audit global variables and eliminate them where possible
 
==== Symbol visibility in shared libraries ====
 
We really should be tagging the functions that we wish to export.
 
==== List dispatch types for functions in source files ====
 
Search for "classes:" in sources to find the few current examples.
 
==== Tag functions with min/max nargin values ====
 
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
processing, optimization, signal processing, and statistics), to
core Octave so development is managed along with Octave.  Core
Octave developers are already responsible for these packages
anyway, and users don't seem to understand why they need to
install them separately.  Core parts of the ordinary differential
equations package have already been moved to Octave.
 
==== Documentation ====
 
* Docs for call stack with examples and illustrations
* Docs for lexer and parser with examples and illustrations
* Docs for fcn_info object
* Docs for load_path object
* Docs for classdef internals
* Docs for Qt graphics toolkit internals
* Docs for Qt GUI and communication with interpreter
* 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
Line 176: Line 252:
but the msys version of less depends on the msys termcap library.
but the msys version of less depends on the msys termcap library.


  bash       less       perl
* bash
  coreutils  libcrypt   regex
* coreutils
  diffutils  libiconv   sed
* diffutils
  dos2unix  libintl     tar
* dos2unix
  file      libmagic   termcap
* file
  findutils  libopenssl unzip
* findutils
  gawk      make       zip
* gawk
  grep      msys-core   wget
* grep
  gzip      patch      zlib
* gzip
* less
* libcrypt
* libiconv
* libintl
* libmagic
* libopenssl
* make
* msys-core
* patch
* perl
* regex
* sed
* tar
* termcap
* unzip
* wget
* zip
* zlib
Retrieved from "https://wiki.octave.org/Special:MobileDiff/13052"

Navigation menu