Date: Sun, 21 Jun 2009 22:51:36 -0500
Reply-To: "Data _null_;" <iebupdte@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Data _null_;" <iebupdte@GMAIL.COM>
Subject: Re: Venting on the strengths and weaknesses of SAS
In-Reply-To: <30d73af3-bad9-43e9-ad6f-ede0703d1bfe@l32g2000vba.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
I don't have time to read your posts.
I would like "fancy proc print" sort of like what QPRINT would have
been. I don't use the summary features of PROC REPORT, but I use it
becaue it is better than nothing.
On 6/21/09, xlr82sas <xlr82sas@aol.com> wrote:
> On Jun 21, 12:15 pm, xlr82sas <xlr82...@aol.com> wrote:
> > Hi SAS-Lers,
> >
> > There is an interesting thread on the perl listhttp://groups.google.com/group/comp.lang.perl.misc/browse_thread/thre...
> > basically it talks about the strengths and weaknesses of perl. Much of
> > the dicussion is germaine to SAS.
> >
> > Topic
> > perl WTFs (What the f***)- not poorly written code, by WTFs in perl
> > itself.
> > comp.lang.perl.misc
> >
> > The perl list often have posts useful to SAS programmers. REGEX and
> > HASH posts.
> > The R mailing list is also a good place for SAS IML programmers
> >
> > Major - DUMB things SAS is doing or has done
> >
> > R AND IML
> > Proc Matrix(early IML) used to be free with base SAS. I remember when
> > SAS downgraded the functionality and and made customers pay for it.
> > proc matrix had quad word numeric precision (128bit). proc IML only
> > has 64bit precision. SAS is getting its comupetence with R.
> >
> > I recently had to convert a numeric algorithm from R to IML. All I had
> > to do was cut and paste the R code and change some of the mattrix
> > operators.
> >
> > Here is what SAS should do:
> > Make IML part of Base(Like it did with SQL)
> > Allow R packages to be called from IML
> > This will lead to substantial growth in sales in the pharma sector
> >
> > SQL AND UNIVARIATE STATS
> > To produce reports that have both counts/percents and univariate
> > stats(median) it is necessary to run both sql and proc univariate.
> > This complicated most pharama reports
> >
> > Here is whar SAS should do:
> > Add the median to SQL (note median(x) in sql is the same as just
> > x) this is really dumb
> > Add first dot and last.dot and all the order statistics to SQL.
> >
> > PROC REPORT
> > When a programmer has order=data on all the columns, proc report
> > should not decide to change the order order of the data. This is a
> > huge problem if you use proc report like a data null, as I do.
> >
> > I never use across or summary stats in proc report. I basically
> > transpose normalized structures(long and skinny) just before report. I
> > have been burned to many times when the across columns need to have
> > individual formatting. Also subscripting summary columns or rows.
> >
> > Here is what SAS should do
> > I
>
> I did not have time to complete my rants
>
> MORE ON PROC REPORT
>
> 1. If the programmer explicitly defines the order of the data, report
> should not decide to scramble the rows.
> 2. Expand the use of proc report to imbed graphics so that a graph
> can extend across rows and down columns.
> Like the merge function in excel.
>
> Suppose I want a confidence interval graphically represented next
> upper and lower bound columns in proc report. This can only be done in
> one cell at a time, there is no way to set aside a rectangle in proc
> report for graphs and flow text around the graph.
> Below is an example of putting graphs in proc report. Maybe SAS could
> create 'proc report lite' that would have the optons above but not
> across, summary capabilities.
>
> ie
>
> %utl_goptpng(h=4.5,fnt=%str(Arial),ptsize=9.5); /* my png driver
> you should be able to substitute gif
> */
> data
> lwrupr;
>
> key='001';
>
> lwr=0.2;
> mid=.
> 9;
>
> upr=2.6;
> var=.
> 25;
>
> output;
>
> key='002';
>
> lwr=0.1;
>
> mid=1.5;
>
> upr=3.1;
> var=.
> 45;
>
> output;
> run;
> proc
> sql;
>
> create
> table addminmax
> as
>
> select
>
> key
> ,lwr
> ,mid
> ,upr
> ,var
> ,var/(select mean(var) from lwrupr) as
> varscl
> ,(select min(lwr) from lwrupr) as
> lwrmin
> ,(select max(upr) from lwrupr) as
> uprmax
>
> from
>
> lwrupr
> ;quit;
>
> data
> anocis;
> length style
> $32;
> length function color $
> 8;
> length xsys ysys hsys $
> 1;
> length when position $
> 1;
> retain position xsys "5" ysys "5" hsys "3" x y . when style color
> function " ";
> set addminmax
> (obs=1);
> scale = (uprmax - lwrmin)/
> 100 ;
> x1 = (lwr-lwrmin)/
> scale ;
> x2 = (upr-lwrmin)/
> scale ;
> xm = (mid-lwrmin)/
> scale ;
> xo = ( 1-lwrmin)/
> scale ;
> %move ( x1,
> 50 );
> %draw ( x2, 50, black, 1,
> 4);
> %move ( xo,
> 0 );
> %draw ( xo,100, black, 1,
> 4);
> cir = 60*varscl/
> 2 ;
> %slice(xm, 50, 0, 360, cir, black, solid,
> 1);
> run;
> title;
> footnote;
> filename bar "/groundtruth/rdeangel/utl/
> bar.png";
> goptions reset=global device=png300 gsfname=bar hsize=1in vsize=.2in
> lfactor=2;
> proc gslide
> anno=anocis;
> run;quit;
> filename bar
> clear;
>
> ods rtf file="/groundtruth/rdeangel/utl/dem.rtf" style=amg_rtflan100
> notoc_data headery=5 footery=5 startpage=no;
> proc report
> data=sashelp.class;
> cols name sex
> grf;
> define name /
> display;
> define sex /
> display;
> define grf /
> computed;
> compute grf /
> char;
> call define(_col_,'style',"style=[preimage='/groundtruth/rdeangel/
> utl/bar.png']");
> endcomp;
> run;quit;
> ods rtf
> close;
>
> DATA STEP
>
> It seems dumb to me to have to strip, left, trim and to worry about
> leading and trailing blanks.
> Create a new datatype that stores strings with there proper length.
>
> Also I think SAS should think ahead about 128bit numerics
>
> =========================================================
>
> I agree with the perl post but would add
>
> Using SAS is like digging the panama canal with a steam shovel
> Using Perl is like digging a panama canal with a backhoe.
> Using C is like digging a panama canal with a shovel.
> Using Java is like digging panama canal with a spoon.
>
| 
