Goals for the next release

I concur.

It is no secret that Octave’s OpengGL rendering engine is written using the old school direct pipeline. This part of the API is at least discouraged and often deprecated. So yes, it would be great if we could hire someone to help us switch to modern OpenGL (glsl shaders, vertex buffer objects, …).

Fascinating stuff.
Reading up in the references of that article, I get the impression (but I may be wrong) that a performance gain is to be expected for (some types of) band matrices, not so much for general “random” matrices. But large “full” matrices are better avoided anyway. so yeah there’s some “perspective”.
Let’s wait until this is picked up more widely and actual implementations turn up that we can use for a start.

Dear All Octave Developers,
Will there be an image-acquisition package which also works for imaging devices connected to Windows OS? :upside_down_face:

I heard that the present package only works for imaging devices connected to a Linux OS.

@HKPhysicist: Generally, Octave “core” and the packages aren’t maintained by the same group of (voluntary) developers.
This thread is about the next release of core Octave. You’d have to ask the package developers of the image-acquisition package if they plan to support other platforms…

Another theme I forgot to mention

  • Documentation
    • Split Octave manual in to a Language Reference Manual which is strictly about documenting the language and its functions, and an Applications Manual which is a guide to using Octave that contains less formal language and many examples.
    • Ensure that every function which returns a value documents that in the function prototype. Lots of old Octave functions assumed that the user understood a value would be returned.
    • Enforce a common format with function prototypes, 1-line summary description, description of function, description of inputs, description of outputs, application notes (tips), references, and examples.
1 Like

I opened a new topic for the replacement command window and posted a (very!) preliminary patch here:

My Wish Item:
Please update Octave Coder for Octave v6.1.

Thanks for your attention. :hugs:

AFAIK, that project isn’t managed or developed by the core Octave developers. You should probably contact the person responsible for it at their github project page.

I’m a big fan of everything @rik has laid out in the “Matlab compatibility” and “Documentation” items here.

As far as dataframes (called “table arrays” in Matlab) are concerned, I have a proof-of-concept/beta-quality implementation of tables in my Tablicious package for Octave (GitHub - apjanke/octave-tablicious: Table (relational, tabular data) implementation for GNU Octave) and as discussed on the Maintainers mailing list, would be happy to contribute that upstream to core Octave and do some work to get it integrated. I’ll work on improving the documentation for it so that it’s easier for y’all to assess its suitability.

FWIW, in my Matlab work lately, I’ve been making a fair amount of use of Matlab’s new “argument” input validation blocks, and have found them to be very useful and convenient. Would be nice to see Octave get that.

And as you can probably guess, I’m a fan of “biting the bullet” on string arrays/Matlab char compatibility/double-quoted-string-literals. But that’s from the perspective of someone who values compatibility with Matlab code much higher than back-compatibility with older Octave codebases.

@rik: For a hash operator, are you thinking it would be pass-by-value like a normal Octave array, or pass-by-reference like a handle object? Matlab’s containers.Map is handle/pass-by-reference, and in practice that turns out to make it not very useful, because you can’t mix-and-match it with other regular pass-by-value Matlab data structures. I’ve seen almost no use of containers.Map in my own code or in the wild, and I suspect it’s largely for this reason.

I don’t do it so much anymore, but I use to code a lot of Perl. And having scalars, lists, and hashes as fundamental data types built in to the language made it very easy to construct more complicated data structures like data frames.

I’m with you in that my code never uses containers.Map, and that is a shame because often a hash is what I’m looking for. I usually resort to strcmp or find (O(n) performance) which are fine only as long as the problem set is small.

