[Octave-bug-tracker] [bug #59899] colon operator returns incompatible class for integer inputs

[Rik]

Update of bug #59899 (project octave):

                  Status:                    None => Confirmed              
                 Release:                   6.1.0 => dev                    

    _______________________________________________________

Follow-up Comment #1:

It's true that octave considers all ranges to be ranges of doubles.  Changing
this to be Matlab-compatible will be disruptive so any changes will need to
take place on the development branch.

It would be helpful to understand whether Matlab internally represents the
range as doubles and only converts to the specified class at the end of the
calculation, or whether it does all calculations is the specified class.

Could you try this in Matlab?


x = uint8(1) : 0.4 : uint8(5)


If it does everything in the same class than uint8 (0.4) will be zero and this
will be the empty matrix.  Otherwise, this will be the same as


x = uint8 (1 : 0.4 : 5)


Which is a sequence with duplicate values, but otherwise valid.

What happens when the classes differ such as 


x = uint8(1):int32(5);
class (x)


Does Matlab choose the beginning class or the ending class?

What happens if the endpoints of the range exceed the capacity of the class?


x = uint8(5) : -1 : -5


Seems like there are a lot of corner cases here.  On the other hand, ranges
for integers are very easy to implement.  Octave has a sophisticated algorithm
to try and get floating point numbers to behave as people think they should
regardless of round-off errors, etc.  It might be possible to make the Range
class in liboctave a templated class with specializations for floating point. 
Would it need a specialization for 'single' types as well or can the algorithm
for 'double' be used with a cast to single at the end?

Could you try this


x = single(0):pi:100*pi;
sprintf ('%.17f\n', x(2))
sprintf ('%.17f\n', pi('single'))
sprintf ('%.17f\n', pi('double'))


This should see what increment Matlab used.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59899>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/