|
From: | Daniel J Sebald |
Subject: | Re: imag () function detail regarding -0.0000 |
Date: | Tue, 11 Sep 2012 20:49:20 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/11/2012 08:26 PM, Max Brister wrote:
On Tue, Sep 11, 2012 at 7:21 PM, Michael D Godfrey <address@hidden> wrote:On 09/11/2012 08:53 PM, Daniel J Sebald wrote: On 09/11/2012 07:15 PM, Jordi Gutiérrez Hermoso wrote: On 11 September 2012 20:00, Daniel J Sebald<address@hidden> wrote: octave:59> [1,-1,-0]'*i ans = 0 + 1i -0 - 1i -0 - 0i Is this proper behavior? I would think There is no actual "i" in Octave. Instead, "i" is a function that returns the equivalent of std::complex<double>(0.0, 1.0). You can see this behaviour in other ways, e.g. inf*i giving NaNs. Matlab says: ans = 0 + 1.0000i 0 - 1.0000i 0 For once, I go with Matlab. -0 implies (as in ones-complement) there are 2 representations of 0. But, there are not in nearly all modern (twos-complement) machines.IEEE 745 does have a signed zero. [1]Whatever causes -0 to be displayed should be fixed.Yes, I don't think the negative sign conveys any extra information to the user. [1] http://en.wikipedia.org/wiki/Floating_point#Signed_zero
Well, not in this case, no, unless one wants to think of rounding to zero from the negative direction. But I prefer the single additive identity rule of a field in the case of computations.
I would think the CPU naturally doesn't use -0 for multiplies if it is following some standard, unless there is some configuration (compile option?) saying to maintain sign through multiplication by zero. I'm guessing Octave is implementing the rule.
There are times when -0 makes sense: limits, branch cuts, some trig functions, etc. So there may be application of -0. Which complicates matters because then it is no longer a display issue.
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |