Re: unary mapper system redesigned + a few questions

[John W. Eaton]

On 18-Nov-2009, Jaroslav Hajek wrote:

| On Tue, Nov 17, 2009 at 9:40 PM, John W. Eaton <address@hidden> wrote:
| 
| > On 17-Nov-2009, Jaroslav Hajek wrote:
| >
| > | No. Quoting the C++ standard:
| > |
| > |        template<class T> complex<T> log(const complex<T>& x);
| > |   Notes: the branch cuts are along the negative real axis.
| > |
| > |   Returns: the complex natural (base e) logarithm of x, in the range of a
| > | strip mathematically unbounded
| > |      along the real axis and in the interval [-i times pi, i times pi ]
| > | along the imaginary axis. When x is a
| > |      negative real number, imag(log(x)) is pi.
| > |
| > | ..end of story.
| >
| > Sorry, but I don't see why
| >
| >  (0, -1) / (large representable number)
| >
| > should be considered to have a complex imaginary part yet
| >
| >  (0, -1) / inf
| >
| > should not.
| >
| >
| This is what Octave does for (0, 1), so substitute in (0, 1) and use the
| same reason.

I've thought some more about the log example I gave and I can also now
see some justification for the result that the math library produces.
I also agree that we will have a lot of potential confusion and
trouble if we try to do this operation in a way that is different from
what the implementation languages (C++, C, Fortran) compute.  That's
also a reason for not trying to introduce a pure imaginary type in
Octave without having it in the implementation languages, unless we
want to rewrite those too (I don't)...

Maybe these issues are also arguments against any automatic narrowing
from complex to real, since that is also different from what the
implementation languages do.  At this point I'm not convinced that
automatic narrowing from complex to real is a good thing to do.  But I
don't see that we have much choice about that if we want compatibility
with Matlab.  I'm certain that people would notice if we never
narrowed complex to real.

For real values, we should still preserve -0 and print it, correct?
And we can still produce complex values with -0 imaginary part, using
the complex function (though I guess it will easily be lost on
subsequent operations)?

OK, then I suppose you should check in the change.

If you make this change, then we should probably also rethink what
happens in functions like

  bool
  ComplexNDArray::all_elements_are_real (void) const
  {
    octave_idx_type nel = nelem ();

    for (octave_idx_type i = 0; i < nel; i++)
      {
        double ip = std::imag (elem (i));

        if (ip != 0.0 || lo_ieee_signbit (ip))
          return false;
      }

    return true;
  }

If we are narrowing to real based on the simple check of ip != 0, then
shouldn't this function also return true if the imaginary parts of all
elements are != 0 and ignore signbit?  If so, then I think the only
place we would use lo_ieee_signbit is in printing values.

jwe