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: Schirmacher, Rolf
Subject: RE: unary mapper system redesigned + a few questions
Date: Tue, 17 Nov 2009 21:20:56 +0100

John,

I highly appreciate your intention and reasoning, but I think for most users
the astonishment about not narrowing at -0i while doing so for +0i is much
greater than this Inf - inconsistency. 

I think that the appropriate software for getting infinite limits right
might be some CAS like maxima, not a numerical system like octave. So we
should try to get these cases as right as possible in octave, but focus more
on the practical numerical usage. And for the latter, I think narrowing both
imag zeros is preferable.

Just my 2 ct,

Rolf

> -----Original Message-----
> From: John W. Eaton [mailto:address@hidden
> Sent: Tuesday, November 17, 2009 9:05 PM
> To: Jaroslav Hajek
> Cc: octave maintainers list
> Subject: Re: unary mapper system redesigned + a few questions
> 
> 
> 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?
> 
> 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.
> 
> 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.
> 
> jwe
> 


reply via email to

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