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.