Thread Subject: How to get Matlab receive and print "-0" and "+0"

I'm writing a GUI which plots a few data sets. User is required to input values at the begining which will be included in the title of the plots at the end. These values are both negative and positive numbers. Due to the nature of the data sets, I want Matlab to receive values like "+0" and "-0" but I couldn't figure out how.
Any help will be appreciated!!!

Thanks,

MATLAB doesn't accept values like -0 and +0, because they are numerically
identical in floating point format. The closest you could come is to have
the user input "0 - eps" and "0 + eps". To have this display back to the
prompt as "a slightly positive number" and "a slightly negative number", you
can force the format to be "bank" as an example:

>> format bank
>> 0+eps

ans =

          0.00

>> 0-eps

ans =

         -0.00

You might have to pigeonhole this concept into your application. For
instance, read the data in from the textbox using a callback, and parse the
text.

* If the text is "-0", then forward on to the algorithm, the value "0-eps".
* If the text is "+0", then forward on to the algorithm, the value "0+eps".
* Otherwise, forward the value as is.

Hope this helps.

"Aviator " <carl_agahi@yahoo.com> wrote in message
news:gu9rnf$80p$1@fred.mathworks.com...
> I'm writing a GUI which plots a few data sets. User is required to input
> values at the begining which will be included in the title of the plots at
> the end. These values are both negative and positive numbers. Due to the
> nature of the data sets, I want Matlab to receive values like "+0" and
> "-0" but I couldn't figure out how.
> Any help will be appreciated!!!
>
> Thanks,

"Aviator " <carl_agahi@yahoo.com> wrote in message <gu9rnf$80p$1@fred.mathworks.com>...
> I'm writing a GUI which plots a few data sets. User is required to input values at the begining which will be included in the title of the plots at the end. These values are both negative and positive numbers. Due to the nature of the data sets, I want Matlab to receive values like "+0" and "-0" but I couldn't figure out how.
> Any help will be appreciated!!!
>
> Thanks,

% I'm not sure what you mean by " receive values" but maybe

doc sprintf

% and look at the "Flags" section for printing minus and plus signs.

"Manu Raghavan" <manu.raghavan@mathworks.com> wrote in message <gu9ubo$4fi$1@fred.mathworks.com>...
> MATLAB doesn't accept values like -0 and +0, because they are numerically
> identical in floating point format.

As per section 6.3 of ANSI/IEEE Std. 754-1985, MATLAB honors the sign bit "even when operands or results are zero or infinite."

So, for example...

>> pzero = 0;
>> nzero = -0;
>> 1/pzero

ans =

   Inf

>> 1/nzero

ans =

  -Inf

However, it can be VERY difficult to distinguish between a positive and negative zero. For example, positive zero is equal to negative zero:

>> nzero == pzero

ans =

     1

and both sign(pzero) and sign(nzero) return a positive zero.

When I *really* need to distinguish between the two, I rely on the Inf vs. -Inf behavior shown above. For example,

>> sign(1/pzero)

ans =

     1

>> sign(1/nzero)

ans =

    -1

allows me to distinguish between the two.
--
Bob Gilmore, The MathWorks, Inc.

Robert Gilmore wrote:
...
> As per section 6.3 of ANSI/IEEE Std. 754-1985, MATLAB honors the sign
> bit "even when operands or results are zero or infinite."
...
If

sprintf('%+d', nz)

doesn't output the (-)ive sign, I'd think that a bug.

I've not had much need for it in ages, and don't know the details of 754
well enough otomh on whether it even addresses external representation
or not, but that would be my expectation certainly.

Showing my age, the CDC FORTRAN compilers did indicated +/- zero
routinely and it took effort to hide them... :)

--

