octave-bug-tracker
[Top][All Lists]

## [Octave-bug-tracker] [bug #32053] matlab/Octave differences for complex

 From: Michael Godfrey Subject: [Octave-bug-tracker] [bug #32053] matlab/Octave differences for complex Date: Thu, 06 Jan 2011 07:28:39 +0000 User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110103 Fedora/3.6.13-1.fc14 Firefox/3.6.13

```Follow-up Comment #4, bug #32053 (project octave):

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

_______________________________________________________

<http://savannah.gnu.org/bugs/?32053>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

```