turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

Find a Community

- Home
- /
- Analytics
- /
- Stat Procs
- /
- Prevent proc glimmix from "Termination due to Flo...

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

09-11-2016 03:43 AM

Hello ,

when I run the following macro, I sometimes encounter the error "Termination due to Floating Point Exception".

%macro mult (dsin=,sc=);

ods output ParameterEstimates=pe_sc&sc. estimates=est_sc&sc.

proc glimmix data=&dsin method= laplace;

by study;

class response predictor patient;

model response= predictor/ dist=multinomial link=glogit s cl;

random predictor /sub=patient group=response G type= Chol;

nloptions maxiter=5000 tech=quanew;

parms / lowerb=1e-4,.,1e-4,1e-4,., 1e-4;

freq count;

estimate "Predictor=0" intercept 1 predictor 1 0 / cl ilink bycat;

estimate "Predictor=1" intercept 1 predictor 0 1 / cl ilink bycat;

run;

%mend mult;

The procedure converges for the respecitve cases, however, as one estimate for the predictor is 0, the estimate-statement causes the termination. Without "estimate "Predictor=0" intercept 1 predictor 1 0 / cl ilink bycat;estimate "Predictor=1" intercept 1 predictor 0 1 / cl ilink bycat;" , the procedure continues with the next by-group (=study) without any problems. Because I need the macro to go through every by-group, my question is: Is there any chance to add a condition in the macro that only executes the estimate statement if the estimates are non-zero and writes missing values into the ods estimates-table otherwise? If not, how could I catch the termination error as variable and continue with the next by-group?

Thanks in advance, M

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Posted in reply to Maya1

09-12-2016 01:34 PM

Would it make sense to replace the ESTIMATE statements with LSMESTIMATE statements?

Something like

LSMESTIMATE predictor 'Predictor=0' 1 0/ilink cl;

LSMESTIMATE predictor 'Predictor=1' 0 1/ilink cl;

Or move to LSMEANS, and use the ODDS and ODDSRATIO options.

Steve Denham

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Posted in reply to SteveDenham

09-13-2016 01:24 PM

Thank you for your time, Mr Denham. Unfortunately, least square means are not available for dist=mult in proc glimmix. So neither lsmeans nor lsmestimate works. Odds ratios are also not an option in my case. Is there any possibility to "catch" the estimate for the predictor if it is zero before the estimate-statement is executed? In which system variable could I possibly find this error and with which value?

Thanks again + regards,

M

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Posted in reply to Maya1

09-13-2016 08:26 PM

I can't think of any tricks to flag results within a glimmix run to decide whether or not to execute estimate statements within the *same* run. I can think of an alternative, but I don't have the time to write out the needed code. You would take out all your estimate statements, and put your results in an item store (using the STORE statement within glimmix). You would also save other results using ODS OUTPUT statements or the OUTPUT statement, such as the predicted values. In a DATA step, you would identify whether the prediction (or whatever) was 0 or not. If not 0, you would then run PROC PLM (with RESTORE statement to get results from glimmix), which would have the needed estimate statements. If prediction was 0, you could then execute a different PROC PLM with estimate statements that would work. The main programming work would be done within a DATA step.

I know this is just a general suggestion, but it allows you to selectively use estimate statements based on certain results from a model fit.