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

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

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)

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

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

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

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.

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.