Just a quick addition to the correct answer from @Ksharp : the RETAIN statement, when used properly, allows you to carry data forward to the next row, and allows it to change when your rules require it to change (when PAY=2 do not carry the data forward). ... View more

So, @jitb , I would like to briefly summarize the responses so far. In order for you to have the best chance of getting good replies in the future, please keep these things in mind:   When you are having problems, we need a clear explanation of what you are trying to do. Do not assume that because you posted code that doesn't work, we know what you want. We also need to know you think the correct answer is, or at least the correct thing for the code to be doing. We need a portion of your SAS data set, or we need made up data as long as it illustrates the problem. Please follow these instructions and examples to provide the data. If there are errors in the log, please show us the LOG (start to finish) for the DATA step or PROC that you are having errors in. Do not show us tiny portions of the log.     ... View more

It would be extremely helpful if you showed us the ENTIRE log for this data step (not a small portion of the log).   Also, as far as I can tell, there is no need for %sysfunc here, yet you chose to use it even though no macro variables are present. As far as I can tell, there is no need for %str here, yet you chose to use it even though no macro variables are present. If payment_amount and term are data set variables, %sysfunc and %str cannot access the values of a data set variable. Therefore, %sysfunc sees text as the second argument of the REPEAT function. The text is    term-1   which is not a number, and not a reference to a data step variable, hence the error.   So if you remove %sysfunc and %str and their associated parentheses, this might work. ... View more

Go through the SAS Communities and read the original post in old threads (you can pick the New Users community if that is appropriate for you). Don't read the answers, just read the original post. Provide your own answers.    I think 2018 was a good year. ... View more

random intercept / subject=PRVDR_NUM(hrrnum) group=PAC_1 type=vc;   So here HRRNUM is nested within PRVDR_NUM. That's 2943 x 306 = 900,558 different combinations. I can understand why SAS is telling you this will take a very long time. Further, with 160,391 observations, the data will be very sparse in some of the combinations of HRRNUM and PRVDR_NUM; in other combinations of HRRNUM and PRVDR_NUM, there will not be any data. So, this is an overspecified model as well, you can't estimate everything. ... View more

It cannot be done in a reasonable amount of time. This probably is not a memory issue (otherwise the error message would specifically say memory), it is most likely a CPU issue.   How many levels are there in each of your CLASS variables? Can some of the levels be combined?   How many observations in data set data.model_df? ... View more

@Tom wrote:   Since in this case you are generating a data step anyway you can just use SAS for all of your calculations.  Which means you can just use a FORMAT to do the rounding of the values you write to the LOG.   This is an excellent point from @Tom . Rounding using a FORMAT is often superior to rounding using the ROUND function. Why? Because if these are intermediate calculations that will be used later in the program in a further analysis, rounding using the ROUND function can lead to incorrect answers in later steps that use that variable. Using the FORMAT does not truncate the value and so later steps still can use the entire collection of digits in the value, leading to correct answers.    Of course, I feel that too many people focus so tightly on the coding problem that they have a problem with, and don't explain how the answers will be used. This is a sub-optimal method, and can lead to sub-optimal answers. @dxiao2017 : We need to know the big picture, not just the coding problem you have. If we know the big picture, we won't give you answers that don't work in the big picture. If we know the big picture, we can also advise on better approaches and logic (which can be easier to program and a better method) to get you to your final result. This is called the XY-problem. Please read about the XY-problem (here and here).   Side issue: there are times when ROUNDing is the right thing to do, but without knowing the big picture, we can't even begin to advise you on this. ... View more

As it so often happens here in the SAS Communities, @Rick_SAS has written a blog post on how to compute these confidence intervals on the percentiles. https://blogs.sas.com/content/iml/2013/05/06/compute-confidence-intervals-for-percentiles-in-sas.html   You would have to merge these confidence intervals with the normal probability plot in order to get the plot you want. I believe PROC SGPLOT will allow you to draw these points and lines, after you merge the data sets. ... View more

I suppose you could create a macro that loops through all variables and does this PUT command. But even then there are problems, if the variable is numeric, you can't replace the original numeric value with a character value, you would have to create a new character variable (with a different name). If you have a character variable, then PUT would work but if the length of the formatted value is longer than the length of the unformatted value, the formatted value will get truncated. So, a somewhat complicated macro is needed that will handle these (and possibly other) situations.   You could do a similar thing with ARRAY.   May I ask why this is necessary? I have a feeling that if we knew why you want to do something like this, we might be able to figure out a better approach. ... View more

Basically, column position makes no difference to SAS. Anything you want to do in SAS works regardless of order of the columns in the data set (although there might be some rare exceptions).   The only time column position makes a difference is when you are creating an output that needs to be viewed by humans and then a logical order of columns is needed in the output, not in the SAS data set. So with that in mind, the columns positions can be easily specified in output PROCs, such as PRINT, TABULATE and REPORT. Since you asked for the "best way", I believe this to be the "best way".   Thus my advice is to not bother re-arranging the columns in a data set. Re-arranging the columns when you output the results is the time to do it.   ... View more

Why does removing the minus sign make the slightest bit of difference? Why would you do that? What is the benefit? ... View more

This is roundoff error. It happens when digital computers do math on numbers that are not integers and not 2 to the power of any negative integer. For any real-world purpose, you can treat these as exactly zero.   If you look in data set BDD, you can see for example, that cylinders (which is an integer in SASDATA.CARS) is not an integer and not 2 to the power of any negative integer.     ... View more

data want; set have; by transaction_id; retain flag; if first.transaction_id then flag=0; if yn='NO' then flag=1; if flag=1 then yn='NO'; drop flag; run;   The above code is untested. If you want tested code, you need to provide data as working SAS data step code (examples and instructions), and not as copy/paste from Excel or other program. Since you have more than 1 transaction in your real data, you need to provide us with data that has more than 1 transaction ID so we can test if the code works properly. ... View more