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

 
 

bug #32053: matlab/Octave differences for complex

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Wed 05 Jan 2011 06:16:38 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: FixedAssigned to: None
Originator Name: godfreyOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
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>
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

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>
Project 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>
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

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:

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>
Project 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>
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

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>
Project 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>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #23359:  complex.diff added by domob (3kB - 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
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by domob (Posted a comment)
  • -unavailable- added by highegg (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by godfrey (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 04 Sep 2013 06:22:41 AM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Fri 06 May 2011 06:31:35 PM UTCdomobAttached File-=>Added complex.diff, #23359

    Back to the top


    Powered by Savane 3.1-cleanup