You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The changes I'm proposing in #172 do not expose a separate constructor for .stan files compared to .so files, but rather just branch on the extension of the file passed as the first argument.
So, in R, it would look like:
StanModel$new("foo_model.so", data="foo.data.json") # loads a model already compiledStanModel$new("bar.stan", data="bar.data.json") # compiles, *then* loads
In Python this looks different for the two cases:
StanModel("foo_model.so", data="foo.data.json") # loads a model already compiledStanModel.from_stan_file("bar.stan", data="bar.data.json") # compiles, *then* loads
In Julia it looks more like R, but is technically doing type dispatching rather than checking the .stan extension:
StanModel("foo_model.so", data="foo.data.json") # loads a model already compiledStanModel(stan_file="bar.stan", data="bar.data.json") # compiles, *then* loads
I think the real outlier here is Python, which deserves to be unified IMO. We can leave the existing function, but just update some logic in the constructor to handle .stan files. Whether Julia should also be updated or left using this disbatching I am less sure.
The text was updated successfully, but these errors were encountered:
Agreed, Python should be unified so that StanModel("bar.stan", data = "foo.data.json") works. This also means adding a keyword argument named data, since in Python StanModel(...) currently has a keyword argument named model_data, different from R and Julia (which both use data). I like data better.
In Julia, I think allowing StanModel("foo_model.stan", ...) would be a good thing.
These changes would take some care to ensure backward compatibility, ya?
The easiest way to ensure backwards compatibility is just leave the existing functions but re-direct their logic to the new suped-up constructor. Renaming a keyword argument in Python is a bit more annoying to do in a backwards-compatible way, but doable.
The changes I'm proposing in #172 do not expose a separate constructor for .stan files compared to .so files, but rather just branch on the extension of the file passed as the first argument.
So, in R, it would look like:
In Python this looks different for the two cases:
In Julia it looks more like R, but is technically doing type dispatching rather than checking the .stan extension:
I think the real outlier here is Python, which deserves to be unified IMO. We can leave the existing function, but just update some logic in the constructor to handle .stan files. Whether Julia should also be updated or left using this disbatching I am less sure.
The text was updated successfully, but these errors were encountered: