About RyanSimmons

RyanSimmons · ‎09-04-2020

Thanks! I knew the solution would be really simple!

RyanSimmons · ‎09-04-2020

I am a bit stuck on how to automate this programming issue. I am trying to write a macro to perform this but can't seem to figure out a clean way of doing it so it is generalizable. The input to this macro is going to be a numeric dataset with ~30-50 observations and anywhere from 2 to 10 variables. This dataset will be structure like this: DATA input; do Item = 1 to 30; Score1 = rand('uniform'); Score2 = rand('uniform'); Score3 = rand('uniform'); output; end; run; But the exact numbers will vary for each such input dataset. What I need to do is evaluate for each Item (i.e. row) whether or not the set of Scores (columns) meets a condition. The condition is: exactly one of the Scores is >= 0.6 and each other score is <=0.4. Now, for the example dataset, this can be coded pretty easily using something like: DATA output; set input; if Score1 >= 0.6 & Score2 <= 0.4 & Score3 <= 0.4 then condition = 1; else if Score1 <= 0.4 & Score2 >=0.6 & Score3 <= 0.4 then condition = 1; else if Score1 <= 0.4 & Score2 <= 0.4 & Score3 >=0.6 then condition = 1; else condition = 0; run; The problem of course is that this isn't easily generalizable, this only works if there are exactly 3 variables. How would I automate/generalize this logic in a macro? I'm pretty stuck, I don't really know what to do. I'm guessing there is a way to do this with arrays but I can't quite figure out how to implement that.

RyanSimmons · ‎06-26-2019

It seems that offsetmin and offsetmax can be used to get rid of this white space: PROC SGPLOT data=figure1 noautolegend; scatter x = t y = marker / markerattrs=(color=black); series x = t y = planned / lineattrs=(color=black pattern=1); series x = t y = current / lineattrs=(color=black pattern=2); series x = t y = CP_current / lineattrs=(color=black pattern=1) curvelabel="CP=&Current_CP." curvelabelloc=outside; series x = t y = CP_planned / lineattrs=(color=black pattern=1) curvelabel="CP=&Planned_CP." curvelabelloc=outside; text x = t y = laby1 text = label1; text x = t y = laby2 text = label2; yaxis label = "B(t)"; xaxis label = "t" values=(0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0) offsetmin=0 offsetmax=0; run; However, this seems a little clunky (e.g. if I have curvelabelloc=inside, using offsetmax will cut off the curve label instead of displaying it). And even with this workaround I would still like to better understand exactly WHY the text option is causing the axis to be rescaled the way it is.

RyanSimmons · ‎06-26-2019

Below, I have some code that produces some data and generates a plot: %let Planned_E_Bt = 1.81; %let Current_E_Bt = 0.82; /* Generate lines */ DATA figure1; do t = 0 to 1 by 0.01; planned = &Planned_E_Bt*t; current = &Current_E_Bt*t; if t >= 0.5 then do; CP_current = current; CP_planned = &Current_E_Bt*0.5 + &Planned_E_Bt*(t-0.5); current = .; end; output; end; run; /* Generate markers and labels */ DATA figure1; set figure1; if round(t,0.001)=0.5 then do; marker = CP_current; laby1 = marker - 0.1; label1 = "B(t=0.5)=" || strip(round(marker,0.001)); end; if round(t,0.001)=0.4 then do; laby2 = planned + 0.2; label2= "E{B(t)}=" || strip(round(&Planned_E_Bt,0.01)) || "t"; end; run; PROC SGPLOT data=figure1 noautolegend; scatter x = t y = marker / markerattrs=(color=black); series x = t y = planned / lineattrs=(color=black pattern=1); series x = t y = current / lineattrs=(color=black pattern=2); series x = t y = CP_current / lineattrs=(color=black pattern=1) curvelabel="CP=0.04" curvelabelloc=outside; series x = t y = CP_planned / lineattrs=(color=black pattern=1) curvelabel="CP=0.41" curvelabelloc=outside; yaxis label = "B(t)"; xaxis label = "t" values=(0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0); run; This all works as intended. However, I am trying to add some labels as text to the plot. As soon as I add them (see modified SGPLOT code chunk below), it changes the x-axis. It adds white space at either end of the axis (<0 and >1). PROC SGPLOT data=figure1 noautolegend; scatter x = t y = marker / markerattrs=(color=black); series x = t y = planned / lineattrs=(color=black pattern=1); series x = t y = current / lineattrs=(color=black pattern=2); series x = t y = CP_current / lineattrs=(color=black pattern=1) curvelabel="CP=&Current_CP." curvelabelloc=outside; series x = t y = CP_planned / lineattrs=(color=black pattern=1) curvelabel="CP=&Planned_CP." curvelabelloc=outside; text x = t y = laby1 text = label1; text x = t y = laby2 text = label2; yaxis label = "B(t)"; xaxis label = "t" values=(0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0); run; How do I stop it from adding this blank space at either end? I can't figure out how to force it to not rescale the axis. Curvelabel doesn't work, because that will only let me add the labels to the beginning or end of the line instead of the middle. I've tried Datalabel, but that also adds this blank space at either end.

