bugGNU Octave - Bugs: bug #32053, matlab/Octave differences for...

 
 

bug #32053: matlab/Octave differences for complex

Submitter:  Michael Godfrey <godfrey>
Submitted:  Wed 05 Jan 2011 06:16:38 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  godfrey Open/Closed:  * Closed
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 04 Sep 2013 06:22:41 AM UTC, comment #14: 

2 years since the last comment, I'm going to call this one as resolved.

Mike Miller <mtmiller>
Group Member
Sun 04 Sep 2011 11:22:54 PM UTC, comment #13: 

Can this issue report be closed now?  The changeset was applied and I don't think anything else will be done on this issue.

Rik <rik5>
Group administrator
Sun 08 May 2011 04:18:19 PM UTC, comment #12: 

Thanks!  Is there anything else we should do for this bug?  It seems there wasn't really consensus about the rest.

Daniel Kraft <domob>
Fri 06 May 2011 10:49:01 PM UTC, comment #11: 

Daniel, thanks for the changeset.  I checked it in on the default branch with a few edits to the log message.

I don't see the failures when I run make check, either before or after applying the changes.  You should take a look at the test/fntests.log file to see what is causing the problem for you.

The .texi files are generated from the .txi files.  Take a look a the .txi files and you'll see that there are lines like @DOCSTRING(whos).  The build process substitutes the docstring from the DEFUN macro into the .txi file when it generates the .texi file.  So modifying the text in DEFUN is all you need to do.

John W. Eaton <jwe>
Group administrator
Fri 06 May 2011 06:31:35 PM UTC, comment #10: 

Here's a first attempt at a patch that adds a new entry in the attribute column to 'whos' (for complex variables).  I tried to update the docs also, but doc/interpreter/var.texi seems to be not under version control - is this automatically generated?  Do I have to change something else, or is this already done with my patch?

make check reports 5 failures:
  src/DLD-FUNCTIONS/str2double.cc ........................ PASS   17/20   FAIL 3
  src/data.cc ............................................ PASS  621/622  FAIL 1
  scripts/help/doc.m ..................................... PASS    0/1    FAIL 1

It does not immediately look to me as if it had anything to do with my patch, but I did not yet really understand the test-suite mechanism in Octave...  Do I have to update something here, too?  Or can I possibly add a test-case?

Finally, I hope I got the hg mq stuff correct now.

(file #23359)

Daniel Kraft <domob>
Tue 05 Apr 2011 07:59:14 AM UTC, comment #9: 

So as far as I see, there's consensus about adding "complex" information to whos but not about the narrowing down.  So I'd like to start on a patch to implement the whos information.

Does this sound like a good plan?

Daniel Kraft <domob>
Mon 10 Jan 2011 01:23:11 AM UTC, comment #8: 

Jaroslav wrote:
But making the whole matter even more complex by introducing some rules about which expressions are narrowed and which aren't sounds definitely like a bad idea to me.
============================================

I cannot follow this.  There are rules already: they are what
the code does.  And, as they are now, they are definitely
confusing, at least to me.  I have not found anyone who says
"I would expect some elements of a complex-valued array to be
other than complex."

But, I also agree with Jaroslav that introducing new rules without careful thought is not a good idea.  In any case,
making things
more visible will help.  This is why the change to whos should
be done.  It should still tell the truth whether or not
any changes are made to the "rules."

Michael Godfrey <godfrey>
Group Member
Sun 09 Jan 2011 07:58:15 PM UTC, comment #7: 

I'm against such a change. Indexing arrays is just an expression, in Octave even more so than in Matlab. The feature that complex results of expressions are automatically narrowed if possible has its pluses and minuses, but in total I think pluses prevail somewhat. But making the whole matter even more complex by introducing some rules about which expressions are narrowed and which aren't sounds definitely like a bad idea to me.

Jaroslav Hajek <highegg>
Fri 07 Jan 2011 03:49:35 AM UTC, comment #6: 

I agree with John's comment that this discussion should move to
the maintainers list.  It deserves a wider audience.

My final comments here are:

1. Is it still good practise for improved performance to preallocate variables.  For example:
A = complex(zeros(100,), zeros(100));  ?
If so, it might be good to actually do the allocation.

2. I asked around the lab (ISL, Stanford) about how Matlab
does this.  A typical response was by Stephen Boyd who said:

"i m not a wizard, nor even a fan, of matlab.

it's extremely poorly designed, as examples like this show."

Others were less positive.

So, I would argue that in this case doing it right should be
given some serious thought, within all the usual constraints
including "reasonable" compatibility with Matlab.

My own hope is that Octave will not only be freely available
and widely used, but will also  demonstrate the high
quality that is attainable in this framework. 

Michael


Michael Godfrey <godfrey>
Group Member
Thu 06 Jan 2011 07:37:29 PM UTC, comment #5: 

If we changed Octave to not perform the complex->real conversion, then some other strange things would happen and people would complain about that, I'm sure.  For example, I'd be that there would be complaints that things like


x= [1, i];
x(1)*Inf


would now generate complex values with NaN imaginary parts.  Or should we  ignore the zero imaginary part in the multiplication to avoid generating the NaN even though we are keeping it around to preserve the idea that the value is complex?

See also  https://savannah.gnu.org/bugs/?31974
if you have not been followinwg the comments on that bug report.

As with that report, I think we should move any further discussion about this issue to the maintainers list since that will maybe get more people involved in the discussion.

John W. Eaton <jwe>
Group administrator
Thu 06 Jan 2011 07:28:38 AM UTC, comment #4: 

In comment #3 it was said:
When you do

cc = complex(1,0)

you create a complex object (real and imaginary parts both allocated). But when you write cc(1), the result is subject to a narrowing conversion, so if the imaginary part is zero, it is discarded and the result is real and the imaginary part is no longer allocated. That's what isreal is telling you, since it tests whether the complex part is allocated, not whether the imaginary part is zero. Is that behavior different in Matlab?
============================================

Exactly.  Seems like a confusing choice, which is also what
Matlab does.  It would be appropriate to create a
complex as requested.  The fact that the imaginary part is zero does not mean it does not exist.  If I type x = 0; I
expect a real which contains 0. For example:
octave:1> cc(1)=complex(1,0)
cc =  1
octave:2> iscomplex(cc)
ans = 0
octave:3> isreal(cc)
ans =  1
octave:4> cc(2)=complex(1,1)
cc =

   1 + 0i   1 + 1i

octave:5> isreal(cc)
ans = 0
octave:6> iscomplex(cc)
ans =  1
octave:7> isreal(cc(1))
ans =  1
octave:8> whos
Variables in the current scope:

  Attr Name        Size                     Bytes  Class
  ==== ====        ====                     =====  =====
       ans         1x1                          1  logical
       cc          1x2                         32  double

Total is 3 elements using 33 bytes

======================================
In this case, unlike the example in #3, the "real"
is allocated as complex (in size), but claimed to be a real element of a complex array. Formally, this does not make sense.
(Matlab does the same.  Not a good excuse.)

Michael

Michael Godfrey <godfrey>
Group Member
Wed 05 Jan 2011 06:47:16 PM UTC, comment #3: 

"I understand that cc and cc(1) are real elements of
a complex array. But, they are allocated storage as if
they were complex (a good thing, of course). "

When you do


complex (1, 0)


you create a complex object (real and imaginary parts both allocated).  But when you write cc(1), the result is subject to a narrowing conversion, so if the imaginary part is zero, it is discarded and the result is real and the imaginary part is no longer allocated.  That's what isreal is telling you, since it tests whether the complex part is allocated, not whether the imaginary part is zero.  Is that behavior different in Matlab?

The one strange thing is this part:


octave:26> zz(1) = complex(1,0*j)
zz = 1
octave:27> isreal(zz)
ans = 1


but I think this happens because the narrowing conversion is applied on assignment.  Is this behavior different in Matlab?

The only differences that I see are that Matlab doesn't print the zero imaginary parts (something I don't think we should copy) and it shows "complex" as an attributed in the output of whos.