"Robert Gilmore" <BobDOTGilmore@mathworks.com> wrote in message <gua4vl$47q$1@fred.mathworks.com>...
> "Manu Raghavan" <manu.raghavan@mathworks.com> wrote in message <gu9ubo$4fi$1@fred.mathworks.com>...
> > MATLAB doesn't accept values like -0 and +0, because they are numerically
> > identical in floating point format.
>
> As per section 6.3 of ANSI/IEEE Std. 754-1985, MATLAB honors the sign bit "even when operands or results are zero or infinite."
>
> So, for example...
>
> >> pzero = 0;
> >> nzero = -0;
> >> 1/pzero
>
> ans =
>
> Inf
>
> >> 1/nzero
>
> ans =
>
> -Inf
>
> However, it can be VERY difficult to distinguish between a positive and negative zero. For example, positive zero is equal to negative zero:
>
> >> nzero == pzero
>
> ans =
>
> 1
>
> and both sign(pzero) and sign(nzero) return a positive zero.
>
> When I *really* need to distinguish between the two, I rely on the Inf vs. -Inf behavior shown above. For example,
>
> >> sign(1/pzero)
>
> ans =
>
> 1
>
> >> sign(1/nzero)
>
> ans =
>
> -1
>
> allows me to distinguish between the two.
> --
> Bob Gilmore, The MathWorks, Inc.

Bob, doesn't it seem odd that 'sign(-0)' returns 0? Almost by definition, it seems like it should return -1.

Regards,
Eric

dpb <none@non.net> wrote in message <gua87c$tig$1@aioe.org>...
> Robert Gilmore wrote:
> ...
> > As per section 6.3 of ANSI/IEEE Std. 754-1985, MATLAB honors the sign
> > bit "even when operands or results are zero or infinite."
> ...
> If
>
> sprintf('%+d', nz)
>
> doesn't output the (-)ive sign, I'd think that a bug.
>
> I've not had much need for it in ages, and don't know the details of 754
> well enough otomh on whether it even addresses external representation
> or not, but that would be my expectation certainly.
>
> Showing my age, the CDC FORTRAN compilers did indicated +/- zero
> routinely and it took effort to hide them... :)
>

Yes, it would be nice for some consistency here. For example, all of the following will reproduce the - sign:

sprintf('%-f',nz)
sprintf('%-e',nz)
sprintf('%-E',nz)
sprintf('%-g',nz)
sprintf('%-G',nz)

but the %-d format will not. I too would consider this a bug.

Another annoying inconsistency (at least to me) is that the num2hex function can't be trusted to show you the underlying bit pattern. e.g.,

>> num2hex(nz)
ans =
0000000000000000
>> typecast(nz,'int64')
ans =
 -9223372036854775808

Obviously, the underlying bit pattern has a non-zero bit as seen by the typecast result, but you wouldn't know it just by looking at the num2hex result. I would consider this a bug also.

Speaking of Fortran, I still use some relatively current compilers that claim to be IEEE compliant yet do not honor the sign bit when printing a signed zero, in violation of the IEEE standard. The Fortran Standard does not require that the sign bit of -0 be honored, but it *does* state that if an implementation does honor it (e.g. claim to be IEEE compilant) then they must print it out when requested and honor it in the intrinsic SIGN function, etc.

James Tursa

James Tursa wrote:
...
> Yes, it would be nice for some consistency here. For example, all of
> the following will reproduce the - sign:
>
> sprintf('%-f',nz)
 > sprintf('%-e',nz)
 > sprintf('%-E',nz)
> sprintf('%-g',nz)
 > sprintf('%-G',nz)
>
> but the %-d format will not. I too would consider this a bug.
...
The "-" shouldn't force the sign, though; it's purpose is to left-adjust
the field iir the C formatting rules.

It's the "+" modifier that is supposed to cause the leading +/- sign to
be output irregardless.

If ML outputs -0.000 for

  sprintf('%-f',nz)

that's a change in behavior since the version (R12) I have wherein it
doesn't. I just used d since it looked like that was what the OP in the
thread would probably have wanted.

--

"Robert Gilmore" <BobDOTGilmore@mathworks.com> wrote in message <gua4vl$47q$1@fred.mathworks.com>...
> "Manu Raghavan" <manu.raghavan@mathworks.com> wrote in message <gu9ubo$4fi$1@fred.mathworks.com>...
> > MATLAB doesn't accept values like -0 and +0, because they are numerically
> > identical in floating point format.
>
> As per section 6.3 of ANSI/IEEE Std. 754-1985, MATLAB honors the sign bit "even when operands or results are zero or infinite."
>
> So, for example...
>
> >> pzero = 0;
> >> nzero = -0;
> >> 1/pzero
>
> ans =
>
> Inf
>
> >> 1/nzero
>
> ans =
>
> -Inf
>
> However, it can be VERY difficult to distinguish between a positive and negative zero. For example, positive zero is equal to negative zero:
>
> >> nzero == pzero
>
> ans =
>
> 1
>
> and both sign(pzero) and sign(nzero) return a positive zero.
>
> When I *really* need to distinguish between the two, I rely on the Inf vs. -Inf behavior shown above. For example,
>
> >> sign(1/pzero)
>
> ans =
>
> 1
>
> >> sign(1/nzero)
>
> ans =
>
> -1
>
> allows me to distinguish between the two.
> --
> Bob Gilmore, The MathWorks, Inc.