RyanSimmons · ‎06-25-2019

Thanks for the suggestion. Unfortunately, I get the same error message: rc=10005 msg=ERROR: Open failure for Z:\CRU\Pediatrics\Active Projects\CoBIS II\raw data\CoBISII-InterimAna lysis20190618.zip during attempt to create a local file handle. 10005 is the error code returned by FCOPY; not sure if there is any meaning to be gleaned from that. I do see that the documentation for FILENAME's ZIP access method states, "The ZIP access method reads and writes only files created with the WinZip file compression." I'm not sure how this .zip file was created, but I'm wondering if the issue was that it wasn't using WinZip.

RyanSimmons · ‎06-25-2019

I'm fairly certain that quotes there are not needed. There are plenty of examples online that don't use the quotes and seem to work. Further, if I use the quotes with my example, I get the same exact error message, it doesn't change the behavior at all.

RyanSimmons · ‎06-24-2019

I am having difficulty trying to open a zipped SAS dataset. There seem to be very few examples of this that I can find online, and none of them offer a clue as to how to solve my problem. If I run the following code, I can see that SAS is successfully recognizing the zip file and its contents (I edited out the path for anonymity, but "path" in the below is a valid path to an existing directory on the machine): filename inzip ZIP "path\CoBISII-InterimAnalysis20190618.zip"; DATA contents(keep=memname); length memname $200; fid=dopen("inzip"); if fid=0 then stop; memcount=dnum(fid); do i=1 to memcount; memname=dread(fid,i); output; end; rc=dclose(fid); run; PROC PRINT data=contents noobs N; run; This produces the following output: memname mrsdata.sas7bdat Readme.xlsx N = 2 I want to read the SAS dataset (mrsdata) into SAS. I tried following the example here and used the following code: filename wc "%sysfunc(getoption(work))/mrsdata.sas7bdat"; DATA _null_; infile inzip(mrsdata.sas7bdat) lrecl=256 recfm=F length=length eof=eof unbuf; file wc lrecl=256 recfm=N; input; put _infile_ $varying256. length; return; eof: stop; run; PROC CONTENTS data=WORK.mrsdata; run; However, this produces the following error (again, I am editing out the path for anonymity's sake): ERROR: Open failure for path\CoBISII-InterimAnalysis20190618.zip during attempt to create a local file handle. NOTE: UNBUFFERED is the default with RECFM=N. NOTE: The file WC is: Filename=C:\tmp\wc.dat, RECFM=N,LRECL=256,File Size (bytes)=0, Last Modified=24Jun2019:14:39:38, Create Time=24Jun2019:14:39:38 I am at a complete loss as to how to proceed.

RyanSimmons · ‎05-02-2019

Interesting! Clever idea. Looks like this is essentially the same logic as my "clunky solution 2", but operationalized better. I'll leave this question open for a little while longer to see if anybody else comes up with something clever, otherwise I think this will be the answer!

RyanSimmons · ‎05-02-2019

Unfortunately I'm not well-versed in many programming languages, so I can't say for sure. I thought that the "lubridate" package in R had that functionality, but I may be mistaken. I know too that some R functions for fitting longitudinal or time series models (for example, the temporal smoothers in the "mgcv" package) have ways of taking the "wrapping around" of time or date variables into account, but the application is different. On one hand, it makes sense why this is limitation exists, since the typical programming solution is to encode times as the number of seconds relative to some benchmark (e.g. midnight). On the other hand, it's a very simple mathematical operation, so it would surprise me if there were NO solutions to this. Even something as simple as having an option to the "intck" function that says "crossdays=TRUE" or something to that effect. Anyway, thank you for your response! It looks like I am just going to have to code something clunky (unfortunately I don't have date variables for both days, I only have date variables for the first day, and some people went to sleep past midnight, so I am going to have to do an if/then loop or two to make the calculations work for everyone).

