JWE Project Ideas: Difference between revisions

Jump to navigation Jump to search

JWE Project Ideas (view source)

Revision as of 17:45, 27 March 2024

1,142 bytes removed ,  27 March
→‎Language and functions
m (Protected "JWE Project Ideas" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading])
Line 3: Line 3:
'''2021-11-19: This page is out of date -- jwe'''
'''2021-11-19: This page is out of date -- jwe'''


== Language and functions ==
== Project Ideas ==


=== classdef issues ===
The following are projects that I'm interested in working on, roughly
prioritized by my level of interest.  I intend to provide expanded explanations of each project.


==== Compatibility issues ====
=== Comment parsing ===


Make a list here, pointing to individual bug reports?
Refactor comment handling in lexer and parser.


==== Load/save for classdef ====
=== MException object ===


See also general load/save issues.
=== FTLK graphics widget ===


==== Improve / simplify implementation ====
Eliminate fltk graphics widget or move to external package.


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.
=== gnuplot graphics widget ===


=== Syntax, semantics, and data types ===
Eliminate gnuplot graphics widget or move to external package.


==== Matlab-compatible argument validation blocks ====
=== Function objects ===


New language feature, syntax is accepted by parser now but argument validation is not performed.
Refactor function objects.


==== Function handle refactoring ====
=== arguments blocks ===


* Load/save for all types of function handles and all data formats (ascii, binary, hdf5, mat5)
Finish implementation of Mmatlab-compatible argument validation blocks.
* Use std::shared_ptr for function objects instead of bare pointer to octave_function.


==== String class ====
=== local functions ===


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).
Implement Matlab-compatible local functions in script files.


==== Other new data types ====
=== string object ===


Andrew Janke has implementations of these classes (FIX: link to repos here)
=== load_path class ===


* table
Refactor (or rewrite) load_path class.
* datetime, duration, calendarDuration
* categorical
* timetable
* timeseries


==== single / integer valued ranges ====
=== Broadcasting ===


This is a compatibility issue.
* Refactor broadcasting.
* Make broadcasting work for sparse matrices.


==== Refactor load-path ====
=== GUI command widget ===


* Directories are not properly removed from load path (FIX: link to bug report here)
Make common command widget for Windows and Unixy systems work well enough to become the default command line interface for the GUI.
* Should we really have ADD_PKG and DEL_PKG files?  If so, how can we make them safe?


==== Eliminate special matrix types ====
=== OpenGL graphics ===


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.
Modernize our use of OpenGL graphics to use shader programs instead of the legacy OpenGL API.


==== Special case FOR loop limits ====
=== classdef ===


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.
Refactor (or rewrite) classdef implementation.


==== Local functions ====
=== Qt graphics widget ===


The semantics for local functions in scripts is different from the
Refactor (or rewrite) Qt graphics widget.
way Octave currently handles functions that are defined in script
files.


==== Matlab packages ====
=== graphics properties ===


+DIR directories in the loadpath; related to classdef
Refactor graphics properties classes.


Octave already searches for files in package directories and
=== graphics threading issues ===
understands the PKG.fcn syntax and functionality.  The big missing
piece is implementation of the "import" functionality and handling
it efficiently and in a way that is compatible with Matlab.


==== Refactor broadcasting ====
Fix handling of graphics properties to be properly thread safe.


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?
=== HDF5 load and save ===


==== Sparse matrix issues ====
Implement Matlab compatible HDF5-based load and save functions.


==== Broadcasting ====
=== External editors ===


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


==== Structural zeros ====
=== who -file ===


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?
Fix who -file to just read file and list info, not create dummy scope.


==== Indexed assignment ====
=== import ===


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?
Make "import" work in a matlab-compatible way ===


==== graph and digraph ====
=== Code quality ===


Would it be difficult to provide these objects?
** 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.
** Use const in more parse tree functions.
** remove, replace, or at least rename the "added static" concept in the symbol_record class.
** Should not expose symbol_record in call_stack functions if possible.
** Remove unused symbol_table/scope/record 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.
** Audit use of panic_* functions and replace with calls to error where possible.
** Fix symbol visibility so we are mostly tagging namespace decls, not individual functions.
** Complete use of dispatch types for functions (search for "classes:" to find the few current examples).
** Tag for built-in functions to specify maxiumum number of inputs.


== GUI ==
== GUI ==
Retrieved from "https://wiki.octave.org/Special:MobileDiff/15098"

Navigation menu