Announcing Octave 7.1 Release Candidate 1 availability

That change looks good to me. :+1:

IIUC, this will already return array for the colon operator with integer type operands. So, no matter how we decide to proceed (for Octave 8 or later), we won’t end up with a new type that we’d need to support at least for a couple of versions (thinking of loading files with later versions that are saved in Octave 7).

That probably means that we could clean up the code that handles loading and saving integer ranges (because they’d no longer exist). But we could also leave that in as dead code and remove it for Octave 7.2.0 (or later) if no one minds.

Is there anything else where we could possibly help?

I tried again to rework the range<T> and octave_range class so that we could store ranges efficiently. I think we can eventually make that work but the changes are too disruptive for now. So it’s probably best to go ahead with the patch I posted yesterday and work on any further changes for the next release.

We may want to remove the now unused range<T> and ov_range<T> classes (for T = float and T = octave_{u,}intN types). I can’t guarantee that the current interfaces won’t change between now and the release of Octave 8 and it would be easier to not have to worry about backward compatibility issues.


That sounds like a good plan to me.
If you’d like to push the changeset you posted earlier, I can try to help removing the classes we no longer need (maybe during the weekend?). That is if you don’t prefer to handle that yourself.

That way, we might be able to get to a new release candidate maybe in time for the meeting next week…

I pushed my changes a moment ago, including a modified version of the diff I posted here followed by another change to comment out all specializations and uses of range<T> and ov_range<T> that we don’t need. I also tried to limit range<T> to T = floating point only.

Although I earlier said I’d prefer to eliminate the range data type (not the colon operator, obviously, just the internal representation of ranges) it now seems like something we can implement without too much more effort. I’ll try to work on that relatively soon so that it will be early in the version 8 release cycle.

At this point, I’m ready to go ahead and make another release candidate with Windows binaries and maybe we can get the release out by the end of March?

One thing that would still be good to have is more tests for the colon operator. I don’t know whether we have any tests for things like


that check for both correct result type and values.


Perfect! :+1:

Let’s wait for the buildbots and GitHub actions to finish their tests. But after that with all “blockers” out of the way, I agree that we should be ready for the next release candidate. :tada:

Edit: All buildbots are green. And the only reason why the GitHub-CI is red is that the test for getframe started failing again on Windows. That’s most probably unrelated to these changes, and more related to the fact that mesa3d has been updated in MSYS2 recently which regressed that test. (We should probably just revert hg id f5587d651bc7 for now.)

Anyway, all looks good for a release candidate imho!

1 Like

Looking at the changes for hg id 2989202f92f8, they also disable range<float>. The commit message just talks about disabling range<T> for integer type T.
Is that intentional? Do we need range<float>?

I had the same clarification question. Running through tests for the edits that @jwe made, I see this:

>> s = (int8(-120) : 4 : int8(+120)); class(s), typeinfo(s)
ans = int8
ans = int8 matrix

>> s = (double(-120) : 4 : double(+120)); class(s), typeinfo(s)
ans = double
ans = range

>> s = (single(-120) : 4 : single(+120)); class(s), typeinfo(s)
ans = single
ans = float matrix

If it is intended that singles should return a matrix but doubles should return a true range type, then all is good.

I found a bug with uint64, probably an overflow. The test is:

>> hi = intmax("uint64"), lo = hi - 5, falling = hi : -1 : lo, rising = lo:hi
hi = 18446744073709551615
lo = 18446744073709551610
falling =
  18446744073709551615                     0  18446744073709551615                     0  18446744073709551615                     0

rising =
  18446744073709551610                     0                     1                     2                     3                     4

For uint8, uint16, and uint32 the above code works properly. Only uint64 is affected.

This code does work properly and helps to construct high-end ranges:

>> intmax("uint64") - 5 + (1:5)
ans =
  18446744073709551611  18446744073709551612  18446744073709551613  18446744073709551614  18446744073709551615

>> intmax("uint64") - 5 + (5:-1:1)
ans =
  18446744073709551615  18446744073709551614  18446744073709551613  18446744073709551612  18446744073709551611

EDIT: The above behavior seems to happen for anything above flintmax. For example:

>> hi = uint64(10)^18, lo = hi - 5, falling = hi : -1 : lo, rising = lo:hi
hi = 1000000000000000000
lo = 999999999999999995
falling =
  1000000000000000000  1000000000000000000  1000000000000000000  1000000000000000000  1000000000000000000  1000000000000000000

rising =
   999999999999999995  1000000000000000000  1000000000000000000  1000000000000000000  1000000000000000000  1000000000000000000

Some implicit conversion to doubles seems to be the problem, affecting only uint64 and int64, and not the other types.

@arungiridhar: In your example, what is a and what is b?

Sorry, a is hi and b is lo. Was giving more descriptive names before posting and didn’t replace all. I will edit the previous comment.

Yes, it is intentional that only range<double> create octave_value range objects. Previously we had octave_range and Range that were double only. Now we have octave_range with an internal ov_range<T> class that is only instantiated for double. I wanted to also limit range<T> to double but it was easier to allow range<float> as well even though we are constructing float arrays instead of ranges for float : float : float expressions. See the comment for the make_float_range function in that constructs float arrays for colon expressions.

1 Like

I’ll take a look at that problem. I’m guessing it is a mixed type arithmetic problem when constructing the range values.

Thank you, @jwe. I see what you intend and I’m good with it.

Please try the attached change. It seems to work for me. If you agree, I’ll push a changeset soon.

range-increment-diffs.txt (2.5 KB)

Yes, that edit works properly for me. Thank you, @jwe!

I pushed a modified version of that patch. It would be great to have more tests for expressions like this.


I created a new release candidate (7.0.92) in the mercurial archive and am uploading the source tar files to now. I’ll create Windows binaries and upload those next.


Since this thread is titled “Announcing Octave 7.1 Release Candidate 1 availability”, should there be another thread titled “Announcing Octave 7.1 Release Candidate 2” so that it gets disseminated widely?

Yes, please go ahead and create a new topic. The tar files and windows binaries should be on now.

Done! ANNOUNCEMENT: Octave 7.1 RC2 now available!

1 Like