John W. Eaton <jwe>
Group administrator
Wed 05 Jan 2011 06:31:28 PM UTC, comment #2: 

John,
I understand that cc and cc(1) are real elements of
a complex array.  But, they are allocated storage as if
they were complex (a good thing, of course).

The following example (both Octave and Matlab) adds a bit
of confusion, I think:

octave:23> zz = complex(1,0*j)
zz =  1 + 0i
octave:24> isreal(zz(1))
ans =  1
octave:25> isreal(zz)
ans = 0
octave:26> zz(1) = complex(1,0*j)
zz =  1
octave:27> isreal(zz)
ans =  1
octave:28> isreal(zz(1))
ans =  1
octave:29>
======================
Matlab is slightly different in that it, of course,
shows:

>> zz(1) = complex(1,0*j)


zz =

     1

=======================
I agree that the whos output should be made like Matlab.

Michael Godfrey <godfrey>
Group Member
Wed 05 Jan 2011 08:10:17 AM UTC, comment #1: 

In your example, cc(1) is no longer complex in either Octave or Matlab.  Try for example


isreal (cc)
isreal (cc(1))


and note that isreal tests whether the underlying data is stored as complex or real, not whether individual elements have zero imaginary part.

I agree that it could be useful to modify the output of whos to display the "Attributes" info.

John W. Eaton <jwe>
Group administrator
Wed 05 Jan 2011 06:16:38 AM UTC, original submission:  

There are differences between matlab (R2009b) and Octave for
complex variables:

Octave:
octave:18> cc =  complex (zeros(2,2), zeros(2,2))
cc =

   0 + 0i   0 + 0i
   0 + 0i   0 + 0i
octave:20> cc(1,1)
ans = 0
octave:25> whos('cc')
Variables in the current scope:

  Attr Name        Size                     Bytes  Class
  ==== ====        ====                     =====  =====
       cc          2x2                         64  double

Total is 4 elements using 64 bytes
===========================================
Matlab:
 cc =  complex (zeros(2,2), zeros(2,2)) 

cc =

     0     0
     0     0
 cc(1,1)

ans =

     0
 whos('cc')
  Name      Size            Bytes  Class     Attributes

  cc        2x2                64  double    complex  

================================================

Both can be comfusing:
1. cc(1,1)  answer appears to indicate double not complex
   for both Octave and Matlab.

2. cc       answer for Octave seems best. Matlab seems
            to indicate double.

Note: the cases above apply only is the imaginary part is
      zero.

Output of who('cc') is better from Matlab. The 'attribute'
column is useful, particularly since if the imaginary parts are
all zero the variable appears to be double.

It is not clear how to deal with compatibility in the case.
The "best" change would be to make cc(1,1) show 0 + 0i,
as it does for cc even though matlab does not do this,
and add the correct Attribute column for whos('cc').

If this does not pass the compatibility test, at least make
some changes to make it clearer that a complex variable
with zero value for the imaginary part is actually complex.

This is partly just to have the Matlab/Octave differences
recorded in case this issue comes up again.


Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #23359:  complex.diff added by domob (3KiB - application/octet-stream - First patch to add 'complex' attribute to whos.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by domob (Posted a comment)
  • -email is unavailable- added by highegg (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by godfrey (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
    2013-09-04 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed
    2011-05-06 domob Attached File- Added complex.diff, #23359

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code