It looks like you have a discrete scale of colors. If so, use the KEYLEGEND statement in PROC SGPLOT. If you have a continuous color ramp, use the GRADLEGEND statement. For an example, see Create a wind chill chart in SAS - The DO Loop ... View more

In practice, the subterfuge would be recognized the first time that a hand appears that shows two Ace of clubs. This will happen frequently, at which point you are 100% sure that the deck is altered.   In terms of the simulation, your situation is equivalent to using a deck of 52 numbers that look like this: {1,1,2,3,4,6,7,8,...,52}, where '1'=AC and '5'=2C.     If you want to stick with your original problem, which estimates frequencies, I suggest you start with a smaller deck for which the simulation will run faster and for which the probabilities are larger. For example, start with a deck of 8 cards (Aces and Twos) that look like {1,1,2,3,4,6,7,8}. Figure out the answer to your problem with this smaller deck. When you can solve the problem with a deck that has 8 cards, test your knowledge by moving to a deck that has 12 cards. Then try 16. Then you will be ready for 52.   It sounds like your problem is related to using simulation to estimate "power and sample size."  See these articles: What sample size do you need for a binomial test of proportions? - The DO Loop Sample size for the Monte Carlo estimate of an integral - The DO Loop Use simulation to estimate the power of a statistical test - The DO Loop     ... View more

The new thread is at https://communities.sas.com/t5/SAS-Forecasting-and-Econometrics/How-to-simulate-diffusion-process-with-certain-line-pattern/m-p/977694  ... View more

Run exactly the code I sent you and report your log. ... View more

OPTIONS NONOTES; should turn off all notes. Here is an example from the documentation, along with the SAS log. You can see that there are no notes associated with the optimization in the log:   proc iml; start F_ROSEN(x); y1 = 10 * (x[2] - x[1] * x[1]); y2 = 1 - x[1]; f = 0.5 * (y1 * y1 + y2 * y2); return(f); finish F_ROSEN; x = {-1.2 1}; opt = {0 2 . 2}; option nonotes; do i = 1 to 10; call nlpqn(rc, xr, "F_ROSEN", x, opt); end; options notes; quit; 8985 proc iml; NOTE: IML Ready 8986 start F_ROSEN(x); 8987 y1 = 10 * (x[2] - x[1] * x[1]); 8988 y2 = 1 - x[1]; 8989 f = 0.5 * (y1 * y1 + y2 * y2); 8990 return(f); 8991 finish F_ROSEN; NOTE: Module F_ROSEN defined. 8992 x = {-1.2 1}; 8993 opt = {0 2 . 2}; 8994 8995 option nonotes; 8996 do i = 1 to 10; 8997 call nlpqn(rc, xr, "F_ROSEN", x, opt); 8998 end; 8999 options notes; 9000 quit; NOTE: Exiting IML. NOTE: PROCEDURE IML used (Total process time): real time 0.10 seconds cpu time 0.06 seconds If you are seeing something different, then please provide a sample log (for a small number of simulations) and the details about how you are submitting SAS: EG? SAS Studio? ODA? Batch? etc ... View more

This is a cumulative logit model. When combined with the spline effects, I think it will be hard to obtain an analytical expression for the derivative of the predicted responses. It's much easier to use a numerical approximation. I propose:   Create scoring data that uses small steps between points in the independent variable (HEIGHT). Use the DIF function to form the finite-difference derivatives.  See also the article, "Compute derivatives for nonparametric regression models." Here is the code that creates the scoring data and that visualizes the predicted responses. You can use the links I've provided to obtain the finite-difference derivatives at any (sex, height) combination.   proc means data=sashelp.class; class sex; var height; run; data scoreData; sex='F'; do height = 51.4 to 66.5 by 0.1; output; end; sex = 'M'; do height = 57.5 to 72 by 0.1; output; end; run; proc logistic data=sashelp.class; class sex(ref="F")/param=ref; effect htS=spline(height/ degree=1 knotmethod=percentilelist(25,75)); model age=htS sex htS*sex; score data=scoreData out=ScoreWide; run; title "Visualize the Cumulative Logit Model"; proc sgpanel data=ScoreWide; panelby sex; series x=height y=P_11; series x=height y=P_12; series x=height y=P_13; series x=height y=P_14; series x=height y=P_15; series x=height y=P_16; run;   ... View more

Is there anything else we can help you with? If not, please accept a solution and close this thread. ... View more

No. PROC REG assumes that the dependent variable (the response) is continuous. If your dependent variable is binary, you should probably switch to using PROC LOGISTIC, which (by default) models the probability that a response is 0. ... View more

I read the documentation. I think it says the following: The procedure fits a cubic spline to the data and evaluates the spline for every day. If you use the option observed=(beginning), that is equivalent to using observed=(beginning,beginning).  That means that the output value is the value of the cubic spline on the first day of each month: 01JAN, 01FEB, 01MAR, etc. If you use the option  observed=(beginning,average), the output value is the AVERAGE of the values in the month. Thus the output for January is the average of the cubic spline in January, the output for February is the average of the cubic spline in February, etc. Here is the graph of the cubic interpolation function (which I got by setting TO=DAY and PLOTS=(ALL)). See if this helps you make sense of the outputs in both cases:   ... View more

PROC REG does not support a CLASS statement, so there is no default reference level.  When using PROC REG, you have to create the dummy variables yourself.   Let's use the example of creating a dummy variable for a two-level variable such as GENDER. Your reference level is always the lowest level, which is 0 if you construct a 0/1 binary variable.  For example, if you define sex = (Gender='M'); then the '0' level corresponds to females.  However, if you define  sex = (Gender='F'); then the '0' level corresponds to males.    That is why I recommend including the reference level in the variable name, such as  isMale = (Gender='M');       ... View more

If your question is answered, please close this thread. If you have additional questions, please let us know how we can help. ... View more

I feel confident that you can use the best practices in the links to improve your program. Since I don't have your data, it is difficult for me (or anyone) to know whether our suggestions fix all of the problems you are experiencing. Give it a try and then report back if you have additional questions.  ... View more

I don't want to hijack this thread, but I'd like to encourage SAS Experts like @Kathryn_SAS and @Quentin to stop proposing  ODS _ALL_ CLOSE; or  ODS LISTING CLOSE; in their solutions.  The modern syntax for suppressing ODS results is ODS EXCLUDE ALL; followed by ODS EXCLUDE NONE or ODS SELECT <object> when you are ready to resume output. For more details, see  What is the best way to suppress ODS output in SAS? Five reasons to use ODS EXCLUDE to suppress SAS output ... View more