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
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 <email@example.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.
> %utl_goptpng(h=4.5,fnt=%str(Arial),ptsize=9.5); /* my png driver
> you should be able to substitute gif
> table addminmax
> ,var/(select mean(var) from lwrupr) as
> ,(select min(lwr) from lwrupr) as
> ,(select max(upr) from lwrupr) as
> length style
> length function color $
> length xsys ysys hsys $
> length when position $
> retain position xsys "5" ysys "5" hsys "3" x y . when style color
> function " ";
> set addminmax
> 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,
> %move ( xo,
> 0 );
> %draw ( xo,100, black, 1,
> cir = 60*varscl/
> 2 ;
> %slice(xm, 50, 0, 360, cir, black, solid,
> filename bar "/groundtruth/rdeangel/utl/
> goptions reset=global device=png300 gsfname=bar hsize=1in vsize=.2in
> proc gslide
> filename bar
> ods rtf file="/groundtruth/rdeangel/utl/dem.rtf" style=amg_rtflan100
> notoc_data headery=5 footery=5 startpage=no;
> proc report
> cols name sex
> define name /
> define sex /
> define grf /
> compute grf /
> call define(_col_,'style',"style=[preimage='/groundtruth/rdeangel/
> ods rtf
> 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.