I was interested in something slightly different when I proposed this. The Projects page on the wiki is good for just that, potential ideas to implement. Instead, I wanted to explore what major themes we might pursue for the Octave 7 release. After a theme (or two or three) was picked then projects would be selected to support that theme. Some possible organizing ideas that I had:
-
Improve graphics
** better graphic performance (plots of many polygons, such as through patch(), are much slower than OpenGl is capable of)
** hide the fact that OpenGl uses single precision variables (this has been on the wishlist forever)
** allow for very large datasets (right now we pass all points to OpenGl for ploting which can be slow for a million points)
** have an architecture review by an OpenGl expert (do we have enough in Octave’s fund to pay for a 4-hour review). I think we must be doing some things inneficiently.
-
Improve performance
** JIT compiler (this is a big one, but it has to happen sometime)
** overall performance has slowed considerably from earlier versions of Octave (3.4.X seems to have been the best). Use profiling and other tools to eliminate some of the slowdowns
** performance for certain operations like struct field lookups should be O(log2(N), but is not. Given that we are mapping on to C++ data structures which have this behavior it must be something that Octave is doing that prevents us from reaching full performance.
-
Code Base and technical debt
** complete BIST regression suite. It is easier to speed through the design/build/test cycle if we know we have a complete regression suite which will catch any bugs.
** create a performance regression test suite. Right now we can’t code with confidence that we aren’t solving a functional problem but also creating a performance one.
** reduce unnecessary functions in core so there is less to maintain. I’m thinking of a number of very UNIX-y sysadmin functions which we basically get for free, but are still cluttering and not really germane to numerical analysis. I would rather have people use a language like Perl if they want to do sysadmin. The functions could be shunted off to a new package.
-
Matlab compatibility
** strings class (bite the bullet and implement this and, probably, get rid of Octave’s very UNIX-y way of understanding single and double quotes)
** “argument” input validation blocks
** others? Seems like there are tall arrays, dataframes, etc.
-
Octave-only functionality
** built-in hash operator. I would like to see an O(1) search function incorporated in to the Octave language, similar to hashes in Perl or dictionaries in Python. This would be an extension over what Matlab provides, and could be used to implement containers.Map more easily as well as data frames.
** new efficient algorithm for eigenvectors. See https://www.quantamagazine.org/neutrinos-lead-to-unexpected-discovery-in-basic-math-20191113. It turns out the mathematics are sound and have been re-discovered from time to time. It probably beats what is in LAPACK.
These are a few themes, there could be more. For example, I haven’t even mentioned UI/UX because it isn’t a big deal for me, but I know others might want to make that a focus.