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: Wed, 18 Nov 2009 07:35:24 +0100



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

I don't see any practical way to do this for every computation which
might result in an underflow on the negative side of zero.


I seriously doubt you need this done for every computation. In fact I'm interested if you have any real-life script that starts producing wrong results after the discussed patch is applied.

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