clayt85 Tracker
https://communities.sas.com/kntur85557/tracker
clayt85 TrackerMon, 27 May 2024 12:09:49 GMT2024-05-27T12:09:49ZRe: Problems performing 1-sided group sequential design in proc seqdesign
https://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888940#M44034
<P>This bug has been fixed in all versions of the SAS Viya 4 platform. It still exists in all versions of the SAS 9 platform (9.4M8, 9.4M7, ...)</P>Fri, 11 Aug 2023 13:38:33 GMThttps://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888940#M44034clayt852023-08-11T13:38:33ZRe: Problems performing 1-sided group sequential design in proc seqdesign
https://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888637#M44011
<P>Interesting. I see the problem. Here are my results when I run your program exactly as written.</P>
<P><span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="SampleSizeSummary1.png" style="width: 436px;"><img src="https://communities.sas.com/t5/image/serverpage/image-id/86574i7639D387855C8688/image-size/large?v=v2&px=999" role="button" title="SampleSizeSummary1.png" alt="SampleSizeSummary1.png" /></span><span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="SampleSizeSummary2.png" style="width: 451px;"><img src="https://communities.sas.com/t5/image/serverpage/image-id/86575i4BD34CB3C93BEC2A/image-size/large?v=v2&px=999" role="button" title="SampleSizeSummary2.png" alt="SampleSizeSummary2.png" /></span></P>
<P>As you can see, the results differ. (Note also that the results immediately above are slightly different from the results in my previous response. That is because the code in this message uses NSTAGES=1, while in my previous response I used NSTAGES=2.)</P>
<P> </P>
<P>I see your statement that, when you run this latest code snippet, you obtain the same results with both invocations of SEQDESIGN. This is a known bug. First, I'll explain why the results *should* differ. Then I'll explain how you can work around the bug with SAS 9.4M7.</P>
<P> </P>
<P>When the two groups have different NULLHAZARD values, the alternative reference is no longer simply the negative log of the hazard ratio. Rather, you must subtract out the negative log of the hazard ratio at baseline. (See the definition of theta_1 in the MODEL=TWOSAMPLESURVIVAL Section <A href="https://go.documentation.sas.com/doc/en/statcdc/14.2/statug/statug_seqdesign_syntax05.htm#statug.seqdesign.seqdsamptwo" target="_self">here</A>.) Thus, the first invocation (where you specify the ALTREF= value) and the second invocation (the alternative reference gets computed internally by SEQDESIGN) will not match because the alternative reference values will be different. It is the latter invocation of SEQDESIGN that seems to match your stated objectives.</P>
<P> </P>
<P>The bug occurs when you use the NULLHAZARD= option to specify two (different) baseline hazards and then also specify the HAZARDRATIO= option. In this case, SEQDESIGN does not compute the correct value of the hazard for Group A. My comments in the previous paragraph give you a hint for the workaround: you use the (correct) formula to compute the ALTREF= value:</P>
<PRE><CODE class=" language-sas">proc seqdesign altref=%sysevalf(%sysfunc(log(&HR.))-%sysfunc(log(&HR_thresh.))) plots=(none) ;
fixed: design nstages=1 alpha=0.025 beta=&beta. alt=upper ;
samplesize model=twosamplesurvival
(nullhazard=%sysevalf(&Lambda_cnt.*&HR_thresh.) &Lambda_cnt.
acctime=&AT. accrual=UNIFORM foltime=&FUT.);
run;</CODE></PRE>
<P>This will give you the results you desire.</P>Wed, 09 Aug 2023 18:57:58 GMThttps://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888637#M44011clayt852023-08-09T18:57:58ZRe: Problems performing 1-sided group sequential design in proc seqdesign
https://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888469#M44003
<P>Greetings, and thank you for your question.</P>
<P> </P>
<P>I apologize in advance for the long response, but I hope you will find it useful. I've tried to include links to relevant sections of the documentation in case you want additional information.</P>
<P> </P>
<P>First, on PROC POWER. Setting NSUBINTERVAL=2 is much too low. The fact that doing so produces a result of 28 events (close to the R output of 29 events) is pure coincidence. In fact, even the default value of NSUBINTERVAL=12 seems a bit too low in this case. Setting that value much higher (on the order of 1000) will produce a result that is accurate to well within 1%.</P>
<P> </P>
<P>As to why the PROC POWER result (ceiling of 37 events) differs from your R analysis (29 events), my guess is that there are some options/methods/etc that differ somewhere. These power and sample size computations (particularly for survival endpoints), even when nominally similar in their options specifications, can use different underlying statistical models and computational approximations. This leads to different results. That said, here is a code snippet that uses PROC SEQDESIGN to produce a fixed-sample design and agrees with your other result (29 events):</P>
<PRE><CODE class=" language-sas">%let Lambda_cnt=0.01005; %let AT = 1; %let FUT=1; %let HR=0.3; %let alpha=0.025; %let beta=0.1;
%let HR_thresh = 1;
proc seqdesign altref=%sysfunc(log(&HR.));
FixedSample: design nstages=1 alpha=&alpha. beta=&beta. alt=upper;
samplesize model=twosamplesurvival
(nullhazard=%sysevalf(&Lambda_cnt.*&HR_thresh.) &Lambda_cnt.
acctime=&AT. accrual=UNIFORM foltime=&FUT.);
run;</CODE></PRE>
<P>The computations performed by PROCs POWER and SEQDESIGN are summarized in the SAS/STAT documentation (<A href="https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_power_details88.htm" target="_blank" rel="noopener">PROC POWER > Details > Computational Methods and Formulas > Analyses in the TWOSAMPLESURVIVAL Statement</A>; <A href="https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_seqdesign_details52.htm" target="_blank" rel="noopener">PROC SEQDESIGN > Details > Applicable Two-Sample Tests and Sample Size Computation</A>).</P>
<P> </P>
<P>Notice that, in the code above, I specified ALT=UPPER. I also removed the HAZARDRATIO suboption in the SAMPLESIZE statement. To understand why, compare the outputs from the following two analyses:</P>
<PRE><CODE class=" language-sas">proc seqdesign altref=1.203973;
FixedSample: design nstages=1 alpha=&alpha. beta=&beta. alt=upper;
samplesize model=twosamplesurvival
(nullhazard=%sysevalf(&Lambda_cnt.*&HR_thresh.) &Lambda_cnt.
acctime=&AT. accrual=UNIFORM foltime=&FUT.);
run;
proc seqdesign altref=1.203973;
FixedSample: design nstages=1 alpha=&alpha. beta=&beta. alt=lower;
samplesize model=twosamplesurvival
(nullhazard=%sysevalf(&Lambda_cnt.*&HR_thresh.) &Lambda_cnt.
acctime=&AT. accrual=UNIFORM foltime=&FUT.);
run;</CODE></PRE>
<P>Here I have replaced the %sysfunc macro with the hard-coded numerical value just for transparency. The only difference between these two invocations is ALT=UPPER vs ALT=LOWER on the DESIGN statement.</P>
<P> </P>
<P>Compare the Design Information tables. You can see that the value of the alternative reference has changed signs, even though I specified the same alternative reference both times! This is because of the way SEQDESIGN handles the <A href="https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_seqdesign_syntax01.htm#statug.seqdesign.altrefopt" target="_blank" rel="noopener">ALTREF= option</A>--it uses the absolute value of the user-specified value; then the correct sign (+/-) is applied based upon the ALT=option.</P>
<P> </P>
<P>Now compare the Sample Size Summary tables. The hazard rates for Group A are different (they are reciprocals of each other). These hazard rates are calculated from the alternative reference (see the documentation: <A href="https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_seqdesign_syntax05.htm#statug.seqdesign.seqdsamptwo" target="_blank" rel="noopener">SEQDESIGN > Syntax > SAMPLESIZE Statement > Two-Sample Models</A> > MODEL=TWOSAMPLESURVIVAL Subsection). If you use ALTREF=1.203973 you get one value, if you use ALTREF=-1.203973 you get the reciprocal value. You can see that your intended analysis (Hazard Ratio for Group A is 0.3) occurs when ALT=UPPER.</P>
<P> </P>
<P>So why is this an ALT=UPPER test when we want to compare an assumed effect of 0.3 against a null hypothesis of 1.0? Because the power analysis is not based on the hazard rates but rather on the negative log of the hazard ratio. For you, this means -log(0.3/1.0) = 1.203973. This is explained in greater details in the previously linked sections of the SEQDESIGN documentation.</P>
<P> </P>
<P>The next question is: why did I need to remove the HAZARDRATIO suboption in the SAMPLESIZE statement? The truth is: I did not *have* to remove it. The following code will work just fine:</P>
<PRE><CODE class=" language-sas">proc seqdesign;
FixedSample: design nstages=1 alpha=&alpha. beta=&beta. alt=upper;
samplesize model=twosamplesurvival
(nullhazard=%sysevalf(&Lambda_cnt.*&HR_thresh.) &Lambda_cnt.
hazardratio=%sysevalf(&HR.)
acctime=&AT. accrual=UNIFORM foltime=&FUT.);
run;</CODE></PRE>
<P>Notice that this time I removed the ALTREF= option. That is because the ALTREF option is extraneous--the value of the alternative reference can be computed from the information provided on the SAMPLESIZE statement. And this is the key to understand the warning message that you received (in which the SAMPLESIZE statement was ignored because of the ALT=LOWER option). In your code, SEQDESIGN realizes that it has enough information (on the SAMPLESIZE statement) to compute the alternative reference, so it does. The result of that computation is positive (1.203973). This means setting ALT=LOWER does not make any sense; SEQDESIGN prints a warning and then ignores the SAMPLESIZE statement.</P>
<P> </P>
<P>(When printing the warning message, SEQDESIGN *prints* the value of the ALTREF= option if one is provided. That is why, in your screenshot, you see "WARNING: The alternative reference -1.204 is derived...". In fact, the value that is derived by SEQDESIGN is 1.204 (positive) while the value of -1.204 (negative) was provided in the ALTREF= option. This is a bug in the code that prints the warning message.)</P>
<P> </P>
<P>I hope this explains why ALT=UPPER is the correct hypothesis test for your use case.</P>
<P> </P>
<P>On the final issue, when you set HR_thresh = 0.9. What version of SAS are you running? In my hands, I obtain the 35 events that you are expecting:<span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Screenshot 2023-08-08 161334.png" style="width: 539px;"><img src="https://communities.sas.com/t5/image/serverpage/image-id/86549i59D647A5931E1261/image-size/large?v=v2&px=999" role="button" title="Screenshot 2023-08-08 161334.png" alt="Screenshot 2023-08-08 161334.png" /></span></P>Tue, 08 Aug 2023 20:20:54 GMThttps://communities.sas.com/t5/Statistical-Procedures/Problems-performing-1-sided-group-sequential-design-in-proc/m-p/888469#M44003clayt852023-08-08T20:20:54ZRe: parameter estimation in systems of ordinary differential equations
https://communities.sas.com/t5/Statistical-Procedures/parameter-estimation-in-systems-of-ordinary-differential/m-p/799377#M39313
<P>I'd like to add a bit more perspective to the comments from <a href="https://communities.sas.com/t5/user/viewprofilepage/user-id/13684">@Rick_SAS</a> that I think might assist as you debug this program.</P>
<P>If you take the program as supplied by <a href="https://communities.sas.com/t5/user/viewprofilepage/user-id/13684">@Rick_SAS</a> but make the following modifications:</P>
<OL>
<LI>Remove the BOUNDS statement</LI>
<LI>Set the value of PMAX to 40 (as in the original code)</LI>
<LI>Set the value of CELLMAX to 60 (as in the original code)</LI>
</OL>
<P>Then you will receive exactly the same error ("Missing value encountered for intial dert.CELL at time = 0..." And so on.) I'm making an educated guess here (I do not know much about PROC MODEL) but I am quite certain this is the reason:</P>
<P> </P>
<P>As <a href="https://communities.sas.com/t5/user/viewprofilepage/user-id/13684">@Rick_SAS</a> notes, the values of CELL and P in the data exceed the values of the parameters CELLMAX and PMAX. In the most general case, this need not necessarily be a problem. (For example, a measured value might exceed a theoretical maximum because of random error during the measurement process.) BUT in your case this is almost certainly a problem.</P>
<P> </P>
<P>To see why, notice the structure of the derivative equations (for example, dert.CELL). The equation contains the term "(1 - P/Pmax)**n". If P>Pmax, then the term inside the parentheses is negative. This is OK when n=2 exactly (as you specify for the initial value of the parameter). But this is not defined when, say, n=2.1. This latter fact is the reason for the error. For a nonlinear least squares problem, the derivatives of the objective function with respect to the parameters (these are computed internally by PROC MODEL) must be well-defined in an open region. For your case, the derivatives are defined only at a point (n=0).</P>
<P> </P>
<P>Depending on the application, you might consider fixing the values of the parameters m and n.</P>Tue, 01 Mar 2022 16:36:34 GMThttps://communities.sas.com/t5/Statistical-Procedures/parameter-estimation-in-systems-of-ordinary-differential/m-p/799377#M39313clayt852022-03-01T16:36:34ZCausal Analysis Using SASĀ® Statistics Procedures
https://communities.sas.com/t5/SAS-Global-Forum-Proceedings/Causal-Analysis-Using-SAS-Statistics-Procedures/ta-p/741392
<DIV class="conf-presentation">
<DIV class="authors">
<DIV class="author-head" contenteditable="false">Presenter</DIV>
<P>Clay Thompson, SAS</P>
</DIV>
<H2 contenteditable="false">Abstract</H2>
<P>This talk overviews some recently developed SAS procedures that provide statistical tools for causal analysis, including causal effect estimation, causal mediation analysis and causal graph theory for establishing valid estimation strategies.</P>
<H2>Watch the presentation</H2>
<P>Watch <A href="https://youtu.be/JLbCXkGuvzc" target="_self">Causal Analysis Using SASĀ® Statistics Procedures</A> on the SAS Users YouTube channel.</P>
<P> </P>
<P><div class="video-embed-center video-embed"><iframe class="embedly-embed" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FJLbCXkGuvzc%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJLbCXkGuvzc&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FJLbCXkGuvzc%2Fhqdefault.jpg&key=b0d40caa4f094c68be7c29880b16f56e&type=text%2Fhtml&schema=youtube" width="600" height="337" scrolling="no" title="Causal Analysis Using SAS Statistics Procedures" frameborder="0" allow="autoplay; fullscreen; encrypted-media; picture-in-picture;" allowfullscreen="true"></iframe></div></P>
</DIV>Mon, 17 May 2021 21:30:57 GMThttps://communities.sas.com/t5/SAS-Global-Forum-Proceedings/Causal-Analysis-Using-SAS-Statistics-Procedures/ta-p/741392clayt852021-05-17T21:30:57Z