Open an existing model, data, or fit at launch - #1
Closed
mbthompson14 wants to merge 1 commit into
Closed
Conversation
Models specified in a script had to be rebuilt by hand in the interface, or
round-tripped through an .rds file, before the GUI could draw them. Accept them
directly instead:
ctgui_launch_app(model, data = mydata)
ctgui_launch_app(fit = myfit)
model, data and fit each also take a file path. A fit is unwrapped to the model
it was fitted with, so opening one gives the diagram, equations and diagnostics
together without refitting. With a model supplied the app opens on the visual
specification editor rather than the Data tab; with no arguments it starts empty
as before.
Most of this already existed: ctgui_create_app() took an initial_spec, and
ctgui_spec_from_model() backed the in-app model loader. The new work is
ctgui_launch_state(), which normalises the supplied objects into one initial
state and passes the specification through ctgui_commit_spec() so a scripted
model lands in the same canonical state an in-app load produces, plus seeding
the server's data and fit reactives from it.
Also fix a fidelity bug this exposed. ctModel() does not record the
tipredDefault it was called with, and ctgui_spec_from_model() hardcoded TRUE, so
importing a model built with tipredDefault = FALSE silently enabled TI
moderation on every free parameter. This affected the existing Load model RDS
button, not just the new path. Infer the flag from the per-parameter effect
columns in model$pars instead: TRUE only when every free parameter is moderated
by every TI predictor. The inference errs toward FALSE, which is safe because
per-parameter effects are reconstructed explicitly either way, and a ctModel to
GUI to ctModel round trip now returns an identical pars table for params,
indvarying and all TI effects.
ctgui_project_spec() accepts a fit as well, so the in-app RDS loader gains the
same handling.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Models specified in a script had to be rebuilt by hand in the interface, or round-tripped through an .rds file, before the GUI could draw them. Accept them directly instead:
model, data and fit each also take a file path. A fit is unwrapped to the model it was fitted with, so opening one gives the diagram, equations and diagnostics together without refitting. With a model supplied the app opens on the visual specification editor rather than the Data tab; with no arguments it starts empty as before.
Most of this already existed: ctgui_create_app() took an initial_spec, and ctgui_spec_from_model() backed the in-app model loader. The new work is ctgui_launch_state(), which normalises the supplied objects into one initial state and passes the specification through ctgui_commit_spec() so a scripted model lands in the same canonical state an in-app load produces, plus seeding the server's data and fit reactives from it.
Also fix a fidelity bug this exposed. ctModel() does not record the tipredDefault it was called with, and ctgui_spec_from_model() hardcoded TRUE, so importing a model built with tipredDefault = FALSE silently enabled TI moderation on every free parameter. This affected the existing Load model RDS button, not just the new path. Infer the flag from the per-parameter effect columns in model$pars instead: TRUE only when every free parameter is moderated by every TI predictor. The inference errs toward FALSE, which is safe because per-parameter effects are reconstructed explicitly either way, and a ctModel to GUI to ctModel round trip now returns an identical pars table for params, indvarying and all TI effects.
ctgui_project_spec() accepts a fit as well, so the in-app RDS loader gains the same handling.