On Tue, Nov 17, 2009 at 1:54 PM, John W. Eaton
<address@hidden> wrote:
On 13-Nov-2009, Jaroslav Hajek wrote:
| > So it seems you made this change so that 0*(-i) produces a 0 - 0i. I think
| > it's a good time to rethink this decision.
| > First, you probably overlooked the fact that 0 - 0i is constructible with
| > complex (0, -0) - because complex() is the (only) function that bypasses the
| > narrowing. So the primary motivation is not strong - these numbers *would
| > be* constructible, albeit less conveniently.
It's not only about the construction of -0 imaginary parts. It's also
about preserving the result of a computation that generates a -0
imaginary part.
Understood. But why is that desirable? Can you demonstrate practical needs?
| > On the other hand, there are disadvantages:
| >
| > 1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary
| > parts.
We do a number of other things that are not completely compatible.
Yes. But I got the impression that you were amongst those who ranked Matlab compatibility quite high.
| > 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)).
| > 3. When numbers like x-0i are excluded from simplifying, you want real-only
| > mappers (erf, gamma etc) to still work on them. Currently that requires each
| > real-only mapper to have a complex wrapper counterpart. That's cumbersome
| > and easy to forget when new mappers are added.
| > 4. a' * a is not always real if a is a complex scalar. On the contrary, if
| > a is a complex vector, the result *is* always real, as computed by BLAS.
| > Should we try to fix BLAS?
I'm still not convinced that we should discard -0 when it appears as
the imaginary part of a complex number but not -0 when it appears as a
real number.
Why? Signed zero is not a mathematical concept; it's a feature of the IEEE 754 standard. I bet lots of Octave don't know anything about signed zeros. "discard zeros" is surely easier to understand and remember (and also to check) than "discard positive zeros". It's not like converting negative zeros to positive ones - it's about simplifying certain complex numbers to reals.
I think the real problem here is that we have no pure imaginary type.
Yes this has been talked about previously but the potential consistency advantages are still left to be narrowed down and it would surely complicate the existing implementation a lot.
Perhaps instead of changing the narrowing operation so that it always
drops -0 imaginary parts we should have the negation operation for
complex (0, y) generate complex (0, -y) instead of (-0, -y). If we
had a way of narrowing to pure imaginary, this is the result we would
get, isn't it?. Then at least we would not thow away zero imaginary
parts in all cases (for example, something like (1+i)/(-inf)). Or
would that cause more problems than it solves?
My suggestion is to avoid unnecessary special cases. There is no imaginary type in Octave, there probably never will be, it is neither in Matlab nor any other mathematical software I know of, so behaving "as if" there was one simply lacks sense IMHO.
What I suggest is to revert back to the plain stupid: let's do the complex operation as nature (C++/BLAS) intended them to work, and let's automatically simplify purely real complex numbers to true reals. Admittedly, it doesn't work that well if you think about the reals as just an economized special case of complex, but it works best in practice.
This strategy also requires the least special casing throughout the code, which I think is a desirable goal if you want to keep the Octave project attractive for future contributors.