[Octave-bug-tracker] [bug #45758] for 'range' type input some functions fail to return type range

[Rik]

Update of bug #45758 (project octave):

              Item Group:        Incorrect Result => Feature Request        
                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #2:

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,


octave:8> x = 1:50;
octave:9> whos x
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        x           1x50                        24  double

Total is 50 elements using 24 bytes

octave:10> x = x';
octave:11> whos x
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        x          50x1                        400  double

Total is 50 elements using 400 bytes


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


extern OCTAVE_API Range operator - (const Range& r);
extern OCTAVE_API Range operator + (double x, const Range& r);
extern OCTAVE_API Range operator + (const Range& r, double x);
extern OCTAVE_API Range operator - (double x, const Range& r);
extern OCTAVE_API Range operator - (const Range& r, double x);
extern OCTAVE_API Range operator * (double x, const Range& r);
extern OCTAVE_API Range operator * (const Range& r, double x);


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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45758>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/