HP3000-L Archives

June 1997, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Tue, 17 Jun 1997 07:10:16 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (95 lines)
At 12:34 AM 6/17/97 -0500, Michael Anderson wrote:
>I'v been working with HP COBOL for about 9 years and am aware of the
>"000}" negative zero that goes along with Signed ASCII numerics. However
>try telling a UNIX/C++ person what a negative zero is, AHhhh! He'll tell
>ya that a zero is a zero is a zero, and when it's put that way it's hard
>to call it anything else :-) It would be nice if someone could give me
>some insight or a valid reason for using a negative zero instead of a
>positive zero.

Indeed in number theory there is no such thing as a negative zero.
However, in process control applications I've seen the binary representation
of negative zero (zero value with sign-bit on) in real-type fields used to
denote 'missing value'.  This is especially useful when a specific value
cannot be used to indicate missing data because the value itself could be
valid data under certain conditions.

However, comparison logic in computers/languages generally treats -0 the
same as +0, and as such, one cannot test for -0 by:

       IF (value = -0.0)....

Instead one has to either examine the bits or initialize another variable
with -0 and then compare the separate variables:

        REAL value, missing;
        LOGICAL l'missing(*) = missing;

        l'missing'zero(0) = %100000;
        l'missing'zero(1) = %0;
        if (value = missing'zero) .....

This is possible because within the definition of a real number, this is
not a valid bit pattern.  If I recall, the value zero in real format is
something like:

        l'missing'zero(0) = %040000;
        l'missing'zero(1) = %0;

They were 24-bit reals on a Honeywell 4500...

Unfortunately this is limited to REAL-type data fields, and may also be
language-dependent.  The same 'trick' is not possible with integer
variables. The sign bit (bit 0) on and all other bits off represents
the number -32768 in half-word integer format, which is a legal integer
value...

Here's a simple illustration in FORTRAN:

FORTRAN *

PAGE 0001   HP32102B.01.12  (C) HEWLETT-PACKARD CO. 1986


00001000         REAL Missing, Value
00002000         LOGICAL LMissing(2), LValue(2)
00003000         EQUIVALENCE (Missing, LMissing), (Value, LValue)
00004000         DATA LMissing /%100000L, %0L/
00005000         Value = -0
00006000         IF (Missing .eq. -0) WRITE (6,1) "1:True", LMissing, Missing
00007000         IF (Missing .ne. -0) WRITE (6,1) "1:False", LMissing, Missing
00008000         IF (Missing .eq. Value) WRITE (6,1) "2:True", LMissing,
Value,
00009000       *                                     LVALUE
00010000         IF (Missing .ne. Value) WRITE (6,1) "2:False", LMissing,
Value,
00011000       *                                     LVALUE
00012000         LValue(1) = %100000L
00013000         IF (Missing .eq. Value) WRITE (6,1) "3:True", LMissing,
Value,
00014000       *                                     LVALUE
00015000         IF (Missing .ne. Value) WRITE (6,1) "3:False", LMissing,
Value,
00016000       *                                     LVALUE
00017000  1      FORMAT (1X,S,1x,O6,"/",O6, "=", F8.3,": ", O6,"/",O6)
00018000         STOP
00019000         END

PROGRAM UNIT MAIN' COMPILED

****      GLOBAL STATISTICS      ****
****   NO ERRORS,   NO WARNINGS  ****
TOTAL COMPILATION TIME  0:00:01
TOTAL ELAPSED TIME      0:00:01
TOTAL SYMBOL TABLE USED   %  07
/DO PREPRUN
PREPRUN $OLDPASS

1:False 100000/000000=   -.000:
2:False 100000/000000=    .000: 000000/000000
3:True 100000/000000=   -.000: 100000/000000



/jf

ATOM RSS1 RSS2