octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unary mapper system redesigned + a few questions


From: Jaroslav Hajek
Subject: Re: unary mapper system redesigned + a few questions
Date: Fri, 13 Nov 2009 12:46:28 +0100



On Fri, Nov 13, 2009 at 7:27 AM, Jaroslav Hajek <address@hidden> wrote:


On Thu, Nov 12, 2009 at 10:20 PM, John W. Eaton <address@hidden> wrote:
On 12-Nov-2009, Jaroslav Hajek wrote:

| Sorry, but what is that good for? I still don't get the point. I don't think
| Matlab supports this, does it? So what is the motivation? Why does Octave
| distinguish signed and unsigned zeros?

IEEE 754?  We've discussed this before:

 http://old.nabble.com/Negative-zeros--to844605.html#a845854

jwe

Thanks for the pointer. This thread mainly discusses the existence of signed zero which I'm OK with. It's also fine that Octave prints negative zeros. But why are complex numbers with negative zero parts excluded from automatic narrowing?

I found this message: "I don't see a quick fix for these problems, but the following patch
does allow you to write

  0*(-i)

to produce (0, -0).

jwe
<patch follows>"

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.

On the other hand, there are disadvantages:

1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary parts.
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?

The advantages, for recap:

1. Numbers with negative zero imaginary parts, should they be needed for consistency, can be constructed like x + 0*(-i). However, even without the discussed behaviour, these numbers could be constructed using complex (), so this is pretty weak.
2. more?

Unless there are more advantages that I just don't see, it seems to me that the losses far outweigh the benefits. So I vote for a change. The overall impact is probably minor and won't affect most existing computations, because the issues being dealt with are quite subtle anyway.

comments?


Attached is a proposed changeset. This eliminates the remaining test failures and gives:

octave:1> i*i
ans = -1
octave:2> -i*i
ans =  1
octave:3> 0*(-i)
ans = -0
octave:4> complex (0, -0)
ans =  0 - 0i
octave:5> a = complex (1, -0); a'*a
ans =  1

regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Attachment: complex.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]