Date:         Wed, 25 Feb 2004 08:19:58 -0500
Reply-To:     "Fehd, Ronald J. (PHPPO)" <rjf2@CDC.GOV>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Fehd, Ronald J. (PHPPO)" <rjf2@CDC.GOV>
Subject:      Re: Floating point storage of missing values
Content-Type: text/plain; charset="us-ascii"

Dennis's comment:
"to use only floating point numbers as variables"
i.e. real numbers
prompts me to ask:
Has anyone done any testing of the SAS set of missing values
-- . ._ .A--.Z --
in numeric variables whose length is less than 8 bytes?

Ron Fehd  the macro maven  CDC Atlanta GA USA RJF2@cdc.gov
Efficiency is intelligent laziness. -David Dunham

> -----Original Message-----
> From: Dennis Diskin [mailto:diskin.dennis@KENDLE.COM]
> Sent: Wednesday, February 25, 2004 7:38 AM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Floating point storage of missing values
>
>
> Mike,
>
> You've already had a lot of good responses regarding actual
> order of the missing values. I just thought I'd point out
> that the binary represnetation will depend on your hardware.
> SAS's imlpementation of missing is tied in to their decision
> to use only floating point numbers as variables. Though it
> varies in implementation, a floating point number is stored
> as a characteristc and a mantissa (exponent and base). On the
> hardware I am familiar with, the mantissa porition is
> normalized (ie. left
> justified) and zeros are stored as all zero bits. If you
> create a binary representation which does not fall into the
> normalized representation, it is not a valid floating point
> number. When you try to floating point arithmetic on one of
> these, the hardware generates an interrupt which can be
> trapped and handled as you wish. This is where the overhead
> comes in. Just testing for order probably does not generate
> the interrupt since it is usually done on a binary basis.