Feature request: `sp_diag` should find arguments in `geostan_fit`
wcjochem opened this issue · comments
I've enjoyed using your package during my JOSS review and this isn't really part of the review for the journal. But I was wondering if there would ever be a time when I (or other users) would want to use sp_diag.geostan_fit with the spatial object, the style and/or A arguments that don't match what was used to fit the model?
If not, would it be possible to change the default behaviour in to get those arguments from the geostan_fit object itself? That would require passing information from the car_parts argument on to the fitted object. Although I could imagine a case with a large connectivity matrix and large spatial object that you might not want to store with the fitted object (so perhaps flag in stan_car to turn off the storage?).
That's awesome, thanks for providing a thoughtful review of the software!
Often times I think that the same spatial connectivity matrix is going to be used, so it makes sense, as your suggesting, to store that matrix in the fitted model object (in sparse matrix format) and avoid another call to shape2mat. Storing the spatial object itself would be too much, I think, and its currently not passed in to the modeling functions. Your welcome to make a pull request with that change, if you're interested. If not I can probably get to it over the coming two weeks.
There are some reasons for looking at different specifications of that same matrix (the style argument), such as examining both row-standardized and binary versions. (One will produce a Moran plot with the mean spatial lag, the other will show the sum of neighboring values, and they sometimes differ.) But I don't imagine most users will be concerned with those small differences.
The CAR models are actually an exception, at least when the "ACAR" model is used. The more common "WCAR" model has the row-standardized spatial weight matrix in it, but the ACAR model uses a less familiar matrix specification. So in that case one would probably want to examine residual auto-correlation using the familiar row-standardized version of the matrix (which would require using the A argument).
Thanks for the reply. Your reasoning for the current set-up makes sense to me. I'll consider working on a pull request if I get a chance, but it doesn't seem urgent and everything is working well now.
Thanks again for the suggestion and peer review. Just released v0.4.1 with a fix to this issue.