Changes to trace update interface methods

[marcoct]

Fix-update is an interesting type of trace update, that is intermediate between free update and force update. However, it's not clear that it is needed. Remove fix-update.

[marcoct]

Also make the trace the first argument of all the update methods

[marcoct]

Also, reorder the values in the return tuple of the force_update variant of update, so that the first three arguments are the same as the other update variants:

(new_trace, weight, retdiff, discard)

[marcoct]

Rename force_update to constrain_update, and rename free_update to select_update, and rename extend to extend_update. Having separate names for these (instead of relying on dispatch of one function update based on types of its arguments) can be helpful, especially if we want to port the GFI to other languages or interfaces that don't support the same type of overloading.

[alex-lew]

I like bringing the signatures into closer alignment (re: ordering of return values). I'm not sure select_update, constrain_update, etc. are the clearest names we can find. It sounds to me like I'm constraining an update, or selecting an update, when what I'm actually doing is updating.

Is there a reason to call them all update in the first place? In my mind, force_update is the most update-like, and deserves to be called update (or perhaps update_trace): you pass in new arguments and new choice values, and get back an updated trace.

Of the GFI methods, free_update seems closest to initialize (which we are renaming to generate_trace): it uses an internal proposal to regenerate some of the choices in the trace. Why not call it regenerate, or maybe regenerate_selection?

As for extend, I think its name is fine as it is (though perhaps it could be changed to extend_trace). It is a special version of update (currently force_update) that can be used when no existing choices need to change.

This would make the methods

generate_trace: generate a trace and a score from the internal proposal, subject to constraints

update_trace: change the arguments and choice values of a trace, automatically updating its score.

extend_trace: a special version of update_trace for when only new choices are being added.

regenerate: use the internal proposal to regenerate a selection of addresses from a trace, and to add any new randomness as required.

---

Another direction I can see the names going is automatic_update for free_update and manual_update for force_update. extend could be left as is.

[marcoct]

That's interesting---I had thought of 'regenerate' as jargon, but perhaps it's not bad jargon for this usage. Maybe `regenerate_trace`would be better to make it more similar to the other names. Or maybe remove `_trace` from all the names to make them consistent. Also note that `regenerate` can also accept a change to the arguments, in addition to the choice selection.

…

On Sun, Feb 3, 2019, 6:27 PM Alex Lew ***@***.*** wrote: I like bringing the signatures into closer alignment (re: ordering of return values). I'm not sure select_update, constrain_update, etc. are the clearest names we can find. It sounds to me like I'm constraining an update, or selecting an update, when what I'm actually doing is updating. Is there a reason to call them all update in the first place? In my mind, force_update is the most update-like, and deserves to be called update (or perhaps update_trace): you pass in new arguments and new choice values, and get back an updated trace. Of the GFI methods, free_update seems closest to initialize (which we are renaming to generate_trace): it uses an internal proposal to regenerate some of the choices in the trace. Why not call it regenerate, or maybe regenerate_selection? As for extend, I think its name is fine as it is (though perhaps it could be changed to extend_trace). It is a special version of update (currently force_update) that can be used when no existing choices need to change. This would make the methods generate_trace: generate a trace and a score from the internal proposal, subject to constraints update_trace: change the arguments and choice values of a trace, automatically updating its score. extend_trace: a special version of update_trace for when only new choices are being added. regenerate: use the internal proposal to regenerate a selection of addresses from a trace, and to add any new randomness as required. ------------------------------ Another direction I can see the names going is automatic_update for free_update and manual_update for force_update. extend could be left as is. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABihtL8Qx0OLCMJHCff6wUGTY4STZTttks5vJ3BggaJpZM4aafbV> .

[marcoct]

I am happy with: - `generate` - `update` - `regenerate` - `extend` On Sun, Feb 3, 2019, 10:47 PM Marco Cusumano-Towner <imarcoam@gmail.com wrote:

…

That's interesting---I had thought of 'regenerate' as jargon, but perhaps it's not bad jargon for this usage. Maybe `regenerate_trace`would be better to make it more similar to the other names. Or maybe remove `_trace` from all the names to make them consistent. Also note that `regenerate` can also accept a change to the arguments, in addition to the choice selection. On Sun, Feb 3, 2019, 6:27 PM Alex Lew ***@***.*** wrote: > I like bringing the signatures into closer alignment (re: ordering of > return values). I'm not sure select_update, constrain_update, etc. are > the clearest names we can find. It sounds to me like I'm constraining an > update, or selecting an update, when what I'm actually doing is updating. > > Is there a reason to call them all update in the first place? In my > mind, force_update is the most update-like, and deserves to be called > update (or perhaps update_trace): you pass in new arguments and new > choice values, and get back an updated trace. > > Of the GFI methods, free_update seems closest to initialize (which we > are renaming to generate_trace): it uses an internal proposal to > regenerate some of the choices in the trace. Why not call it regenerate, > or maybe regenerate_selection? > > As for extend, I think its name is fine as it is (though perhaps it > could be changed to extend_trace). It is a special version of update > (currently force_update) that can be used when no existing choices need > to change. > > This would make the methods > > generate_trace: generate a trace and a score from the internal proposal, > subject to constraints > > update_trace: change the arguments and choice values of a trace, > automatically updating its score. > > extend_trace: a special version of update_trace for when only new > choices are being added. > > regenerate: use the internal proposal to regenerate a selection of > addresses from a trace, and to add any new randomness as required. > ------------------------------ > > Another direction I can see the names going is automatic_update for > free_update and manual_update for force_update. extend could be left as > is. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#54 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABihtL8Qx0OLCMJHCff6wUGTY4STZTttks5vJ3BggaJpZM4aafbV> > . >

[fsaad]

Keep the _trace suffix, it adds clarity for probabilistic programming with first-class traces.

[marcoct]

These changes were made in probcomp/GenExperimental.jl#67