Disable automatic conversion to reals

Is there a way to disable the automatic conversion of a complex variable with zero imaginary component into a purely real variable?

>> x = complex(zeros(2,2)) % complex
x =
   0.0000 + 0.0000i   0.0000 + 0.0000i
   0.0000 + 0.0000i   0.0000 + 0.0000i 

>> x(2,1) = -1             % magically becomes real
x =
     0     0
    -1     0

This is bothering me because:

1. It differs from the behavior of gpuArrays, for which subsref and subsasgn preserve complexity.
2. It triggers an unnecessary memory copy (and then again when I eventually store a complex value into the matrix).
3. This is not playing well with MEX routines that expect the arguments to have the same datatype.

To that last point, consider the following:

>> x = complex(randn(4,100), randn(4,100)); % complex
>> y = x .* max(0,abs(x)-1);                % also complex
>> for ii = 1:100
       try
           z = mymexfunc(x(:,ii), y(:,ii))  % sometimes not complex
       catch
           fprintf('Error on iter %d\n',ii);
       end
    end
Error on iter 44
Error on iter 62

I thought it was safe to assume that a subscripted reference from a complex array would yield a complex array, but it turns out I was wrong.

Our C/C++ developer is pretty busy these days, so before I go bother her about adding mixed-complexity support to the MEX routines, I am wondering:

1. Is there an undocumented feature flag I can disable? Something like feature('auto_convert_reals',0) would be great.
2. Are there alternatives to parenthetical indexing that do preserve complexity?

[Walter Roberson]

Which MATLAB release? R2017b changed how complex values are stored.

[Kevin]

R2018a

Answer 1

[Edric Ellis]

MATLAB's behaviour has always been to drop the imaginary part on indexing operations (where it is all zero!). gpuArray is somewhat incompatible with standard MATLAB behaviour in this regard - this was a deliberate choice to improve performance of gpuArray indexing (since the very beginning, gpuArray has used interleaved-complex format).

Anyway, probably your best bet is to preprocess your MEX arguments using a simple MATLAB wrapper, something like this:

function varargout = matchComplexity(varargin)
% Require precisely as many outputs as inputs.
nargoutchk(nargin, nargin);
varargout = varargin;

% Check which are stored as real
isReal = cellfun(@isreal, varargout);

% If not all arrays stored as real, complexify those that are real
if ~all(isReal)
    varargout(isReal) = cellfun(@complex, varargout(isReal), ...
        'UniformOutput', false);
end
end

Clearly, you'll want to apply this only to your data arguments that are expected to match in complexity.

[Kevin]

Just out of curiosity: now that complex arrays in host memory also use the interleaved format, are there any plans to change this behavior in future releases?

Answer 2

[James Mentz]

Sorry, this is a bug, not a feature. You can have an entire array of complex number and writing a single indexed value with a number where the imaginary part = 0 will destroy all of the complex information in the entire array.

If Matlab is going to do this we need a new immutable array data type where once it's declared complex it stays complex.

I had to work around this by checking EVER value going into the array and if the imaginary part is zero I add (realmin('single') * 1i) to each entry, this doing every bit as much checking as Matlab does to make these values fragil, with the added downsize of dithering my data by realmin.

[Rik]

The point is not that this behavior occurs when imag(z_input)==0, but when all imaginary parts of the resulting array are zero. I would still consider it a bug, but it is less dramatic than your post seems to suggest.

No information is lost, only the data type changes.

Answer 3

[Jim Svensson]

I agree that Matlab's way of automatically dropping imaginary part when zero is stupid, very annyoing and it causes extra problems in many cases. I wish it could be disabled.