[Octave-bug-tracker] [bug #31974] Interpreter fails to create complex numbers with Inf complex parts

[John W. Eaton]

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

Judd, I think that Matlab always allocates storage for the real part.  If you
have access to Matlab, try this mex file:


#include "mex.h"

void
mexFunction (int nlhs, mxArray* plhs[], int nrhs, 
             const mxArray* prhs[])
{
  double *pr = mxGetPr (prhs[0]);
  double *pi = mxGetPi (prhs[0]);

  if (pr)
    mexPrintf ("real part is allocated; its value is %gn", pr[0]);


  if (pi)
    mexPrintf ("imaginary part is allocated, its value is %gn", pi[0]);
}


and call it with


foo (i)
foo (1)
foo (complex (1, 0))


etc.  Can you come up with a way to make Matlab not allocate the real part of
a numeric value?  That would be interesting, because it would mean that
implemented pure imaginary values.  But I don't think they have done that. 
Instead, I think there are some limited number of places where values with
zero real parts are treated as if they are pure imaginary.  Unfortunately, I
think this special treatment also applies to computed values, not just ones
explicitly defined with the special values "i" or "j".  For example, what
happens with


x = 1 + i
y = -1 + i
z = x + y
Inf * z


Do you still see the special treatment of the zero imaginary part here, or do
you get NaN + Infi?

This topic of having a pure imaginary type has come up before.  If it is
really important to have this behavior for pure imaginary values, then I think
we need to have it consistently in Fortran, C++, C, etc., not just in some
portions of programs like Octave or Matlab.  Do we really want that kind of
inconsistent behavior?

    _______________________________________________________

Reply to this item at:

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

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