<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p>Hello mailing list,</p>
<p><br>
</p>
<p>I would like to open a PR that improves the speed of intersect1d in particular for large arrays of potentially unequal sizes. As parts of the change would involve a new keyword I think I should write to this mailing list first (correct me if I am wrong).</p>
<p><br>
</p>
<p>Lets start with the current implementation of intersect1d. The steps are (roughly): I) concatenate both arrays II) sort that large array and III) keep only duplicates. This is a simple but not necessary fast implementation. In particular it has has complexity
 O( (len1 + len2) log(len1 + len2)).</p>
<p><br>
</p>
<p>I have two suggestions one of which can greatly improve the runtime (1) while the other has some minor improvements (2). Lets start with the major one.<br>
</p>
<p>1) Adding <i>assume_sorted</i> as keyword argument.<br>
    If you can already assume that the arrays are sorted you can improve the runtime to min(len1, len2)*log(max(len1, len2)) which is orders of magnitude faster especially when the arrays intersected are unequal in size.<br>
    The implementation basically is I) figure out which is the smaller array II) make that array unique III) use np.searchsorted to find duplicates of the smaller in the larger.</p>
<p>    I think that having assume_sorted as a keyword argument is quite useful, especially as the result of assume_sorted is always sorted. So chaining multiple intersections together can be made much faster.<br>
</p>
<p><br>
</p>
<p>2) Improve the performance in the case that we cannot assume sorted arrays</p>
<p>     In the case that we cannot assume that both arrays are already sorted we can still gain advantages. Mainly by sorting the arrays separately and then using np.searchsorted again. This brings the complexity down to
<span>O( len1 log(len1)  + len2 log(len2))</span> + <span>min(len1, len2)*log(max(len1, len2)</span>).</p>
<p><br>
</p>
<p>I already mention this in the issue 16964: <a href="https://github.com/numpy/numpy/issues/16964" class="OWAAutoLink">
https://github.com/numpy/numpy/issues/16964</a><br>
</p>
<p><br>
</p>
<p>Looking forward for your feedback.<br>
</p>
<p><br>
</p>
<p>Have a great day and stay safe</p>
<p><br>
</p>
<p>Felix Stamm<br>
</p>
<p><br>
</p>
</div>
</body>
</html>