Re: imag () function detail regarding -0.0000

[Daniel J Sebald]

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