Project liboctave 4.2: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(Warn outdated.) |
||
| Line 1: | Line 1: | ||
{{Warning|This page is outdated (July 2019).}} | |||
Especially for new developers it is hard to get started with liboctave, one of the core elements of GNU Octave. Liboctave defines and implements data types, operators, and much more. To change that state this long term project has the following goals: | Especially for new developers it is hard to get started with liboctave, one of the core elements of GNU Octave. Liboctave defines and implements data types, operators, and much more. To change that state this long term project has the following goals: | ||
Revision as of 06:45, 19 July 2019
This page is outdated (July 2019).
Especially for new developers it is hard to get started with liboctave, one of the core elements of GNU Octave. Liboctave defines and implements data types, operators, and much more. To change that state this long term project has the following goals:
- Document the existing code for developers (Doxygen)
- Bring all the data types into order
- Reduce the code to a sufficient minimum
- Remove macros where possible
Milestone 1 - The Array hierarchy
A first desirable milestone is to start with the root of all advanced data types. The class Array. Here is a Doxygen generated picture of the current state inside the development version of liboctave.
Questions / Tasks:
- On any changes to this structure there is an API-Constraint with Oct-Files.
- TODO: Document inside the C++-Classes that this are API relevant classes.
- Identify the difference between for example Array<char>, charNDArray, and charMatrix
- What is necessary?
- What are preservable convenience classes?
- Is there code redundancy?
- Is there a necessity to specialize?
- e.g. ComplexRowVector and RowVector vs. RowVector<T>
- Does every file name reflect its content? (Nested classes, etc.)