From: Dale McLerran on
OK. I am looking forward to learning more about JavaObj. I
am certainly not pleased with the limited capabilities of the
functions and call routines available through PROC FCMP.

And you are absolutely correct that there are many operations
that PROC FCMP doesn't even pretend to make available like
performing a singular value decomposition of a matrix.
Altogether, the FCMP procedure has not addressed critical
needs.

Using other SAS procedures besides IML in order to obtain an
SVD may have some utility. However, to my way of thinking,
such utility would be limited. I would want to be able to
obtain an SVD within a data step or procedure which constructs
the matrix that requires the SVD decomposition.

Dale

---------------------------------------
Dale McLerran
Fred Hutchinson Cancer Research Center
mailto: dmclerra(a)NO_SPAMfhcrc.org
Ph: (206) 667-2926
Fax: (206) 667-5977
---------------------------------------


--- On Fri, 12/11/09, oloolo <dynamicpanel(a)YAHOO.COM> wrote:

> From: oloolo <dynamicpanel(a)YAHOO.COM>
> Subject: Re: SAS vs. SPLUS vs. SAS
> To: SAS-L(a)LISTSERV.UGA.EDU, "Dale McLerran" <stringplayer_2(a)YAHOO.COM>
> Date: Friday, December 11, 2009, 4:17 PM
> NO, I am not talking about PROC FCMP.
> I don't have SAS9.2 and I can't do
> any test on it either. If I really need a serious computing
> agent within
> DATA STEP ( I know functions compiled by FCMP can also be
> used in other
> PROCs), I will turn to JavaObj.
>
> My way is to discover the mathematical relationship between the
> underlying algorithms used in various PROC in SAS/STAT and try to
> build the link between them, either by developing iterative
> algorithms or directly resort to the results. On example is
> observing that one computation method for PCA is via SVD, so that
> we can do SVD. There are also many features in SAS/STAT we can
> discover to facilitate our implementation of new algorithms.
>
> The SVD discovery stands out because SVD is at the heart of many modern
> data mining algorithms and from here, we can go a lot further.
>
From: Ken Borowiak on
Paul,

Have you taken a look at the support for sequential designs in V9.2?

http://support.sas.com/documentation/cdl/en/statug/63033/HTML/default/seqd=
esign_toc.htm

Regards,
Ken Borowiak

=20

=20

-----Original Message-----
From: Paul Miller <pjmiller_57(a)YAHOO.COM>
To: SAS-L(a)LISTSERV.UGA.EDU
Sent: Fri, Dec 11, 2009 4:09 pm
Subject: SAS vs. SPLUS vs. SAS


Hello Everyone,
=20
I=E2=80=99ve recently become interested in sequential clinical trials desi=
gns. I=E2=80=99ve=20
purchased a book that discusses the topic called =E2=80=9CAnalysis of Clin=
ical Trials=20
using SAS: A Practical Guide.=E2=80=9D Upon trying to run some of the code=
samples from=20
the book, I=E2=80=99ve learned that we don=E2=80=99t have Proc IML. Until=
recently, I was under=20
the impression that, as a data manipulation feature, Proc IML was a part=
of Base=20
SAS. I was disappointed to learn that this is not the case and was even mo=
re=20
disappointed when I learned what it would cost to add IML to our server li=
cense.=20

=20
So I=E2=80=99m now considering some alternatives. SPLUS has an add-on call=
ed SEQTRIAL=20
that can be used for sequential clinical trials designs. I=E2=80=99ve obta=
ined a 30-day=20
trial and spent some time playing around with the SEQTRIAL component. I ha=
ve=20
virtually no experience using SPLUS, but the software appears to be of goo=
d=20
quality and adding SEQTRIAL to our current version of SPLUS would be cheap=
er=20
than purchasing IML.=20
=20
A third possibility would be to use the SEQDESIGN and SEQTEST procedures=
that=20
became available in SAS 9.2. Although I don=E2=80=99t currently have SAS=
9.2, I should=20
have it shortly. One concern I have about these procedures is that they ar=
e=20
=E2=80=9Cexperimental.=E2=80=9D I believe that SAS Institute normally indi=
cates that such=20
procedures should not be used in the =E2=80=9Cproduction environment.=E2=
=80=9D So it=E2=80=99s not clear=20
how I could use these procedures to do work for any of our clients and it=
=E2=80=99s not=20
clear how long these procedures will remain experimental.
=20
At this point, I was wondering if anyone out there has experience with any=
of=20
these options and would be willing to comment on their relative merits. Al=
so, I=20
was hoping someone might be able to comment on the relative merits of SAS=
vs.=20
SPLUS. My thinking was that if we started using SPLUS, this might give us=
some=20
additional capabilities that we wouldn=E2=80=99t normally get through SAS.
=20
Thanks,
=20
Paul =20

