In order to fix https://github.com/stan-dev/stan/issues/1943, I would like to change the behavior of generated quantities so that rather than crashing when there’s an exception, it catches the exception , writes an error message, and then streams out NaN for all the values after the error.
As is, the crashes in generated quantities do not allow sampling to continue. They should allow sampling to continue as they’re only generated conditional on the samples anyway.
On the down side, once you start generating NaN values under error conditions, how will you ever use those values?
Any opinions?
(I wasn’t sure what tag to use for this, so I left it empty.)
1 Like
Current behavior is a source of frustration for people working on difficult models so I can see the logic. I tried to come up with good justifications for making the change and the only one I can think of is functional models that rarely produce extreme parameter values in RNG’s. Shouldn’t our RNG’s be safe in the sense that they return some max value rather than crash?
I’ve been frustrated by the current behavior myself but it’s usually when I’m doing something dumb.
They don’t crash, they throw exceptions when they get arguments out of range. Same for indexing into an array. If I declare
real a[4];
a[10] = 6;
the question is how to be safe. I’m suggesting when that arises or when we get illegal arguments to RNG or other functions, we catch the exception that gets thrown and just dump out a bunch of NaN values for any variable not already set.
That’s on a per-iteration basis right? An RNG could produce a non-representable value on one iteration and a representable value on the next? You were making it sound like once an error is caught all the following iterations are shot.
The indexing example… seems like that should throw and terminate the program. Do these have to have the same behavior for some reason?
I’m proposing one iteration at a time. What happens now is that it just stops sampling or optimization altogether.
@syclik s trying to split out the indexing errors to treat differently. Are there other errors that should be treated separately?
Right now, errors that can be handled are std::domain_error. Those are any of the checks that are recoverable like NaN elements, vilolating constraints.
Other exceptions should stop including std::out_of_range or std::illegal_argument. Those happen when indexes are wrong (programming error that aren’t really recoverable).
So should I catch std::domain_error and let the rest propagate? I’ve always been confused about the differnence between illegal_argument and domain_error, as the latter just seems like a particular kind of the former.