Re: unary mapper system redesigned + a few questions

[John W. Eaton]

On 17-Nov-2009, Jaroslav Hajek wrote:

| > 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?

I think 1/(-0) should result in -Inf, not Inf.

Hey, that's even Matlab compatible (:-), so it seems that Matlab does
store the sign of zero even if it doesn't display it.

If you preserve the -0 for real values, then I think you should also
preserve them for imaginary values.

| > 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.

Lot's of Octave users don't know much about floating point numbers
generally.

| 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.

I don't really expect to be able to implement a pure imaginary type
without some support from the implementation language (C++).

| My suggestion is to avoid unnecessary special cases.

Narrowing is already a special case.

| 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.

C++ does not do that.  There is no automatic conversion from complex
to real.

jwe