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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #31974] Interpreter fails to create complex nu


From: Judd Storrs
Subject: [Octave-bug-tracker] [bug #31974] Interpreter fails to create complex numbers with Inf complex parts
Date: Mon, 03 Jan 2011 16:14:53 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Ubuntu/10.04 Chromium/8.0.552.224 Chrome/8.0.552.224 Safari/534.10

Follow-up Comment #20, bug #31974 (project octave):

It seems like this may result from the differences in complex number
representation in Matlab and in Octave?  Matlab stores the real and imaginary
components separately whereas octave interleaves them.

If the components are stored separately, it would be trivial to get Matlab's
behavior based on the states of the pointers to the real and imaginary memory
chunks.  i.e. NaN*j would create a complex number that only has memory for the
imaginary field allocated.  In some cases when Matlab passes the value off to
the blas or whatever in some cases it will be forced to first allocate both
components of the complex value, losing the internal state and resulting in
identical behavior as octave.

So for the "1+Inf*j" Matlab could simply do "(1,unallocated)" +
"(unallocated,Inf)" by letting allocated fields simply replace unallocated
fields.  This would work without a special parser rule and copy-on-write means
there is essentially no penalty for behaving this way.

Approaching this from the interleaved representation (used in octave) it's
more difficult because both the real and imaginary parts are allocated
simultaneously as a single region of memory that cannot be separated--i.e.
octave can't hide state inside allocation patterns.

One approach would be to add a state variable to the complex values that
labels the status of the (real,imaginary) components to obtain the semantics
of the separate real/imag representation.  Another option would be to add a
pure-imaginary array similar to the pure-real arrays we already have.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]