And a related problem is how to detect the sign of a NaN. The above trick for -0 will not work with NaN values, but a typecast trick will. E.g.,

>> n = NaN
n =
   NaN
>> sign(n)
ans =
   NaN
>> typecast(n,'int64')<0
ans =
     1
>> typecast(-n,'int64')<0
ans =
     0

James Tursa
 

dpb <none@non.net> wrote in message <guac2v$3bi$1@aioe.org>...
> James Tursa wrote:
> ...
> > Yes, it would be nice for some consistency here. For example, all of
> > the following will reproduce the - sign:
> >
> > sprintf('%-f',nz)
> > sprintf('%-e',nz)
> > sprintf('%-E',nz)
> > sprintf('%-g',nz)
> > sprintf('%-G',nz)
> >
> > but the %-d format will not. I too would consider this a bug.
> ...
> The "-" shouldn't force the sign, though; it's purpose is to left-adjust
> the field iir the C formatting rules.

 Ah, yes. My bad. The above examples should have had + instead of - as you point out.

James Tursa

"Eric " <foo@bar.com> wrote in message
news:guaae1$3r$1@fred.mathworks.com...

*snip*

> Bob, doesn't it seem odd that 'sign(-0)' returns 0? Almost by definition,
> it seems like it should return -1.

No, by the definition:

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/sign.html

it should return 0. If we made sign(-0) return -1 then for consistency we
would need to make sign(0) return 1, and that would be a significant
backwards incompatibility (since sign(0) in MATLAB has returned 0 for as
long as I can remember.)

--
Steve Lord
slord@mathworks.com

James Tursa wrote:
...
> Ah, yes. My bad. The above examples should have had + instead of - as you point out.

Do they now display the minus w/ later/latest versions of ML? I'm stuck
at R12 which doesn't so can't test here...

--

Funny,

format hex

shows the difference.

dpb <none@non.net> wrote in message <guc1fn$m8l$1@aioe.org>...
> James Tursa wrote:
> ...
> > Ah, yes. My bad. The above examples should have had + instead of - as you point out.
>
> Do they now display the minus w/ later/latest versions of ML? I'm stuck
> at R12 which doesn't so can't test here...
>
> --

R2007a and R2008b both display the sign of -0 when using the %-g, %-f, %-e format. I don't have any earlier versions to test at the moment, so don't know if this behavior has been different in the past.

James Tursa

"Matt Fig" <spamanon@yahoo.com> wrote in message <guc3nq$6j6$1@fred.mathworks.com>...
> Funny,
>
> format hex
>
> shows the difference.

Yes, and that inconsistency is quite annoying to me. Why should format hex show something different from num2hex? I consider the num2hex function unreliable and the fact that it doesn't show the actual underlying bit pattern a MATLAB bug. format hex does seem to be reliable.

For example, you can see the same problem with NaN:

>> format hex
>> NaN
ans =
   fff8000000000000
>> num2hex(NaN)
ans =
fff8000000000000
>> -NaN
ans =
   7ff8000000000000
>> num2hex(-NaN)
ans =
fff8000000000000

James Tursa

"James Tursa"
> format hex does seem to be reliable...

not quite

     v=[
          nan inf
          -nan inf
          nan/nan inf/inf
          -nan/nan -inf/inf
          nan/-nan inf/-inf
          -nan/-nan -inf/-inf
     ];
     format hex
     v
%{
% v =
% NAN INF
    fff8000000000000 7ff0000000000000
    7ff8000000000000 7ff0000000000000
    fff8000000000000 fff8000000000000
    7ff8000000000000 fff8000000000000
    7ff8000000000000 fff8000000000000
    7ff8000000000000 fff8000000000000 % <- ?
%}

just a thought...
us

