sort error with ranges

David Bateman David.Bateman at motorola.com
Fri Feb 8 02:57:53 CST 2008


John W. Eaton wrote:
> On  5-Feb-2008, David Bateman wrote:
>
> | Michael Goffioul wrote:
> | > With CVS from yesterday:
> | >
> | > octave.exe:7> complement([1,2,3],[1,2,3,4,5])
> | > ans =
> | >
> | >    4   5
> | >
> | > octave.exe:8> complement([1,2,3],1:5)
> | > error: octave_base_value::sort (): wrong type argument `range'
> | > error: evaluating if command near line 62, column 3
> | > error: called from `unique' in file
> | > `D:\Software\VCLibs\local\octave-vc8-debug\share\octave\3.0.0+\m\set\unique.m'
> | > error: evaluating postfix operator `.'' near line 55, column 19
> | > error: evaluating assignment expression near line 55, column 7
> | > error: evaluating if command near line 54, column 3
> | > error: called from `create_set' in file
> | > `D:\Software\VCLibs\local\octave-vc8-debug\share\octave\3.0.0+\m\set\create_set.m'
> | > error: evaluating assignment expression near line 48, column 7
> | > error: evaluating if command near line 42, column 3
> | > error: called from `complement' in file
> | > `D:\Software\VCLibs\local\octave-vc8-debug\share\octave\3.0.0+\m\set\complement.m'
> | >
> | >
> | >   
> | What about the attached
>
> 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/
> 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.

> 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.

> 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.

D.

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



More information about the Bug-octave mailing list