Would the range class a template be cleaner?
Would not require test in do_colon_op.
Seems a good idea to me. No obvious sideeffects.

For better compatibility with Matlab, the class of an expression like
should be int8. That might be fairly straightforward to handle by fixing the do_colon_op function in ov.cc, at least when special storage for ranges is disabled. Or we could make the Range class a template so that it can handle types other than double.

The possible source of confusion I see is not that range types are not preserved in some functions, but that the class of the range is always double. I think the base assumption might be that a range constructed from type X variables would itself be of type X. See an example below with uint8.
I'm not arguing to change this, as I think it would involve a lot of code for very few actual usage cases; just pointing out that this probably violates people's internal expectations.
If there was a change to make to the Range class I would like to see the extension to column vectors. I understand why Ranges were implemented first for row vectors to compact the argument to a for loop. But it has always seemed a little strange that x = 1:50 is fine but taking the transpose with y = x' undoes all of the magic.

I created the range type as a space optimization for the colon operator in the scripting language because I didn't think it made sense to run out of memory for an expression like
I could have restricted this optimization just to FOR loops, but then things like the above would be allowed but
would still fail. It didn't occur to me to also allow the range type to allow integer types or to be Ndimensional (with all but one dimension == 1). I suppose we could make those changes now if we really wanted to, but it seems like a lot of work for little gain.

I think it would be possible to use a template to avoid duplicating a lot of code if you want to provide integer and float versions of the mixed range/scalar operators. But is it really necessary? For
I get "range", so it seems like Octave is already doing the right thing.

Rik: OK. Just wanted to point this out. What you
say makes sense.
John may have a bit of time to comment on all this
in a wellinformed way.

ranges only exist as "row" vectors. If you do anything that reshapes the row vector into something else then Octave converts to a matrix and manipulates that instead.
For example,
I suppose one could arrange for flip.m to have a special case that checks the typeinfo() of the input and if it is a range then it reverses it. But that might be overkill for how often it gets used. Most ranges seem to be used for indexing or for loops and so there is not much reason to call flip on them.
For changing a range by multiplication or addition/subtraction see the following function prototypes in Range.h
As you can see, only arguments of type double are supported. One could expand this to include single and all the integer classes, but it would certainly lead to a lot of similar looking code (7 functions * 9 types = 63 new declarations). I'm not sure it's worth it since this seems like a low probability way of using ranges.
In all of these cases Octave falls back to a full matrix which is exactly what Matlab does so it is no worse than the competition. I think we would want to go to the trouble of coding this only if these are reasonably frequent usage cases.

An additional comment on type range:
Only type double variables multiplied by or used
for add/subtract of the righthand side of
the construction:
r = x1:x2:x3;
produce an r of type range.
Would it lead to problems if int[8,16,32,64] and single types
were allowed as multipliers or add/subtract values
preserving the type range?

Bug #45739 has brought to light the fact that some
functions which are expected to return a result of
the same type as the input that is to be processed
fail to do this in the case that the input is type
'range'.
At the base of this is: flip. For example:
>> r = 1:2:7
r =
1 3 5 7
>> a= flip(r,2)
a =
7 5 3 1
>> typeinfo(a)
ans = matrix
>>
This affects at least: fliplr, flipud, rot90, rotdim.
permute is also invoked in these functions.
