Date:         Thu, 28 Aug 2003 14:47:16 +0100
Reply-To:     david.mcnulty@QUESTINTL.COM
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         david.mcnulty@QUESTINTL.COM
Subject:      Re: SAS Ballot Request?  Option to "Maintain Hierarchy" for Proc
              REG?
Comments: To: john.hixon@KODAK.COM
Content-type: text/plain; charset=us-ascii

Hi John,

The point as I see it is that PROC REG cannot know the hierarchy of
variables unless it is told the hierarchy. The following code does not work
but will serve for discussion.

proc reg data=data;
   model y = {x} {x x2} {x x2 x3} / selection=stepwise;
run;

where x=rannor(seed) x2=x*x x3=x*x*x

PROC REG rejects the model statement because two of the variables are
include in the statement more than once.  It is relatively simple to
overcome the problem.

proc reg data=data;
   model y = {x} {ax ax2} {bx bx2 bx3} / selection=stepwise;
run;

If PROC REG is modified to allow duplicate variable names in separate
groups then PROC REG can be used as above to choose between hierarchical
models. Furthermore it would be possible to write a macro e.g. Pol(x,3) to
produce polynomial models as in the first set of code.

Whether such a device is useful considering the alternative regression and
modelling procedures is another matter. I do not recall the last time I
used PROC REG.

Regards

Dave.





                      "John Hixon"
                      <john.hixon@KODA         To:      <SAS-L@LISTSERV.UGA.EDU>
                      K.COM>                   cc:
                      Sent by:                 Subject: SPAM:      Re: SAS Ballot Request?  Option to "Maintain
                      "SAS\(r\)                Hierarchy" for Proc              REG?
                      Discussion"
                      <SAS-L@LISTSERV.
                      UGA.EDU>


                      28/08/2003 10:38
                      Please respond
                      to john.hixon






Ian,

All I can say is: Wow.  You are amazing.  You were able to code
a macro which is a viable workaround for my "maintain hierarchy
in Proc Reg" suggestion, in a very short time.

And, as the Grand Master that you are, you highlighted the crucial
point that my request for a "maintain hierarchy" option in
Poc Reg is logically impossible.  You took a "programmer's
view" of the request, and from that perspective, it is clear
that there is no way for Proc Reg to "know" what the hierarchy
should be.

I think I'm way too over-tired from clearing the decks before my
vacation (otherwise I wouldn't have proposed a ballot item that
is impossible to implement!  I'm glad I did not send the
request to SAS.)  After being prodded to think more logically
(by reading your excellent macro work-around this morning), it
is clear that there would be no way for Proc REG to do this.

Proc REG is the most general of all Ordinary Least Squares
(OLS) ANOVA based Procs.  It requires the SAS programmer to
create the Design Matrix X as a set of columns where each column
represents a one degree of freedom "factor".  As such, Proc
REG will never have any idea which factor precedes another
in model hierarchy (as opposed to other SAS model fitting
Procs such as GLM, where the model can be built up from
"main Effect factors" within the Proc).  There might be
the possibility of adding a "retain hierarchy" option to
Procs like GLM, but never to Proc REG.

I posed the question after working with another software package,
"Design Expert" from Stat/Ease.  This is an excellent niche product for
the design and analysis of experiments.  But, it has some rather
severe restrictions: no random effects, no nested effects,
all experimental units must be the same size (ie: no split-plot
models).  Still, for 'standard' DOEs it is a *very* useful
tool.  It includes the option to "maintain hierarchy", but,
of course, it is easy for Design Expert to implement this since
it builds up the design matrix from the definition of the
"Main Effects" terms: so, it knows in advance which terms are
main effects and which terms are higher order or interactions.
Proc Reg will *never* have this foreknowledge, since it is a
very general procedure so that "each design column=one degree
of freedom factor", and each degree of freedom factor could
be a main effect, an interaction, or higher-order-term.
Proc Reg will never know.  So,it can never "maintain hierarchy".

Thanks again for your reply, Ian.  The macro that you propose is
a viable solution to my specific problem, and also forced
me to "think like a programmer" and realize that my request
for a "maintain hierarchy" option in Proc Reg is impossible
to implement.

I stand in awe of the gurus on this list (you know who you
are, I risk leaving some out by trying to name some off
the top of my head [especially since I've been deleting
all of the digests lately], but:  cassell, whitlock, dorfman,
huang, deangelis, devenzia (sp?), mclerran, schreier, et al.)
There is no batter way to grow in SAS knowledge than reading
this list!




Best regards,

John Hixon
Eastman Kodak Company
Rochester, NY USA
585-477-1984

This email has been scanned for Viruses and Spam





IMPORTANT NOTICE:
This email may be confidential, may be legally privileged, and is for the intended recipient only.  Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence.  Please delete if obtained in error and email confirmation to the sender.