=20
=20
=20
=20


__________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explore=
r=C2=AE 8.=20
Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca=
/internetexplorer/

=20
From: ajay ohri on
I find the whole Software 1 versus Software 2 debate amusing, bemusing and =
since these are the Holidays a bit hmmmm
There is no Holy Grail of Software- price is dependent on demand and supply=
and in services on benefit/cost- all softwares can do things differently i=
n an excellent manner and are priced differently.=C2=A0
clearly the fact that even experienced users of SAS sometimes are unaware o=
f different parts of the excellent product portfolio means the website of s=
upport.sas needs to be DESIGNED more like an iPhone interface than like a P=
C like dump of large documents=C2=A0
and with an enhanced search functionality than is currently available.
the design of the website of support.sas needs to tie in an quantitaive ana=
lysis of usage through web analytics ( using clickstream), a feedback loop =
of (rate how helpful this result was)- missing as of now AND
different interfaces for different users- a student doesnot need to see the=
same support.sas website as say a CTO =C2=A0- this can be accomplished if =
they start using some kind of registration ( the easiest and most friendly =
is OAuth) ( also will help them track social media presence of customers fo=
r marketing ;) )
nice name zoo(a)aol :)


regards-Ajay





=C2=A0 =20
"If you have the guts, you will have the glory" =20

=C2=A0 =20

--- On Sun, 12/13/09, Ken Borowiak <evilpettingzoo97(a)AOL.COM> wrote:

From: Ken Borowiak <evilpettingzoo97(a)AOL.COM>
Subject: Re: SAS vs. SPLUS vs. SAS
To: SAS-L(a)LISTSERV.UGA.EDU
Date: Sunday, December 13, 2009, 7:13 PM

Paul,

Have you taken a look at the support for sequential designs in V9.2?

http://support.sas.com/documentation/cdl/en/statug/63033/HTML/default/seqde=
sign_toc.htm

Regards,
Ken Borowiak

=20

=20

-----Original Message-----
From: Paul Miller <pjmiller_57(a)YAHOO.COM>
To: SAS-L(a)LISTSERV.UGA.EDU
Sent: Fri, Dec 11, 2009 4:09 pm
Subject: SAS vs. SPLUS vs. SAS


Hello Everyone,
=20
I=E2=80=99ve recently become interested in sequential clinical trials desig=
ns. I=E2=80=99ve=20
purchased a book that discusses the topic called =E2=80=9CAnalysis of Clini=
cal Trials=20
using SAS: A Practical Guide.=E2=80=9D Upon trying to run some of the code =
samples from=20
the book, I=E2=80=99ve learned that we don=E2=80=99t have Proc IML. Until r=
ecently, I was under=20
the impression that, as a data manipulation feature, Proc IML was a part of=
Base=20
SAS. I was disappointed to learn that this is not the case and was even mor=
e=20
disappointed when I learned what it would cost to add IML to our server lic=
ense.=20

