# bug #52953: reshape() function should not narrow complex results to real

 Submitter: Colin Macdonald Submitted: Mon 22 Jan 2018 07:34:55 PM UTC Category: Interpreter Severity: 3 - Normal Priority: 5 - Normal Item Group: Incorrect Result Status: Confirmed Assigned to: None Originator Name: Open/Closed:  * Open Release:  * dev Operating System:  * GNU/Linux Fixed Release: None Planned Release: None
* Mandatory Fields

Add a New Comment Rich Markup

## Discussion

Wed 24 Jan 2018 06:13:26 AM UTC, comment #6:

More confirmation that all functions which only affect dimensions, do not produce a narrowing from complex to real.

Rik <rik5>
Wed 24 Jan 2018 04:55:05 AM UTC, comment #5:

2015b and 2014b to the same thing:

>> x = complex (0,0);
>> y = x.'
y =
0 +          0i
>> y = x'
y =
0 +          0i
>> y = permute (x, [2 1])
y =
0 +          0i
>>

"imag(x')" is "-0" as you'd expect (but recall Matlab does not display those).  But its detectable in the usual way ("1/imag(x')").

Colin Macdonald <cbm>
Wed 24 Jan 2018 12:34:28 AM UTC, comment #4:

Marking as confirmed and re-titling to reflect that the issue is that all operations which simply change the dimensions of an object should not change the storage class.

Incidentally, could you try a few more tests?

x = complex (0,0);
y = x.'
y = x'
y = permute (x, [2 1])

These are all ways to transpose a matrix, and I don't believe that it should alter the class of the variable x.

Rik <rik5>
Wed 24 Jan 2018 12:25:19 AM UTC, comment #3:

I tried a bit more at work today:

Matlab 2014a:

>> x = complex(0,0)
x =
0 +          0i
>> x(:)
ans =
0 +          0i
>> reshape(x, 1, 1)
ans =
0 +          0i

Matlab 2015b

>> x = complex(0,0)
x =
0 +          0i
>> x(:)
ans =
0
>> reshape(x, 1, 1)
ans =
0 +          0i

So the behaviour of "x(:)" seems to have changed.  This was on two different computers, but both x64 I think.

I don't think Matlab allows "complex(0,0)(:)" so the intermediate variable is the only way to test it.

I've always thought of "x(:)" as a short form of reshape, but it seems it is not so.

I agree "reshape" should have the semantics of not changing the data type.  Whereas indexing operations could narrow (b/c users expect to pull a real number out of a larger complex array for example).

Colin Macdonald <cbm>
Tue 23 Jan 2018 02:33:26 AM UTC, comment #2:

@Colin: For a good overview, see bug #52919.

Generally Octave takes the opportunity to narrow (read convert) complex arrays to real arrays whenever it can because complex arrays require double the storage.

As an example,

octave:7> x = complex (2,0)
x =  2 + 0i
octave:8> y = x(1)
y =  2
octave:9> y = x + 0
y =  2

In this case, I think using ':' is equivalent to indexing and so Octave has the opportunity to narrow the result.  I'm surprised that the reshape() function, however, changes the storage class from complex to real.

Which version of Matlab did you use to verify that ':' and reshape don't change complex results?  Also, what happens if you use an intermediate variable rather than a single expression?

x = complex (0,0)
y = x(:)

Rik <rik5>
Mon 22 Jan 2018 07:36:16 PM UTC, comment #1:

suggested BIST:

## reshaping nominally-complex values should not make them real
%!test <*52953>
%! assert (iscomplex (complex (0, 0)(:)))
%! assert (iscomplex (reshape (complex (0, 0), 1, 1)))

## reshaping should preserve signed zero
%!test <*52953>
%! z = complex ([0 0; -0 -0], [-0 0; -0 0]);
%! assert (signbit (real (z(:))), signbit (real (z))(:))
%! assert (signbit (imag (z(:))), signbit (imag (z))(:))
%! assert (signbit (real (reshape(z, 1, 4))), reshape (signbit (real (z)), 1, 4))
%! assert (signbit (imag (reshape(z, 1, 4))), reshape (signbit (imag (z)), 1, 4))

Colin Macdonald <cbm>
Mon 22 Jan 2018 07:34:55 PM UTC, original submission:

1.  I would not expect reshape and "(:)" to change the type of my data.

2.  But currently "complex(0,0)" and "complex(-0, -0)" become real when reshaped.

3.  Many functions (e.g., special functions) reshape their input before processing.  These functions are one of major reasons we have signed zero.  So if their result depends on signed zero, they cannot get it right.

4.  This is also a Matlab compatibility issue (not that I recommend blindly emulating Matlab's treatment of signed zeros).  I have confirmed that Matlab R2014a does not change the type on reshape.

5.  I will attach some BIST once I have the bug number.

Colin Macdonald <cbm>

## Attached Files

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Comment:

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by amro_octave
• -email is unavailable- added by rik5 (Posted a comment)
• -email is unavailable- added by cbm (Submitted the item)
•

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only group members can vote.