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
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.
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!
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.
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 ov.cc that constructs float arrays for colon expressions.
I created a new release candidate (7.0.92) in the mercurial archive and am uploading the source tar files to alpha.gnu.org 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?