=20
So I=E2=80=99m now considering some alternatives. SPLUS has an add-on calle=
d SEQTRIAL=20
that can be used for sequential clinical trials designs. I=E2=80=99ve obtai=
ned a 30-day=20
trial and spent some time playing around with the SEQTRIAL component. I hav=
e=20
virtually no experience using SPLUS, but the software appears to be of good=
=20
quality and adding SEQTRIAL to our current version of SPLUS would be cheape=
r=20
than purchasing IML.=20
=20
A third possibility would be to use the SEQDESIGN and SEQTEST procedures th=
at=20
became available in SAS 9.2. Although I don=E2=80=99t currently have SAS 9.=
2, I should=20
have it shortly. One concern I have about these procedures is that they are=
=20
=E2=80=9Cexperimental.=E2=80=9D I believe that SAS Institute normally indic=
ates that such=20
procedures should not be used in the =E2=80=9Cproduction environment.=E2=80=
=9D So it=E2=80=99s not clear=20
how I could use these procedures to do work for any of our clients and it=
=E2=80=99s not=20
clear how long these procedures will remain experimental.
=20
At this point, I was wondering if anyone out there has experience with any =
of=20
these options and would be willing to comment on their relative merits. Als=
o, I=20
was hoping someone might be able to comment on the relative merits of SAS v=
s.=20
SPLUS. My thinking was that if we started using SPLUS, this might give us s=
ome=20
additional capabilities that we wouldn=E2=80=99t normally get through SAS.
=20
Thanks,
=20
Paul=C2=A0=20

=20
=20
=20
=20


=C2=A0 =C2=A0 =C2=A0 ______________________________________________________=
____________
Make your browsing faster, safer, and easier with the new Internet Explorer=
=C2=AE 8.=20
Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/=
internetexplorer/

=20
=0A=0A=0A
From: Shawn Haskell on
On Dec 11, 7:08 pm, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote:
> If you are referring to matrix manipulations which can be
> performed employing routines made available with PROC FCMP,
> those routines are not an adequate substitute for a
> full-fledged matrix programming language.  Also, I have
> found that the matrix routines are not really accessible
> in SAS/STAT procedures the way that they should be.
>
> I have brought this to the attention of SI.  Their response
> was that they were not aware of the problems until I reported
> that I could not employ the matrix operations during execution
> of NLMIXED code.  On further consideration, they determined
> that the FCMP procedure only supports derivatives of functions
> and does not support derivatives of CALL routines.  Moreover,
> the FCMP procedure does not support returning an array from
> a function.  Thus, the FCMP matrix operators have limited
> utility within SAS procedures.
>
> I have railed against SI for years about their inability
> to provide matrix capability for procedures which accept
> programming statements.  I really thought that SAS had
> overcome some of these issues when they released PROC FCMP
> and stated that functions and routines coded in FCMP were
> available to both the data step and procedures which supported
> programming statements.  SI still has quite a way to go
> with this functionality.
>
> Dale
>
> ---------------------------------------
> Dale McLerran
> Fred Hutchinson Cancer Research Center
> mailto: dmclerra(a)NO_SPAMfhcrc.org
> Ph:  (206) 667-2926
> Fax: (206) 667-5977
> ---------------------------------------
>
> --- On Fri, 12/11/09, oloolo <dynamicpa...(a)YAHOO.COM> wrote:
>
>
>
> > From: oloolo <dynamicpa...(a)YAHOO.COM>
> > Subject: Re: SAS vs. SPLUS vs. SAS
> > To: SA...(a)LISTSERV.UGA.EDU
> > Date: Friday, December 11, 2009, 2:23 PM
> > matrix is indispensible tool in
> > implementing modern data mining algorithm,
> > but we only have native matrix opertion capability in IML.
>
> > Recently I discovered that in SAS/Base SAS/Stat, we were able to conduct
> > several important matrix manipulations and I able to translate those
> > prototype algorithms on textbook into SAS.
>
> > I just submited a paper to SGF2010 on this topic, hope the paper can be
> > accepted.
>
> > On Fri, 11 Dec 2009 13:09:32 -0800, Paul Miller <pjmiller...(a)YAHOO.COM>
> > wrote:
>
> > >Hello Everyone,
> > >Â
> > >I’ve recently become interested in sequential
> > clinical trials designs.
> > I’ve purchased a book that discusses the topic
> > called “Analysis of Clinical
> > Trials using SAS: A Practical Guide.†Upon trying to
> > run some of the code
> > samples from the book, I’ve learned that we
> > don’t have Proc IML. Until
> > recently, I was under the impression that, as a data
> > manipulation feature,
> > Proc IML was a part of Base SAS. I was disappointed to
> > learn that this is
> > not the case and was even more disappointed when I learned
> > what it would
> > cost to add IML to our server license.
> > >Â
> > >So I’m now considering some alternatives. SPLUS
> > has an add-on called
> > SEQTRIAL that can be used for sequential clinical trials
> > designs. I’ve
> > obtained a 30-day trial and spent some time playing around
> > with the
> > SEQTRIAL component. I have virtually no experience using
> > SPLUS, but the
> > software appears to be of good quality and adding SEQTRIAL
> > to our current
> > version of SPLUS would be cheaper than purchasing IML.
> > >Â
> > >A third possibility would be to use the SEQDESIGN and
> > SEQTEST procedures
> > that became available in SAS 9.2. Although I don’t
> > currently have SAS 9.2,
> > I should have it shortly. One concern I have about these
> > procedures is that
> > they are “experimental.†I believe that SAS
> > Institute normally indicates
> > that such procedures should not be used in the
> > “production environment.†So
> > it’s not clear how I could use these procedures to
> > do work for any of our
> > clients and it’s not clear how long these procedures
> > will remain
> > experimental.
> > >Â
> > >At this point, I was wondering if anyone out there has
> > experience with any
> > of these options and would be willing to comment on their
> > relative merits.
> > Also, I was hoping someone might be able to comment on the
> > relative merits
> > of SAS vs. SPLUS. My thinking was that if we started using
> > SPLUS, this
> > might give us some additional capabilities that we
> > wouldn’t normally get
> > through SAS.
> > >Â
> > >Thanks,
> > >Â
> > >Paul Â
>
> > >Â
> > >Â
> > >Â
> > >Â
>
> > Â  Â  Â
> > __________________________________________________________________
> > Make your browsing faster, safer, and easier with the new
> > Internet
> > Explorer® 8. Optimized for Yahoo! Get it Now for Free!
> > at
> >http://downloads.yahoo.com/ca/internetexplorer/- Hide quoted text -
>
> - Show quoted text -

