Date: Fri, 11 Jul 2003 16:37:18 -0400
Reply-To: "Wainwright, Andrea" <andrea.wainwright@CAPITALONE.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Wainwright, Andrea" <andrea.wainwright@CAPITALONE.COM>
Subject: Re: $CHARw. format is identical to the $w. format
Content-Type: text/plain
And, as we recently discovered, if you do $char. It will default to the
length of the variable, which in our case was 8, and not the 1 byte that we
wanted :(
I spent many hours trying to find out what changed in the code, only to find
out it was the layout.
-----Original Message-----
From: Paul Dorfman [mailto:paul_dorfman@HOTMAIL.COM]
Sent: Friday, July 11, 2003 12:33 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: $CHARw. format is identical to the $w. format
Mike,
That $w. informat is different from $w. format in what it does has long been
a common knowledge. But it has also been quite a common place (if not
somewhat both logical and surprising) that the brightest and most
experienced SAS gurus like youself sometimes get caught by this sort of
s..tuff, I guess Ian being the only known exception. Perhaps the SAS
rational behind the difference is that the character informat interprets the
input byte stream according to a set of rules, actually much more involved
that just trimming the leading blanks, e.g.:
"The $w. informat trims leading blanks and left aligns the values before
storing the text. In addition, if a field contains only blanks and a single
period, $w. converts the period to a blank because it interprets the period
as a missing value. The $w. informat treats two or more periods in a field
as character data."
Heck, one has to beware what is hidden behind the apparently simplistic $w.
In contrast, $w. format interprets nothing at all. It, just like $char.,
simply tells SAS "show as is".
Kind regards,
================
Paul M. Dorfman
Jacksonville, FL
================
>From: Mike Rhoads <RHOADSM1@WESTAT.COM>
>Reply-To: Mike Rhoads <RHOADSM1@WESTAT.COM>
>To: SAS-L@LISTSERV.UGA.EDU
>Subject: $CHARw. format is identical to the $w. format
>Date: Thu, 10 Jul 2003 16:06:53 -0400
>
>In a response earlier today to a question from Debbie Cooper, I
>(correctly) advised her to use $CHAR. rather than the $ informat in an
>INPUT statement so that she would not lose leading blanks in her data.
>
>I should have stopped there, but then "helpfully" added the following:
>"Note that the same is true on output -- $ drops leading blanks. If
>you want to keep your carefully-retained blanks in any raw output file
>you are creating, use $CHAR4630. rather than $4630. in your PUT
>statement as well."
>
>My colleague Randy Herbison very politely informed me that this is NOT
>CORRECT -- when used as formats, neither $CHARw. nor $w. trims leading
>blanks on output. (When list output is used, of course, both leading
>and trailing blanks are trimmed.) This can be verified fairly quickly,
>in any currently available version of SAS, and the subject line of this
>message was in fact copied verbatim from the SAS v8 documentation.
>
>So, maybe it's not the most logical thing in the world for trimming to
>differentiate this pair when used as informats but not when used as
>formats, but that's the way it is. Thanks to Randy for bringing this
>to my attention. Perhaps I'm the only person suffering from this
>misconception (but somehow I doubt it).
>
>(Repeat after me: "Different as informats, identical as formats ...")
>
>Mike Rhoads
>Westat
>RhoadsM1@Westat.com
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
|