After spending a significant amount of time over the past couple of days looking for ways to fix the problems reported in bug #61132 while keeping the space optimization of Octave’s special range type, I’m beginning to come to the realization that it is time for us to abandon some features in order to provide more correct (and/or Matlab-compatible) behavior and to ease the burden of maintenance.
The specific problem that pushed me over the edge was trying to support things like
uint8(10) : -2 : uint8(0)
The current templated implementation of ranges (introduced about a year ago to support integer ranges) assumes that all values in the range can be stored using the same type. So the above expression to create a
uint8 range stores the base, limit, and increment as
uint8 objects. But that doesn’t work for unsigned ranges that have a negative increment (needed for compatibility). So now we may need a different type for the increment? Or do we just store the increment as unsigned and record that the range is descending? If so, then how do we support the function that returns the increment of the range? Etc.
No solution I could think of seemed good. Each thing I considered meant more code or more complicated code, or both, and those things are likely opportunities for even more bug reports and maintenance trouble in the future. OTOH, if the colon operator just created a matrix of the appropriate type, this problem would have been fixed quickly.
At this point, I’d rather have Octave be easier to maintain and working correctly (with more tests!) than save memory.
The same arguments apply for the permutation and diagonal matrix types.