RyanSimmons · ‎05-02-2019

I have a dataset full of times, indicating when an individual went to bed at night and when they woke up the next morning. I want to create a new variable that indicates the number of hours that they were asleep. However, SAS doesn't seem to understand how clocks work, and is unable to "wrap" times around the clock to do the calculation in a sensible way. For example, if someone went to bed at 9pm and woke up at 5am, we would WANT the value of hours slept to be 8. However, SAS will return +/- 16, since it is only able to calculate the difference in a linear fashion. There are a couple of workarounds to this (included in my code snippet below), but they feel very clunky to me. One of them is pulling in the date variables and using the dhms function and then converting the result into hours, the other is converting the bedtime variable into the # of hours before midnight and then adding that to the wake up time variable. Here's an example: DATA time; /* Bed time and wakey time */ bed_time = 75600; format bed_time time8.; wake_time = 18000; format wake_time time8.; /* Wrong answer */ wrong_hours_slept = intck('hour',bed_time,wake_time); /* Clunky solution 1 */ day1 = today(); format day1 date8.; day2 = intnx('day',day1,1); format day2 date8.; seconds_slept = dhms(day2,0,0,wake_time) - dhms(day1,0,0,bed_time); right_hours_slept1 = seconds_slept/3600; /* Clunky solution 2 */ hours_before_midnight = (86400 - bed_time)/3600; right_hours_slept2 = hours_before_midnight + wake_time/3600; run; Are there any other solutions? Obviously both of the above work, and ultimately don't require too much extra coding, but it feels rather frustrating to me that SAS doesn't have a built-in way of manipulating clock time. Further, both of these clunky solutions also have points of failure (notably with people who go to sleep after midnight), requiring some if/then logic to correct.

RyanSimmons · ‎05-31-2018

I appreciate the response. I know that those procedures offer a lot of style functionality. In fact, in the REAL program that inspired this question (which is a lot more complex than the simple example in my OP), I have multiple PROC REPORT calls that each have a variety of different and customized style options that I configure the way you show. The problem is that I am also outputting the tables from these calls to different ODS destinations (e.g. ODS RTF and ODS PDF), and the same program also relies on multiple calls to ODS GRAPHICS, ODS LISTING, ODS HTML, etc. Most of these ODS output options cannot be defined within procedures, due to the need to output them from the SAS environment.

RyanSimmons · ‎05-31-2018

I understand that there are other ways other than PROC LUA to get the effect with regular SAS system options. I only posted the PROC PRINT as a simple replicable example, because my real example is more complicated with a more elaborate bit of code embedded in PROC LUA, and with a variety of different options that I am switching on and off at multiple points through the program. The reason I brought up PROC LUA is specifically because the way in which PROC LUA defines these options locally, without having to manually reset them for the second PROC PRINT call as in your example. That's the point; in a long, complicated SAS program it can be cumbersome to have to keep switching global options on and off, especially if it is an organic program that is consistently being modified and updated (potentially by different coders). Defining such options locally is less cumbersome and reduces the chance of error. PROC LUA allows you to do this (and it has some other nice functionality as well), but only for SAS options. There are other ways you can achieve the same de facto behavior; for example, using %include on a list of separate SAS programs that run under different option configurations and then resetting those options at the end of each program. However, there are advantages to the PROC LUA approach. My question is specifically whether there is a way to get similar behavior (not necessarily in PROC LUA, but through other means) with ODS options, without having to clumsily reset the options as you do in your example. For example, one could do the %include example I mentioned above, but this has a disadvantage in that for suitably complicated projects you end up splitting a single SAS program into dozens of separate programs, which has some downsides. I was curious whether anyone knew of a clever way to get SAS to define ODS options in a local manner. I am grateful for the ODS _ALL_ CLOSE, however, I wasn't aware of that functionality. That can simplify the problem a bit. If you close all ODS destinations, and reopen them, are the settings for each ODS destination reset to their defaults? I still see this as a bit clumsier than some way of defining ODS options in a completely local manner, but it's an improvement over calling each ODS destination separately.