good points about similarities between R and Splus - I will also agree
with a former post that Splus graphing is far superior to SAS. If
matrix operations are your thing then I would be surpised if you can
find anything better than MATLAB by MathWorks - the syntax is pretty
intuitive and efficient with many built-in functions - programming
potential in MATLAB strikes me as limitless. Shawn
From: oloolo on
Nice.
My ideal case would be doing all linear algebra related work in Java. There
are several Java pacakges for numerical computing out there.

>Just some thoughts
>
>1. Whats avaialble on my site
>2. I think it is possible in 9.2 to call R using JavaObj and to pass
>and array (matrix) and return the SVDG(Ginverse?) matrix. It may be
>possible from FCMP using run_macro, I am just not sure. I have an
>example of passing a value and returning a result from R using
>JavaObj.
>3. You can invert a matrix in the datastep via my hokey technique,
>which may be a startting point for programmers who have more time then
>me. This method calls R using windows pipe.
>4. You can interface R and SAS using 'loseless SAS export datasets.
>Loseless on mainframes but very slight issues with IEEE floating point
>(exponent has three more bits in IEEE and three less in mantissa)
>5. Coverting R to IML.
>6. You will find some instructions on my site to interface R packages
>with SAS.
>
>======================================================================
>
>1. Whats avaialble on my site
>see
>http://homepage.mac.com/magdelina/.Public/utl.html
>
>Running R code from SAS using javaobj utl_volume_r.txt
>Interfacing with R using IMLPlus sar_imlstudio.txt
>Simplified interface between R and SAS to invert a matrix windows XP
>sar_wininvert.txt
>Updating R package outliers for use with SAS outliers.zip
>Subroutines, Macros, FCMP and IML Modules in SAS utl_noglobal.txt
>Why I wrote the xportsas package xportsas.txt
>R Package for lossless SAS export data transfer to and from R on SUN
>64bit systems(big endian) xportsas_1.0.0.tar.gz
>Source coode for lossless SAS export data transfer to and from R on
>SUN 64bit systems(big endian) xportsas.zip
>Interface to R Graphics from SAS R_graphics_to_sas
>Interface to R Graphics from SAS R_graphics_to_sas
>
>
===========================================================================
>5. Coverting R to IML.
>
>It is quite easy to convert R to SAS IML. Here is an example of R/S+
>code and SAS IML code. It is not exactly the same problem but is very
>colse.
>
>I find IML has much of the same functiionality of R, but R blows SAS
>away with the 2000+ packages out there.
>
>R/S+ CODE
>
>a=c
>
(2,2,1,0,1,0,1,5,1,1,0,2,2,2,2,1,1,2,3,0,0,0,1,1,0,2,1,1,1,1,0,1,0,1,1,1,1,0
,1,1,15,27,0,0,0,0,0,0)
>b=c
>
(355,389,773,213,231,43,120,105,381,283,294,561,276,416,393,202,103,210,135,
196,122,175,55,38,561,114,147,230,88,167,116,1171,706,203,287,253,313,162,44
1,393,2620,1429,101,232,70,25,196,676)
>c=c
>
(0,1,1,1,0,1,0,2,0,0,1,0,1,0,1,1,2,0,1,0,1,1,0,0,2,3,0,0,0,0,0,0,0,2,0,0,0,0
,0,0,9,41,0,0,0,0,0,0)
>d=c
>
(176,206,184,108,116,46,124,112,384,135,301,142,278,212,197,105,97,107,138,9
6,119,172,58,38,274,108,143,242,88,172,61,377,325,183,280,272,154,160,112,12
4,2625,2854,51,115,75,24,195,225)
>n <- a+b+c+d
>Rr <- (c+d)/(a+b)
>k.T <- 1/(Rr+1)
>k.C <- Rr/(Rr+1)
>OR.i <- ((a+k.T)*(d+k.C))/((b+k.T)*(c+k.C))
>varlnOR.i <- 1/(a+k.T)+1/(b+k.T)+1/(c+k.C)+1/(d+k.C)
>w.i <- 1/varlnOR.i
>plogOR.i <- sum(w.i*log(OR.i))/sum(w.i)
>pvarlogOR.i <- 1/sum(w.i)
>pOR.iv.i <- exp(plogOR.i)
>l.pOR.iv.i <- exp(plogOR.i-qnorm(.975)*sqrt(pvarlogOR.i))
>u.pOR.iv.i <- exp(plogOR.i+qnorm(.975)*sqrt(pvarlogOR.i))
>
>SAS CODE
>
> Just to read a bunch of columns rom s SAS dataset(dataframe in R)
> use inv1st(keep=Key) ;read all var _num_ into keyxpo;
> use inv1st(keep=TrtEvn) ;read all var _num_ into axpo;
> use inv1st(keep=TrtNonEvn);read all var _num_ into bxpo;
> use inv1st(keep=CtlEvn) ;read all var _num_ into cxpo;
> use inv1st(keep=CtlNonEvn);read all var _num_ into dxpo;
>
> /* Vertical to horizontal */
> a=axpo`; * The apostrophe means transpose;
> b=bxpo`;
> c=cxpo`;
> d=dxpo`;
> key=keyxpo`;
>
> Rr=(c+d)/(a+b); * ratio of control vs trtment group sizes;
> k_T=1/(Rr+1);
> k_C=Rr/(Rr+1);
>
> OR_C_R = ((a+k_T)#(d+k_C))/((b+k_T)#(c+k_C));
> VAR_OR_C_R = 1/(a+k_T) + 1/(b+k_T) + 1/(c+k_C) + 1/(d+k_C);
> W_R = 1/VAR_OR_C_R;
>
> LOG_OR_IV_R = sum(W_R#log(OR_C_R))/sum(W_R);
> VAR_LOG_OR_IV_R = 1/sum(W_R);
>
> OR_IV_R = exp(LOG_OR_IV_R);
> OR_IV_UP_R = exp(LOG_OR_IV_R + probit(.975)#sqrt
>(VAR_LOG_OR_IV_R));
> OR_IV_LOW_R = exp(LOG_OR_IV_R - probit(.975)#sqrt
>(VAR_LOG_OR_IV_R));
>
> CC_TA=shape({0},1,3,0);
> CC_TA= OR_IV_R||OR_IV_LOW_R||OR_IV_UP_R;
> create CC_TA from CC_TA;append from CC_TA;

nice