LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (March 2003, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Wed, 12 Mar 2003 23:02:48 -0500
Reply-To:   Jonathan Siegel <jmsiegel@YAHOO.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   Jonathan Siegel <jmsiegel@YAHOO.COM>
Subject:   Re: Function
Comments:   To: Sigurd Hermansen <HERMANS1@WESTAT.COM>

I think you've hit on something which explains why it used to be useful, and I agree also bolsters your case about it not being useful anymore.

I believe in the first days of SAS/PC (we're talking V6 through V6.04), the allowable length of a number was shorter on the PC than it was on the mainframe. If you used an explicit input statement, you might get an error if your application was ported to PC (or be overly restrictive if it was ported to mainframe.) So the implicit input was safer if your application might be ported -- it let you use the system limit, whatever that might happen to be.

But from what you say it sounds like on some operating systems, SAS never bothered to update the length limits when using the implicit input function. (Maybe they wanted to maintain backward compatibility to the 8086 ;)

Jonathan Siegel

On Wed, 12 Mar 2003 11:25:03 -0500, Sigurd Hermansen <HERMANS1@WESTAT.COM> wrote:

>It occurs to me that at least some of the SAS limits on lengths and formats >serve as pragmatic guidelines. Even if the implicit conversion works and the >explicit conversion does not in the artificial case given, I don't think a >programmer would have good reason to push the data step compiler beyond the >limit of an INPUT function. This version of your test program shows that >under Windows '9X SAS the implicit conversion comes to naught past fifteen >decimal places: > > data _null_; > _name_ = repeat('x',14) || '2.' || repeat('0',14) || repeat('9',10) || >'e1'; > put _name_=; > dsnum = substr(_name_, 16)*1 ; > put '(Implicit Conversion) ' dsnum= 32.31; > dsnum = input(substr(_name_, 16),32.); > put '(Explicit Conversion) ' dsnum= 32.31; > run; > >Nonetheless, were I developing a function, I'd want you to test it! >Sig > >-----Original Message----- >From: Howard_Schreier@ITA.DOC.GOV [mailto:Howard_Schreier@ITA.DOC.GOV] >Sent: Wednesday, March 05, 2003 11:09 AM >To: SAS-L@LISTSERV.UGA.EDU >Subject: Re: Function > > >As Roger suggests, some people disapprove of such implicit conversions. >What is usually recommended is an expression using the INPUT function. In >this case, something like > > dsnum = input(substr(_name_, 16) ,32.); > >[Remainder of posting is arcane.] > >There are strange cases where only the implicit method will work. Try this: > > data _null_; > _name_ = repeat('x',14) || '2.' || repeat('0',29) || 'e1'; > put _name_=; > dsnum = substr(_name_, 16)*1 ; > put '(Implicit Conversion) ' dsnum=; > dsnum = input(substr(_name_, 16) ,32.); > put '(Explicit Conversion) ' dsnum=; > run; > >The log shows: > > _name_=xxxxxxxxxxxxxxx2.000000000000000000000000000000e1 > (Implicit Conversion) dsnum=20 > (Explicit Conversion) dsnum=2 > >The value is 2 times 10 raised to the first power, or 20. But the extra >zeroes in the string push the "e1" beyond the maximum 32-byte width of the >informat, so it is ignored. The implicit conversion apparently works around >the informat limitation. > >Experimentation suggests that (with v. 8.2) the implicit conversion method >will process a field of up to 389 bytes. To see this, change the 29 to 385. >A missing value results, because the "e" is processed, but not the "1" >which follows it. > >On Mon, 3 Mar 2003 21:38:59 GMT, Roger Lustig <trovato@BELLATLANTIC.NET> >wrote: > >>Sam: >>What you have here is a quick-and-dirty type change. The SUBSTR >>function naturally returns a character string. Presumably the variable >>DSNUM has not yet been defined; otherwise, the statement would either be >>unnecessary or would produce an error message. >> >>By multiplying the character string by the multiplicative constant, you >>force SAS to turn the string into a numeric value first. >> >>Adding zero (instead of multiplying by one) does the same thing, and >>probably takes fewer CPU cycles. Which doesn't matter unless you're an >>old fogey like me, who had to program on steam-driven computers... >> >>...but fogies of my stripe also don't like those implicit type changes, >>not least because they leave a message in the log. >> >>Roger >> >>Sam wrote: >>> dsnum=substr(_name_, 16)*1; >>> >>> what does *1 do in the above statement please explain.

Back to: Top of message | Previous page | Main SAS-L page