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

[John W. Eaton]

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

If you really want to find out, then I think you might be able to cast an
mxArray* to char* and look at the bytes, then look at the values returned by
mxGetPr and mxGetPI and compare.  That and a little more digging might uncover
something about the layout of the mxArray object and when things are
allocated.  I don't really care to do that myself as those details don't
really matter to me.

What does matter is whether we should treat complex values with zero real
part as pure imaginary values so we don't generate NaNs when multiplying a
complex value with zero real part by Inf.  Apparently this surprises some
people because they don't realize that there are no pure imaginary values,
just real and complex.  The MathWorks apparently made this choice for Matlab,
for all cases, not just the ones Jaroslav has suggested.  So should we be
fully compatible, partly compatible, or not at all with regard to this
feature?

I'm getting feedback on another bug report about complex numbers that is
arguing against automatic narrowing of complex values that have a zero
imaginary part (which is compatible behavior).  So if we narrow there, why not
(appear to) narrow for the opposite case of zero real part?  Or why do either,
even if it means incompatibility, if not ignoring the zero part is the right
thing to do?

Whatever we do, I'm sure someone will not be happy about it.

I don't see the point of just being partly compatible here, and I don't
really like the idea that internal computations can have different results
from ones that are implemented in the interpreter operators themselves.  But
whatever we decide, I don't plan to make any changes in this until after 3.4
is released, so can we stop wasting time on this issue now?



    _______________________________________________________

Reply to this item at:

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

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