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: Tue, 17 Nov 2009 21:23:56 +0100



On Tue, Nov 17, 2009 at 9:04 PM, John W. Eaton <address@hidden> wrote:
On 17-Nov-2009, Jaroslav Hajek wrote:

| > If you preserve the -0 for real values, then I think you should also
| > preserve them for imaginary values.
| >
| >
| This is the "why?" I think you still haven't answered. If we do the
| auto-narrowing, why do we do it only for positive zeros? Dropping both would
| actually be more symmetric than the current behavior.

Try this:

 x = logspace (300, 309, 10)'
 y = complex (0, -1) ./ x
 z = log (y)

What happens?  What should happen?  I see a jump in the last value
when I think the result should be continuous.  Shouldn't the imaginary
part always be -pi/2?


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. An implementation is not required to distinguish the sign of zero, probably for practical reasons: it's more difficult to implement (requires the signbit check) and it's also usually more difficult to use - in  most computations, users don't distinguish signed zeros either, so this would simply mean that the sign of imag(log(x)) is random.
 
I think the result I'm seeing is a bug in the Complex log function.
It should be using the information provided by the negative zero
imaginary part.


According to the C++ standard, apparently not. It's certainly not Octave's bug.
 
If you throw away the negative zero imaginary part before it even gets
to the log function, then there is no way to fix this problem.

Surely there is; just do

y = complex (0, -1 ./ x)

instead. "complex" skips the narrowing.

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

reply via email to

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