"us " <us@neurol.unizh.ch> wrote in message <gucdvu$b63$1@fred.mathworks.com>...
> "James Tursa"
> > format hex does seem to be reliable...
>
> not quite
>
> v=[
> nan inf
> -nan inf
> nan/nan inf/inf
> -nan/nan -inf/inf
> nan/-nan inf/-inf
> -nan/-nan -inf/-inf
> ];
> format hex
> v
> %{
> % v =
> % NAN INF
> fff8000000000000 7ff0000000000000
> 7ff8000000000000 7ff0000000000000
> fff8000000000000 fff8000000000000
> 7ff8000000000000 fff8000000000000
> 7ff8000000000000 fff8000000000000
> 7ff8000000000000 fff8000000000000 % <- ?
> %}
>
> just a thought...
> us

I believe that you're not "supposed to be" paying attention to the sign bit of an NaN result. If you are, you're probably going to be disappointed at some point, as Urs is. For example, go back to section 6.3 of the spec, which states "The standard does not interpret the sign of an NaN." It then goes on to discuss the signs of products or quotients. The paragraph concludes with "These rules shall apply even when operands are zero or infinite." NaN is conspicuous in its absence from the last sentence.

More informally, the specification is shot through with references to +0, -0, +Inf, -Inf, +-0, and +-Inf. I can't find any reference to "-NaN."
--
Bob Gilmore, The MathWorks, Inc.
(I work at The MathWorks, but I don't implement our floating point arithmetic. I simply have some prior experience with, and interest in, the topic. So don't worry if I'm incorrect or imprecise; I'm not in a position to break anything.)

"Robert Gilmore" <BobDOTGilmore@mathworks.com> wrote in message <guck8h$2hc$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <gucdvu$b63$1@fred.mathworks.com>...
> > "James Tursa"
> > > format hex does seem to be reliable...
> >
> > not quite
> >
> > v=[
> > nan inf
> > -nan inf
> > nan/nan inf/inf
> > -nan/nan -inf/inf
> > nan/-nan inf/-inf
> > -nan/-nan -inf/-inf
> > ];
> > format hex
> > v
> > %{
> > % v =
> > % NAN INF
> > fff8000000000000 7ff0000000000000
> > 7ff8000000000000 7ff0000000000000
> > fff8000000000000 fff8000000000000
> > 7ff8000000000000 fff8000000000000
> > 7ff8000000000000 fff8000000000000
> > 7ff8000000000000 fff8000000000000 % <- ?
> > %}
> >
> > just a thought...
> > us
>
> I believe that you're not "supposed to be" paying attention to the sign bit of an NaN result. If you are, you're probably going to be disappointed at some point, as Urs is. For example, go back to section 6.3 of the spec, which states "The standard does not interpret the sign of an NaN." It then goes on to discuss the signs of products or quotients. The paragraph concludes with "These rules shall apply even when operands are zero or infinite." NaN is conspicuous in its absence from the last sentence.
>
> More informally, the specification is shot through with references to +0, -0, +Inf, -Inf, +-0, and +-Inf. I can't find any reference to "-NaN."
> --
> Bob Gilmore, The MathWorks, Inc.
> (I work at The MathWorks, but I don't implement our floating point arithmetic. I simply have some prior experience with, and interest in, the topic. So don't worry if I'm incorrect or imprecise; I'm not in a position to break anything.)

If you do any operations with NaN, I don't think anyone should expect the bit patterns to be maintained. E.g., signaling NaNs may turn into non-signaling NaNs (most significant mantissa bit gets set), sign bits aren't guaranteed to follow floating point rules one would expect from "numbers", and so forth. So I think the example 'us' gives may not be appropriate in this context because it involves operations with NaNs (unary minus and division). Even something as simple as an assignment can change the bit pattern of a NaN ... e.g. see this thread:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/250161#646427

For the operation -NaN, in particular, I don't think anyone should expect that MATLAB *should* handle it by flipping the sign bit. That is an implementation detail not specified by the standard and MATLAB is free to do whatever it likes with the operation, as long as it results in some type of NaN. MATLAB has chosen to flip the sign bit, so that is fine. But I wouldn't depend on this behavior in my code.

That all being said, the MATLAB num2hex function still has a bug in my opinion. Even the MATLAB doc for num2hex states:

"The same representation is printed with format hex."

and my previous posts demonstrate that this is not true. Regardless of how the bit pattern was created (-0, -NaN, through a typecast operation, returned from a mex routine, etc.), if the bit pattern is there then num2hex should display it exactly.

James Tursa