Disable automatic conversion to reals

11 visualizaciones (últimos 30 días)
Kevin
Kevin el 2 de Ag. de 2018
Editada: Jim Svensson el 1 de Sept. de 2022
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?
  2 comentarios
Walter Roberson
Walter Roberson el 2 de Ag. de 2018
Which MATLAB release? R2017b changed how complex values are stored.
Kevin
Kevin el 2 de Ag. de 2018
R2018a

Iniciar sesión para comentar.

Respuesta aceptada

Edric Ellis
Edric Ellis el 2 de Ag. de 2018
Editada: Edric Ellis el 2 de Ag. de 2018
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.
  1 comentario
Kevin
Kevin el 2 de Ag. de 2018
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?

Iniciar sesión para comentar.

Más respuestas (2)

James Mentz
James Mentz el 28 de En. de 2019
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.
  1 comentario
Rik
Rik el 28 de En. de 2019
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.

Iniciar sesión para comentar.


Jim Svensson
Jim Svensson el 1 de Sept. de 2022
Editada: Jim Svensson el 1 de Sept. de 2022
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.

Categorías

Más información sobre Logical en Help Center y File Exchange.

Productos


Versión

R2018a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by