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.

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.

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.

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.

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/DLDFUNCTIONS/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 testsuite mechanism in Octave... Do I have to update something here, too? Or can I possibly add a testcase?
Finally, I hope I got the hg mq stuff correct now.
(file #23359)

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?

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 complexvalued 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."

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.

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

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.

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

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.

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.

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.

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.
