bugGNU Octave - Bugs: bug #52953, reshape() function should not...


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

Submitter:  Colin Macdonald <cbm>
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

Jump to the original submission

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>
Group administrator
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>
Group administrator
Wed 24 Jan 2018 12:25:19 AM UTC, comment #3: 

Thanks for the link.

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 =
>> 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>
Group administrator
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>


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

Attach Files:

No files currently attached


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.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-02 amro_octave Carbon-Copy- Added amro_octave
    2018-01-24 rik5 StatusNone Confirmed
        Summaryreshaping &quot;complex(0,0)&quot; should not make it real reshape() function should not narrow complex results to real

    Back to the top

    Powered by Savane 3.13-0159.
    Corresponding source code