Plus, the objective is to grab the ODS output; I don't see how to grab the ODS output from each run if I only have one Proc statement.

-Mary ----- Original Message ----- From: Keintz, H. Mark To: SAS-L@LISTSERV.UGA.EDU Sent: Tuesday, July 08, 2008 12:17 AM Subject: Re: SET with OBS=0

Howard Schreier said:

Subject: Re: SET with OBS=0 > > On Mon, 7 Jul 2008 16:48:05 -0500, Mary <mlhoward@AVALON.NET> wrote: > > >No, they are for different variables (10000 variables), so a BY > statement > >would not work, as a BY statement subsets observations, not variables. > I > >can't transpose it because I do have other variables on the same row, > such > >as smoking and age that are also in the models. > > I don't think that's an obstacle. Presumably you have a data set like > > data demo; > input id y age smoke var1 var2 var50000; > cards; > 1 165 43 0 7 7 3 > 2 401 49 1 2 8 2 > 3 627 49 0 6 7 9 > 4 29 36 0 8 6 8 > 5 765 48 0 3 2 8 > 6 681 53 0 8 3 6 > 7 713 47 0 5 3 9 > 8 890 67 0 8 9 4 > 9 292 62 0 5 3 1 > ; > > You *can* estimate different models by coding them in separate > statements or > even separate PROC steps > > proc reg data= demo; > model y = smoke age var1; > model y = smoke age var2; > model y = smoke age var50000; > run; > quit; > > but you don't have to. You can also transpose > > proc transpose data=demo > out=long(rename = ( _name_ = varname col1 = varvalue) ); > by id y smoke age; > var var : ; > run; > > then sort > > proc sort data=long; by varname id; run; > > and finally run all of the models via a single MODEL statement > supported by > a BY statement. > > proc reg data=long; > by varname; > model y = smoke age varvalue; > run; > quit;

But the downside with this approach is that you'll wastefully recalculate the sum-of-square-and-cross-products for (Y, SMOKE, AGE) once for each level of VARNAME. In comparison, using the PROC REG with multiple model statements (all including Y, SMOKE, and AGE) does it once, possibly with some minor model-by-model tweaking for differing patterns of missing data in VAR1, VAR2, ... .

> > > > >-Mary > > ----- Original Message ----- > > From: data _null_, > > To: Mary > > Cc: SAS-L@listserv.uga.edu > > Sent: Monday, July 07, 2008 4:42 PM > > Subject: Re: Re: SET with OBS=0 > > > > > > On 7/7/08, Mary <mlhoward@avalon.net> wrote: > > > > > > Yes, and that's what I'm doing in handling the count=0 code; > attempt to run > > > it again with a different parameter, > > > > That is not what I was trying to say at all. If I understand you > > correctly you "macro" loop over the 10,000 "sets/runs" Getting the > > results one-at-a-time, check the "status" and try again. This seems > > too loopy and slow to me. Wouldn't it be better to fit the 10,000 > > "sets/runs" using BY group processing. Then determine which ones > did > > not "fit" and refit those. You still do it programmaticly just not > > one-at-a-time. > > > > You will avoid 10,000 SQL steps and 10,000 sets and 10,000 > logistics. > > > > It sounds somewhat similar to a simulation where Cassell has shown > how > > much faster the BY group approach is compared to macro looping. > > > > The results would be the same but with fewer steps. > > > > >and if that still doesn't get it to > > > run, then save the model info to a running data set so that I've > got > all the > > > ones that finally didn't run together. This means I've got lots > of things > > > in both blocks of code- attempts at reruns if the code did not > run, and > > > saving of model info, in addition to the output of the things that > did run > > > in my block of code if it did work. > > > > > > It is legal in many statistical procedures to just not get ODS > output on a > > > procedure even though the procedure worked- such as odds ratios > may not be > > > appropriate for that particular run, and I'm accumulating a final > > > spreadsheet of data in which that cell would just be blank, and > > > appropriately so; it isn't an error in the analysis. The > trouble is, > > > normal SAS output for something like a Proc Logistic can be up to > 3 pages > > > long, and therefore 30,000 pages for 10,000 runs, whereas I want > just one > > > row of output for each run, with perhaps 10,000 rows down. Using > the macro > > > If statements in conjunction with ODS can do this, and it is one > of the > > > reasons why so many genetics people are going over to R, because > they don't > > > think only R can do this, but SAS can, so that's why I brought it > up in the > > > SAS vs. R discussion. > > > > > > -Mary > > > ----- Original Message ----- > > > From: data _null_, > > > To: Mary > > > Cc: SAS-L@listserv.uga.edu > > > Sent: Monday, July 07, 2008 4:13 PM > > > Subject: Re: Re: SET with OBS=0 > > > > > > On 7/7/08, Mary <mlhoward@avalon.net> wrote: > > > > The problem with the call execute statement is that it is only > one thing, > > > > instead of allowing me to just handle the condition and move on- > usually > > > I'm > > > > trying to aggregate 10,000 runs or so- I **don't** want to stop > just > > > because > > > > one didn't work. > > > > > > The call execute(endsas) was an example I don't know exactly what > you > > > are trying to do. I am not following the R thread closely and I > did > > > not read your contributions. > > > > > > To me it would seem more efficient to fit all 10,000 "runs" using > by > > > group processing. Then examine the "misfits" and refit them using > > > different parameters then examine the "misfits" and refit those > etc.