Two answers: first, both "ismember" and "unique" are m-code functions. Thus,

in order to use them you need the whole interpreter. This is also possible,

but calling it from fortran would be even more effort than from C++. Of

course, under the hood it is "sort" that does the work, and that is a

compiled function. So if you could transform your code to use "sort", you

would not need the interpreter.

And that is then the second answer: no, of course it is not matrix

manipulation as implemented by LAPACK and BLAS that you want here, but it is

just sorting. Octave's sort is taken straight from some python

implementation, by the way. But even plain C has a sorting function (qsort)

in its standard library, C++ will have lots of them, and probably also

Fortran has some sorting function in its standard library (and if not, you

could definitely find one in a permissive licence on the web).

As to how this is used for "ismember" and "unique": unique is just that you

sort your input array (takes O(N*log(N)) time and O(N) space) and step

through it and take only the elements that are different from the element

before (takes O(N) time and additional O(1) space). As regards ismember: if

it is just to test once whether a single element x is a member of a large

vector S, nothing will beat the trivial solution of stepping through S and

testing whether x is equal to S(i). This would be even much faster than

Octave does it. Also if you have a small vector A of, say, N_A=10 elements,

and you want to test which of these are in S, where S is large, say N_S=one

million elements, the trivial solution will be the best. However, this

scales with O(N_S*N_A). If A is larger, at some point it will become

beneficial to first sort S (takes O(N_S*log(N_S))), and then test the

elements by bisection (takes O(N_A*log(N_S))). However, if N_A is much

larger than 1 but still much smaller than N_S, it would be even better to

sort A and step through the elements of S. Another possibility that could be

competitive if N_A and N_S are the same order of magnitude is to sort both A

and S, and then step through A and S simultaneously: if A(i)<S(j) increment

i, if A(i)>S(j) increment j, and if they are equal, you know that A(i) is in

S, and you increment both.

So you see, you can definitely be much faster than Octave can ever be,

because you know about your specific situation, while Octave's algorithms

have to have acceptable behaviour in all situations. For instance, it could

be that you can generate A or S so that they are sorted all the time. Or

perhaps you test not just once, but many times, in which case you can keep

the ordering.

--

Sent from:

https://octave.1599824.n4.nabble.com/Octave-General-f1599825.html