"write_params_to_json"

[MattHJensen]

I can see two major uses for a "write_params_to_json" method that would create a json params file from the param attributes on the calculator.

1. We could allow webapp users to download the json for use on their local version of taxcalc. This could be useful in many situations, including if we wanted to be able to run a tax plan that was created through the webapp on a local machine, without drop-q.
2. One of the reasons why we use user_modes to create a plan y calculator in our 10_min notebook, rather than loading a planY.json params file, is that it would be a pain to maintain an example planY.json params file. Everytime we add or change a parameter to the taxcalc package, we would have to remember to duplicate that modification in both params.json and the new planY.json. With write_params_to_json, we could have a little script that loads a calculator with params.json and a user_mod (params repeal state and local tax) and then calls write_params_to_json in order to create planY.json.

A note on implementation: we would probably want "write_params_to_json" to build off of the default params.json rather than writing the notebook from scratch.

@talumbau, what do you think about this?

[talumbau]

very much 👍 on this. I don't know how useful the downloading of inputs as CSV is write now on the webapp. It is sufficient for reproducibility, but not particularly user friendly. This would be more user friendly.

[zrisher]

And much easier to maintain!

[MattHJensen]

I think this would excuse us from needing to display and maintain "inputs used" at the bottom of the results page. Rather, we can offer for download both planX.json and planY.json, and then only display the parameters changed (user_mods).

As an aside, we may also want a `write_user_mods' function.

1. this would help with displaying "parameters changed" on the webapp (see above).
2. I am not sure about this yet, but I think it might be easier to maintain forward compatibility with user_mods rather than with planY_params.json. (My thinking is that a user_mods structure generated from calc v1 would not work with calc v2 if the user_mod variables had been renamed or otherwise modified between v1 and v2 or if the user_mod api itself is changed. A planY.json generated from v1 would not work with v2 if any variable had been renamed or otherwise modified between v1 and v2 or if the json structure itself had been changed.)

[feenberg]

On Fri, 12 Jun 2015, Matt Jensen wrote:

I think this would excuse us from needing to display and maintain "inputs
used" at the bottom of the results page. Rather, we can offer for download
both planX.json and planY.json, and then only display the parameters changed
(user_mods).

My thought was PlanX would be existing law, and we would show in the
output file any difference between existing law and PlanY. By keeping the
description of the changes together with the output, confusion is reduced.
If we provide PlanX parameters, that would be a lot of data, and would
bury the differences between PlanX and PlanY. Or perhaps only the
difference between existing law and PlanX would be shown? If we maintain
PlanX to be existing law, and the user wants two plans, can't they just
run the model twice?

As an aside, we may also want a `write_user_mods' function.

1. this would help with displaying "parameters changed" on the webapp (see
   above).
2. I am not sure about this yet, but I think it might be easier to maintain
   forward compatibility with user_mods rather than with planY_params.json.
   (My thinking is that a user_mods structure generated from calc v1 would
   not work with calc v2 if the user_mod variables had been renamed or
   otherwise modified between v1 and v2 or if the user_mod api itself is
   changed. A planY.json generated from v1 would not work with v2 if any
   variable had been renamed or otherwise modified between v1 and v2 or if
   the json structure itself had been changed.)

If we find it necessary to rename a variable, we could incorporate code to
recognize either name. But I hope we won't have to rename variables. If we
add structure, we can probably arrange for suitable defaults, so that
earlier plans will still run. Probably we can avoid changing
structure.

dan

—
Reply to this email directly or view it on
GitHub.[AHvQVWRI21bSAKgrHE-1YwZLUz-yB-J5ks5oSxFWgaJpZM4E-1QA.gif]

[MattHJensen]

Definitely in agreement:

1. plan x should be current law.
2. we should couple a description of differences between between plan x and plan y with the output.
   1. When we get there, we should also couple to the output any differences between the default data extrapolation and the user-supplied data extrapolation (which would affect both plan x and plan y, and which would not be captured in a set of differences between the two.)

The option to download a plan X json file, plan Y json file, and a computer-readable set of differences between plan X and plan Y would provide an interested user more information about their plan and existing law and help a user with data access to replicate their webapp run on their own machine.

[MattHJensen]

@PeterDSteinberg this discussion will likely be helpful as well: #343 (diff)

[martinholmer]

Tax-Calculator issue #284 (from September 2015) is still open even though pull request #356, which was apparently an attempt to resolve #284, was closed in September 2015 without merging. Is there any reason to keep issue #284 open given that there has been no discussion of it over the past 17 months?

@MattHJensen @PeterDSteinberg @feenberg @zrisher

[talumbau]

It would seem to me that use case #1 from Matt's original post is still an unresolved use case but there is already at least one issue on the webapp repo to discuss that. Use case #2 seems to have not been as important as originally thought. In any case, I also think it makes sense to close this issue.

[MattHJensen]

It would seem to me that use case #1 from Matt's original post is still an unresolved use case but there is already at least one issue on the webapp repo to discuss that. Use case #2 seems to have not been as important as originally thought. In any case, I also think it makes sense to close this issue.

Agreed. Thanks @talumbau and @martinholmer. Closing.