Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider changing how update and regenerate handle default arguments. #538

Open
ztangent opened this issue Jul 9, 2024 · 2 comments
Open

Comments

@ztangent
Copy link
Member

ztangent commented Jul 9, 2024

When I first introduced support for optional trailing arguments in the Gen dynamic modeling language (see #195), the way I added this functionality to update and regenerate was to assume that default argument vaues would always override the arguments specified in the previous trace that update or regenerate was applied to.

This behavior was easier to implement, but now that I think about it, quite unnatural: Usually, if you're running a MCMC or SMC algorithm on a trace, you want to keep any optional trailing arguments fixed, rather than having to repeatedly specify their values.

As such, I'm proposing that for any optional trailing arguments that are not explicitly specified in a call to update or regenerate, update or regenerate should keep the argument values stored in the previous trace. This would not be hard to implement. It would be a breaking change, but I don't think tons of code relies on the current default behavior because of how unnatural it is.

@femtomc
Copy link
Contributor

femtomc commented Jul 10, 2024

This makes a lot of sense -- is it fair to think of unspecified default values as implicitly converted to NoChange argdiffs? There's a more general change where positional arguments are optional as well for update and regenerate (anything not specified is cast to NoChange from the previous trace's arguments).

@ztangent
Copy link
Member Author

Interesting, thanks! I think we could make that part of the spec for update, but it may be hard to support across implementations of the GFI?

Alternatively, we could add a new generic implementation of update and regenerate that checks whether the number of newly supplied arguments is equal to the number of previous arguments, then pads the new arguments with the previous arguments as necessary. But has to be done dynamically, since there's no easy way to check the type of the arguments contained in the previous trace. (It'll also require specific implementations of update to have a different name than update, so that the generic implementation of update can call update_impl under the hood.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants