SASware ballot #18 Proc Transpose preserving variable
in [SAS]
|
From: "Data _null_;" on 25 Jan 2010 17:13 Just having some fun. When the data are converted to character by the first transpose it will be impossible in some situations to get back to the original data. I believe you and Ted have discussed this already. That, is one reason I suggest that a PROC to read a data set CONTROL data set could be useful but PROC TRANSPOSE is not the proper tool. I use PROC TRANPOSE often but I rarely need to get back to the original data or some even modified version with the same structure. I guess I don't see why the data flip-flop is so useful to you or why you need it. Maybe if you showed some of the code you are using that requires macro or whatever I would understand better. On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > Oh come on Null... > > As mentioned in the message, the example program is merely an > overly-simplistic test case strictly intended to illustrate and exercise all > of the necessary features. Any real application would include additional > logic between the two transpose steps, or read the desired attributes values > from a "self-defining" external file. > > The real trick is for you to simulate the *second* transpose step with > comparably simple code of your own. For you to say that the proposed > TRANSPOSE enhancements are not needed, that is what you must be able to > accomplish. So, are you up to the challenge? > > ----- Original Message ----- From: "Data _null_;" <iebupdte(a)GMAIL.COM> > To: <SAS-L(a)LISTSERV.UGA.EDU> > Sent: Monday, January 25, 2010 15:12 > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > attributes > > > > > On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > > > > > proc transpose data=original out=skinny type length format informat > force > > > noformat; by obsno; > > > var _all_; run; > > > > > > proc transpose data=skinny out=final noinformat; by obsno; > > > id _NAME_; idlabel _LABEL_; idtype _TYPE_; idlength _LENGTH_; idformat > > > _FORMAT_; idinformat _INFORMAT_; > > > var col1; run; > > > > > > If you can manage to accomplish something similar with code that is > anywhere > > > remotely close to something this simple, then you win a (virtual) > cookie. > > > > > > > Seems obvious: data=original > > > > > > >
From: Ted Clay on 25 Jan 2010 17:36 Kevin, Did you mean to type "FORCE" on Proc Transpose? Did I miss a feature in your proposal? Ted -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Kevin Myers Sent: Monday, January 25, 2010 1:23 PM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: SASware ballot #18 Proc Transpose preserving variable attributes Oh come on Null... As mentioned in the message, the example program is merely an overly-simplistic test case strictly intended to illustrate and exercise all of the necessary features. Any real application would include additional logic between the two transpose steps, or read the desired attributes values from a "self-defining" external file. The real trick is for you to simulate the *second* transpose step with comparably simple code of your own. For you to say that the proposed TRANSPOSE enhancements are not needed, that is what you must be able to accomplish. So, are you up to the challenge? ----- Original Message ----- From: "Data _null_;" <iebupdte(a)GMAIL.COM> To: <SAS-L(a)LISTSERV.UGA.EDU> Sent: Monday, January 25, 2010 15:12 Subject: Re: SASware ballot #18 Proc Transpose preserving variable attributes > On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: >> proc transpose data=original out=skinny type length format informat force >> noformat; by obsno; >> var _all_; run; >> >> proc transpose data=skinny out=final noinformat; by obsno; >> id _NAME_; idlabel _LABEL_; idtype _TYPE_; idlength _LENGTH_; idformat >> _FORMAT_; idinformat _INFORMAT_; >> var col1; run; >> >> If you can manage to accomplish something similar with code that is >> anywhere >> remotely close to something this simple, then you win a (virtual) cookie. > > Seems obvious: data=original >
From: Ted Clay on 25 Jan 2010 20:03 Here is a test case trying to cause data loss when converting numeric to character to numeric: data _null_; x=1/3; xc=put(x,30.28); newx=input(xc,30.28); if x=newx then put 'Same'; else put 'Different'; put xc=; run; Different xc=0.3333333333333300000000000000 Is there a way to fiddle with this code to make "Same" come out? Is this character representation truly at the limit of resolution, comparable to how numbers are stored in SAS? Or is there more information "in there" that can be somehow coaxed out? I found that hard-coding an extra "3" in XC did nothing, but adding an extra "33" did the trick. To put this in perspective, a separate Proc Compare showed the difference was on the order of E-15. Ted -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Data _null_; Sent: Monday, January 25, 2010 2:13 PM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: SASware ballot #18 Proc Transpose preserving variable attributes Just having some fun. When the data are converted to character by the first transpose it will be impossible in some situations to get back to the original data. I believe you and Ted have discussed this already. That, is one reason I suggest that a PROC to read a data set CONTROL data set could be useful but PROC TRANSPOSE is not the proper tool. I use PROC TRANPOSE often but I rarely need to get back to the original data or some even modified version with the same structure. I guess I don't see why the data flip-flop is so useful to you or why you need it. Maybe if you showed some of the code you are using that requires macro or whatever I would understand better. On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > Oh come on Null... > > As mentioned in the message, the example program is merely an > overly-simplistic test case strictly intended to illustrate and exercise all > of the necessary features. Any real application would include additional > logic between the two transpose steps, or read the desired attributes values > from a "self-defining" external file. > > The real trick is for you to simulate the *second* transpose step with > comparably simple code of your own. For you to say that the proposed > TRANSPOSE enhancements are not needed, that is what you must be able to > accomplish. So, are you up to the challenge? > > ----- Original Message ----- From: "Data _null_;" <iebupdte(a)GMAIL.COM> > To: <SAS-L(a)LISTSERV.UGA.EDU> > Sent: Monday, January 25, 2010 15:12 > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > attributes > > > > > On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > > > > > proc transpose data=original out=skinny type length format informat > force > > > noformat; by obsno; > > > var _all_; run; > > > > > > proc transpose data=skinny out=final noinformat; by obsno; > > > id _NAME_; idlabel _LABEL_; idtype _TYPE_; idlength _LENGTH_; idformat > > > _FORMAT_; idinformat _INFORMAT_; > > > var col1; run; > > > > > > If you can manage to accomplish something similar with code that is > anywhere > > > remotely close to something this simple, then you win a (virtual) > cookie. > > > > > > > Seems obvious: data=original > > > > > > >
From: Kevin Myers on 25 Jan 2010 21:19 Yes, FORCE was a late addition not included in my original proposal, but necessary to make the proposed options and statements more useful. Using the FORCE option would force TRANSPOSE to create appropriate attribute variables even if no variable being transposed has a given attribute. For example, with the current implementation, a LABEL variable (e.g. _LABEL_) is only created if at least one of the variables being transposed actually has a label. This can adversely complicate subsequent steps that must add extra logic to alter processing depending upon whether or not the _LABEL_ variable exists. Using FORCE would eliminate the need for such logic by causing the LABEL variable to be created whether or not any of the variables being transposed actually have a label. In this case, the LABEL variable would have blank values for all observations. Make sense? s/KAM ----- Original Message ----- From: "Ted Clay" <tclay(a)ashlandhome.net> To: "'Kevin Myers'" <KevinMyers(a)AUSTIN.RR.COM>; <SAS-L(a)LISTSERV.UGA.EDU> Sent: Monday, January 25, 2010 16:36 Subject: RE: SASware ballot #18 Proc Transpose preserving variable attributes > Kevin, > Did you mean to type "FORCE" on Proc Transpose? Did I miss a feature in > your proposal? > Ted > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Kevin > Myers > Sent: Monday, January 25, 2010 1:23 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > attributes > > Oh come on Null... > > As mentioned in the message, the example program is merely an > overly-simplistic test case strictly intended to illustrate and exercise > all > of the necessary features. Any real application would include additional > logic between the two transpose steps, or read the desired attributes > values > from a "self-defining" external file. > > The real trick is for you to simulate the *second* transpose step with > comparably simple code of your own. For you to say that the proposed > TRANSPOSE enhancements are not needed, that is what you must be able to > accomplish. So, are you up to the challenge? > > ----- Original Message ----- > From: "Data _null_;" <iebupdte(a)GMAIL.COM> > To: <SAS-L(a)LISTSERV.UGA.EDU> > Sent: Monday, January 25, 2010 15:12 > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > attributes > > >> On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: >>> proc transpose data=original out=skinny type length format informat >>> force >>> noformat; by obsno; >>> var _all_; run; >>> >>> proc transpose data=skinny out=final noinformat; by obsno; >>> id _NAME_; idlabel _LABEL_; idtype _TYPE_; idlength _LENGTH_; idformat >>> _FORMAT_; idinformat _INFORMAT_; >>> var col1; run; >>> >>> If you can manage to accomplish something similar with code that is >>> anywhere >>> remotely close to something this simple, then you win a (virtual) >>> cookie. >> >> Seems obvious: data=original >> > > >
From: "Data _null_;" on 25 Jan 2010 21:38
HEX16. 105 data _null_; 5106 x=1/3; 5107 xc=put(x,hex16.); 5108 newx=input(xc,hex16.); 5109 if x=newx then put 'Same'; 5110 else put 'Different'; 5111 put xc=; 5112 run; Same xc=3FD5555555555555 On 1/25/10, Ted Clay <tclay(a)ashlandhome.net> wrote: > Here is a test case trying to cause data loss when converting numeric to > character to numeric: > > data _null_; > x=1/3; > xc=put(x,30.28); > newx=input(xc,30.28); > if x=newx then put 'Same'; > else put 'Different'; > put xc=; > run; > > Different > xc=0.3333333333333300000000000000 > > Is there a way to fiddle with this code to make "Same" come out? Is this > character representation truly at the limit of resolution, comparable to how > numbers are stored in SAS? Or is there more information "in there" that can > be somehow coaxed out? I found that hard-coding an extra "3" in XC did > nothing, but adding an extra "33" did the trick. > > To put this in perspective, a separate Proc Compare showed the difference > was on the order of E-15. > > Ted > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Data > _null_; > Sent: Monday, January 25, 2010 2:13 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > attributes > > Just having some fun. > > When the data are converted to character by the first transpose it > will be impossible in some situations to get back to the original > data. I believe you and Ted have discussed this already. > > That, is one reason I suggest that a PROC to read a data set CONTROL > data set could be useful but PROC TRANSPOSE is not the proper tool. > > I use PROC TRANPOSE often but I rarely need to get back to the > original data or some even modified version with the same structure. > > I guess I don't see why the data flip-flop is so useful to you or why > you need it. Maybe if you showed some of the code you are using that > requires macro or whatever I would understand better. > > > On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > > Oh come on Null... > > > > As mentioned in the message, the example program is merely an > > overly-simplistic test case strictly intended to illustrate and exercise > all > > of the necessary features. Any real application would include additional > > logic between the two transpose steps, or read the desired attributes > values > > from a "self-defining" external file. > > > > The real trick is for you to simulate the *second* transpose step with > > comparably simple code of your own. For you to say that the proposed > > TRANSPOSE enhancements are not needed, that is what you must be able to > > accomplish. So, are you up to the challenge? > > > > ----- Original Message ----- From: "Data _null_;" <iebupdte(a)GMAIL.COM> > > To: <SAS-L(a)LISTSERV.UGA.EDU> > > Sent: Monday, January 25, 2010 15:12 > > Subject: Re: SASware ballot #18 Proc Transpose preserving variable > > attributes > > > > > > > > > On 1/25/10, Kevin Myers <KevinMyers(a)austin.rr.com> wrote: > > > > > > > proc transpose data=original out=skinny type length format informat > > force > > > > noformat; by obsno; > > > > var _all_; run; > > > > > > > > proc transpose data=skinny out=final noinformat; by obsno; > > > > id _NAME_; idlabel _LABEL_; idtype _TYPE_; idlength _LENGTH_; > idformat > > > > _FORMAT_; idinformat _INFORMAT_; > > > > var col1; run; > > > > > > > > If you can manage to accomplish something similar with code that is > > anywhere > > > > remotely close to something this simple, then you win a (virtual) > > cookie. > > > > > > > > > > Seems obvious: data=original > > > > > > > > > > > > > > > |