Even the ostensible alternatives in Octave don’t work well. Octave’s struct data type is built on top of C++ std::map. This should be a good solution as the field names are the keys in std::map and the C++ STL keeps those keys in sorted order and guarantees search time is logarithmic (presumably, O(log2 (n)). But, because of inadequacies on our side, the performance of a lookup like isfield is linear in size (O(n)). See this bug report about that issue GNU Octave - Bugs: bug #58105, isfield needs time proportional to... [Savannah].

Perhaps this is just a long-winded way to say that we need to improve things in Octave, and once improved it needs to be adopted by both core Octave programmers and by regular users. If pass-by-value helps increase adoption then I’m all for it.

It’s been a while since we had a virtual Octave meeting on Jitsi. I propose that we have another one with this topic, “Goals for the 7.0 release”, as the primary theme.

@jwe: This post has subsequently received 2 Likes. Can you make it happen on Jitsi? I’m out next week, but otherwise ready to attend.


@rik: Oh I’m with you. I’d really like to have an efficient hash/dictionary/associative-array type in Octave, as long as it was pass-by-value instead of pass-by-reference. (Octave’s struct is better than Matlab’s in this regard, because it allows arbitrary strings as keys, not just valid identifiers/variable names, right? But you’re still limited to strings as the key type; not ideal.)

I’ve added some developer documentation for Tablicious:

Including stuff on the “proxy key” trick:

If anything in the doco isn’t clear, or you’d like to see more stuff in there, drop a request on the repo Issues tracker at:

1 Like

Thanks @apjanke, very impressive! The issue might be that you have done some much work already that it might be difficult for anyone apart from you to know where to begin or what to do next.

Is Arrow something we should consider at this stage?


Octave might want to add Apache Arrow support at some point, but I don’t think it’s necessary or useful for table and the other stuff Tablicious provides, so it could be a separate project at any time.

Octave already has approaches for representing in-memory columnar data: planar-organized classdef classes are one approach, and table is another. These are nice fits for Octave because they compose over all the functions and types that are already defined in Octave, and they allow extension at the native M-code level by definition of classdef classes. Arrow basically provides the same functionality, but at a lower level; you’d have to completely write a wrapper layer for it, and it would be very hard to get arrow to integrate with classdef/MCOS classes. I think Octave would probably just want to consider Arrow to be an external data format, and provide support for converting between it and native Octave data structures, and maybe an MCOS classdef bridge for people who want to define Octave record types over Arrow storage.

Tablicious is kinda large. I’m up to 33,000 lines of M-files by now. :slight_smile:

As for where to start, we discussed this a bit on the mailing list: I think the first thing someone (like a GSoC student) would want to do is get familiar with relational theory and in-memory columnar data stores (e.g. by reading C. J. Date books like “Database in Depth”) and then decide if the basic data structure and algorithmic approach used by Tablicious’ table is the way that Octave wants to do it. Tablicious’ approach is:

  • Every “variable” in an array is just an Octave column vector or 2-D array, of any type.
  • Those types just need to implement ()-indexing, unique(), and a couple other functions/methods.
  • All the relational operations are computed using the “proxy keys” trick.

From there, pretty much everything else falls out naturally. And if you don’t consider this fundamental issue up front, and instead start tackling table functions one at a time, I think you’re going to have trouble.

I’m happy to write more developer doco if it would be useful.

@rik - about splitting up Documentation: in addition to Language Reference and Applications Manual (which I would expect to be targeted at Octave users/clients), how about a Developer Guide for people hacking on Octave itself, that describes Octave internals, tools, source code layout and guidelines, design decisions, etc? Could start out small and grow from there.

Or maybe the Wiki is a better place for that stuff anyway.

Very interesting to see other people’s interests or priorities. Most of the following items have been mentioned before but I list below some Matlab functionalities that I see being used more and more in source code in the wild, making the Octave-Matlab compatibility slowly diverge.

Also, more specific or of lesser importance for now:

The Matlab linter is keen to suggest using new features so they easily creep in new code…

@Guillaume - FYI, the “HDF5 files” support is pretty much a prerequisite for “MAT-files version 7.3”, since they are a dialect of HDF5.

Thanks @apjanke. I’m aware of this and @jwe makes it clear here: JWE Project Ideas - Octave
I mentioned them separately as an alternative/parallel route would be to use matio:
GitHub - tbeu/matio: MATLAB MAT File I/O Library