Date: Tue, 2 Jun 2009 11:21:30 -0700
Reply-To: "Anderson, James" <James.Anderson@UCSF.EDU>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Anderson, James" <James.Anderson@UCSF.EDU>
Subject: Re: Where Should It Stop?
In-Reply-To: <b7a7fa630906021057v15a0b542q4f09598396033cc4@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Hi Joe,
I think you would get a net gain in I/O performance with variable length strings, because in most cases they would use less memory. But that 's not the motivation - I'm interested in simplifying programming.
| Hello| and |Hello | are different, whether you use fixed or variable length strings. I'm not sure what warning you want.
Java and C++ are strongly typed, and they have variable length strings.
Cheers,
Jim
From: Joe Matise [mailto:snoopy369@gmail.com]
Sent: Tuesday, June 02, 2009 10:58 AM
To: Anderson, James
Cc: SAS-L@listserv.uga.edu
Subject: Re: Where Should It Stop?
You lose a lot from that, though, in terms of optimization of i/o, and undoubtedly other elements. You already have the COMPRESS option [which, among other things, effectively makes a character variable of varying length, by compressing the blanks].
The complaint you have about the merge warning is entirely trivial, and any competent programmer knows how to deal with it in a few seconds. On the other hand, it is highly useful sometimes to have that warning, variable length string or no - because you sometimes actually have bad data, and this lets you know about it. Also, how do you merge the two strings:
| Hello|
|Hello |
? Are they the same? Are they different? I want to see a warning tell me about that, because they might very well be different in many instances. Or they might not be. A varying length string solution with no warning will simply assume they are different and end the story there... I don't think the space savings is worth the lack of IO optimization from not knowing how long a block of data is going to be ahead of time, though I'm not the IO expert (or anything close), so I'm glad to be proven wrong.
To me this sounds like a VB discussion of whether you should have strongly typed or weakly typed variables; and I absolutely always fall on the former side [strongly]. You might gain something from having flexible variable types, but the loss in readability and optimization absolutely kills that, and allows far too much sloppy programming. I think the same applies to character variables with non-defined lengths in SAS.
-Joe
On Tue, Jun 2, 2009 at 12:34 PM, Anderson, James <James.Anderson@ucsf.edu<mailto:James.Anderson@ucsf.edu>> wrote:
Chang,
The advantage of the variable length string is that it is more flexible -- the variable holds whatever value you put in it. Today it may be 10 characters, tomorrow 20. With variable length strings I write less code, I have to think less and I get my hand slapped less. Most popular languages today use variable length strings.
One recurring problem I have is merging 2 datasets where each is imported from excel. The lengths of the by variables is determined by the maximum lengths in each sheet, often different between sheets. SAS squawks at me. I can either do more work and stop the squawk or ignore the squawk. Big waste of time and focus.
Jim
-----Original Message-----
From: Chang Chung [mailto:chang_y_chung@HOTMAIL.COM<mailto:chang_y_chung@HOTMAIL.COM>]
Sent: Tuesday, June 02, 2009 10:16 AM
To: SAS-L@LISTSERV.UGA.EDU<mailto:SAS-L@LISTSERV.UGA.EDU>; Anderson, James
Subject: Re: Where Should It Stop?
On Tue, 2 Jun 2009 09:23:14 -0700, Anderson, James <James.Anderson@UCSF.EDU<mailto:James.Anderson@UCSF.EDU>>
wrote:
> Yes!
to this question by Ian:
>>> SAS character variables are a fixed length. This fact permeates the
>>> entire language. Should SI embark on rewriting the system to use
>>> variable length strings?
...
@Jim. Why? I have always thought that the main reason for using the variable
length string type is because it saves memory. but the storage and memory
are getting cheaper. If not this, then what's the reason(s) for using the
var len str type? chang
| 