RyanSimmons · ‎05-30-2018

It is possible to use PROC LUA to define SAS options "locally"; the options defined will not be inherited by the rest of the program. That is, you can set SAS options within a PROC LUA, run a SAS program that operates under those options, then run further SAS code outside of PROC LUA without having to reset the options. For example: PROC LUA; submit; sas.submit[[ options obs=1; PROC PRINT data=SASHELP.HEART; run; ]] endsubmit; run; PROC PRINT data=SASHELP.HEART; run; The first PROC PRINT is run using the SAS option obs=1; i.e. it only prints the first observation of the dataset. You can see that the second PROC PRINT call, which is outside of the PROC LUA submit block, will print the entire dataset without having to specifically reset the obs option. Now, this example is a bit contrived, but the same logic can be usefully extended to more complicated scenarios, when you may want to set a number of SAS options to a particular setting for the purposes of a specific chunk of code, without having to worry about accidentally leaving that option activated for later chunks of code for which it is no longer needed. My question is: is there any way in SAS to similarly define ODS options "locally", e.g. for a specific call to PROC SGPLOT, without those options being inherited later in the program? Note that PROC LUA will not work for this: PROC LUA; submit; sas.submit[[ ods html close; PROC PRINT data=SASHELP.HEART; run; ]] endsubmit; run; PROC PRINT data=SASHELP.HEART; run; The ODS HTML CLOSE call is still 'active' for the rest of the program. It is still a global option, unlike the standard SAS options when called within PROC LUA. Is there any other workaround? I have never seen a solution for ODS options other than to manally reset the options. ODS GRAPHICS has a RESET=ALL option that will automatically clear all ODS GRAPHICS calls, but to my knowledge there is no similar functionality for ALL ODS options. That is, ODS GRAPHICS RESET=ALL has no impact on ODS HTML, ODS LISTING, or other ODS destination options. And it can be tedious in a program designed to generate a variety of different output types to have to keep resetting options and carefully monitoring which options are active and for what reasons.

RyanSimmons · ‎05-17-2017

Depending on the exact type of inference you are interested in, you can account for such clustering in a number of ways. The two simplest ways are probably in GENMOD or GLIMMIX (though, depending on the details of the analysis you can also use PROC SURVEYLOGISTIC or even PROC PHREG, or reparameterize your data to use a conditional maximum likelihood approach in PROC LOGISTIC. But these are less intuitive and more complicated approaches, I think). For example, you can fit a generalized estimating equation (GEE): PROC GENMOD data=dataset; class indexar (ref='2010') koen (ref='K') / param = ref ; model laek(EVENT='1') = pv indexar alder arv koen; repeated subject=patient_id/ type=un; run; You can fit just fit a normal logistic model but with the empirical ("sandwich") variance estimators: PROC GLIMMIX data=dataset empirical; class indexvar koen; model laek(event='1') = pv indexar alder arv koen; run; You can fit a mixed effects model: PROC GLIMMIX data=dataset; class indexvar koen; model laek(event='1') = pv indexar alder arv koen; random intercept / subject=patient_id; run; For both the RANDOM statement in GLIMMIX and the REPEATED statement in GENMOD, you can also specify a hierarchical (nested) structure (e.g. "random intercept / subject=patient_id(clinic_id)" for patients nested within clinics), though I would consult this note (http://support.sas.com/kb/24/200.html) and/or this document (https://support.sas.com/resources/papers/proceedings14/SAS026-2014.pdf) to make sure you understand exactly what it is you are specifying and how to interpret it.

RyanSimmons · ‎05-17-2017

That actually is what I have been using for now. The main reason I am hesitant to use this going forward is that in the future we may actually be interested in differentiating between "negative" and "positive" results (not so much for large effect sizes, but for small or null effect sizes, we may be interested in situations where, due to random sampling variability, a test statistic indicates a "negative" effect, since the context of our simulation is in group sequential analyses with different types of stopping rules).