sort error with ranges

[John W. Eaton]

On  8-Feb-2008, David Bateman wrote:

| John W. Eaton wrote:
| > I think that's fine for the release-3-0-x branch as it works and
| > is a very small change, so I applied that changeset from your archive
| > to mine.
|
| This should not be applied to the 3.0.x branch as the ranges are
| correctly treated as a double array in 3.0.x by the sort function in
| DLD_FUNCTIONS/

Oops, I see now.  I guess I would have found that if I had tried to
compile it after applying the change.  OK, I removed it from the
branch.

| > But how about the following for the development sources?  These changes
| > avoid converting the range to a matrix just to sort the values.  We
| > should probably do the same for the any and all functions defined in
| > ov-range.cc.
| >   
| Yes I'd thought about something like that then thought it wasn't
| necessarily worth it.. The reason is the mergesort algorithm will
| recognize ascending and descending runs of numbers and correctly treat
| them... The octave sort code is very efficient for such "partially"
| sorted lists. However, it might still be a bit faster to not sort at
| all, and the cost of the additional code is not large, so why not.

I was also thinking about memory usage, though the savings in sort may
end up just being a delay since I would guess that in many (most?)
cases when a range is sorted it is also likely that it will eventually be
expanded into a array of values anyway.

| > Also, shouldn't the sortmode enum be inside the octave_sort class?
| >   
| Yes, I remember trying that then stop due to an issue I can't remember.
| Why not try placing it the octave_sort class as this would be better for
| the namespace separation.

OK, I'll try to do this.

| > How is an UNDEFINED sortmode used?  Should we maybe just have only
| > ASCENDING and DESCENDING, with the default ASCENDING instead of
| > UNDEFINED?
| >   
| As you noted UNDEFINED is just treated as ASCENDING, yes it can probably
| be removed if you prefer.

OK, then I think I'll remove it.

Thanks,

jwe