[Octave-bug-tracker] [bug #45739] sort 'descend' together with vectors created with the colon operator

[Rik]

Update of bug #45739 (project octave):

                  Status:               Confirmed => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #19:

I think that the minimal changeset necessary to fix the problem is appropriate
for the stable branch.  I made that change by altering the sort_internal
function for Range objects in Range.cc.  See
http://hg.savannah.gnu.org/hgweb/octave/rev/7e9c752138ec.  I also added tests
for the correct behavior in range.tst
(http://hg.savannah.gnu.org/hgweb/octave/rev/ba032e57fd96).  That is enough to
close this bug report.

However, I still believe it would be useful to change the constructors on the
development branch to guarantee that the maximum value in the range and the
variable rng_limit are synonymous.  From the Octave command line, a range
object is created by the colon syntax.  Thereafter, like any other good C++
object, I can only interact with it through other functions but the internal
implementation is opaque.  I can query the object for the first [x(1)] or last
element [x(end)] or manipulate it with standard arithmetic operators or sort
it.  But I can't ask what the original limit used on the command line was.  So
for x = 1:2:10 there is no possibility of determining that 10 was used rather
than 9.  In C++ there is a way to do that, but I don't think it is a good idea
because it breaks the data encapsulation paradigm of object oriented
programming.

As an analogy, consider the creation of an unsigned 8-bit integer object.  On
the command line I might use x = uint8 (1.5) which produces the uint8 object
with a value of 2.  What should x - 0.25 return?  One possibility is that
Octave has internal state and remembers the value that the object was invoked
with.  In this case, 1.5 - 0.25 is 1.25 and for display purposes this would be
shown as 1.  Or, as Octave indeed does, the constructor is a one-way function
which takes inputs and creates an object without state.  Thus, uint8 (1.5) -
0.25 is equal to 2.

It will simplify the code if the range constructors are able to create a valid
range and do all limit checking just once upon object creation rather than
every time the rng_limit is reached.  Maybe this can be a side discussion at
OctConf 2015.



    _______________________________________________________

Reply to this item at:

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

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