setintersection assumes sets have no repetitions? [message #83312] |
Sat, 23 February 2013 12:46  |
penteado
Messages: 866 Registered: February 2018
|
Senior Member Administrator |
|
|
I am using Coyote's set functions, and I noticed that when I use some
(not any) sets with repetitions as input, it crashes:
IDL>
a=[1,2,3,4,5]
IDL>
b=[1,2,2,2]
IDL>
print,setintersection(a,b,indices_a=ia,indices_b=ib,position s=pos)
% Compiled module: SETINTERSECTION.
% Compiled module: REVERSEINDICES.
% Compiled module: ERROR_MESSAGE.
Traceback Report from SETINTERSECTION:
% Out of range subscript encountered: BINDICES.
% Execution halted at: SETINTERSECTION 192 /software/idl/
others/idl-coyote-read-only/coyote/setintersection.pro
% $MAIN$
-1
Is this the expected behavior? Are the input sets supposed not to have
repetitions? The documentation suggests they may have repeated
elements, thus making the positions array different from indices_a.
|
|
|
|
Re: setintersection assumes sets have no repetitions? [message #83643 is a reply to message #83455] |
Thu, 14 March 2013 13:29  |
bobgstockwell
Messages: 3 Registered: March 2013
|
Junior Member |
|
|
On Tuesday, March 5, 2013 12:00:54 PM UTC-7, David Fanning wrote:
> Paulo Penteado writes:
>
>
>
>> I just noticed that the documentation changed, to say that indices_a
>
>> and indices_b require the intersection elements to be unique, while
>
>> positions does not.
>
>
>
> I'm still waiting for Bob Stockwell to get back to me. It's his code. I
>
> just change the stuff I understand. ;-)
>
>
>
> Cheers,
>
>
>
> David
Hi Everyone,
sorry, even as someone who programs in IDL daily for the past few decades, I don't read this newsgroup very much.
Paulo, yes that is expected behaviour as the routine is written. It is defined to return both reverse index arrays of unique identifiers. I can extend that to repeated elements in the 'b' array easily enough, but the problem withrepeated matches in both is that you (potentially) have more matches than array elements and certainly would have different numbers of matches for each element which would require a ptr array for the results.
In fact, that calculation shouldn't even be executed unless the user requests it.
I'll take a look at the code and see what modification would seem reasonable. And an example would probably be nice to add as well.
cheers,
bob
|
|
|