@Paco: Instead of posting to a bug report that thas been closed for a year and a half it is better to report a new bug.  I saw this only through your request to join the Octave Maintainers group, which isn't necessary.

I checked in a fix on the stable branch here: https://hg.savannah.gnu.org/hgweb/octave/rev/616b844e903a.

You can download the m-file from the Mercurial repository if you need the fix immediately.  Otherwise, it will be a part of the next bug fix release of Octave.

I have pushed http://hg.savannah.gnu.org/hgweb/octave/rev/89b0a53258b7 to fix this issue.

A possible patch to the reimplemented version is to add something like this at the beginning:

if (isnumeric(a)&&~isreal(a)) || (isnumeric(s)&&~isreal(s))
  [~, ~, u] = unique([a(:); s(:)]);
  a(:) = real(u(1:numel(a)));
  s(:) = real(u(numel(s)+1:end));
end

That is, if complex inputs are detected, replace values in the inputs by globally unique integer labels. By "globally unique" I mean unique across the two inputs. That way the lookup function will work fine.

Apparently this cset http://hg.octave.org/octave/rev/dbc61d4e428d broke ismember for complex input.

Before the "reimplementation" ismember returned [1 2 3], you can try with this http://hg.octave.org/octave/raw-file/0c4e6a3d6e3e/scripts/set/ismember.m

mark as regression

This code

x = [5 4-3j 3+4j]; [~, b] = ismember(x, x)

gives [3 3 3] instead of the expected [1 2 3].

The problem seems to be that 'ismember' uses the 'lookup' function, which was

## Reimplemented using lookup & unique: Jaroslav Hajek <highegg@gmail.com>

and 'lookup' has the comment

// In the case of a complex array, absolute values will be used for
// compatibility (though it's not too meaningful).

Well, it may not be meaningful for lookup's original purpose, but it definitely is for ismember.

It looks like ismember's second output should be obtained with something other than lookup, at least in the complex case