Resolve issue 304 regarding Calculator constructor logic #1582
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.
This issue resolves issue #304 by revising the Calculator class constructor logic so that deep copies of the specified Policy and Records objects are assigned to the internal class policy and records attributes. In the same spirit as #304, the Calculator constructor now also makes a deep copy of Behavior objects and Consumption objects specified in the constructor call.
The reason for doing this is the reason highlighted in issue #304: the Calculator object should not cause side effects for the Policy or Records (or Behavior or Consumption) objects passed to the Calculator constructor.
However, there is another significant benefit from making these changes: the new idiom for creating current-law and reform Calculator objects is noticeably faster than the approach used now. The execution times cited below indicate a 35 percent reduction in execution time for a typical analysis situation.
One implication of these changes is that typical current usage of Behavior objects in Calculator objects may need to change in order to get correct behavior. One example of a needed change would be the behavioral-effect notebook. Part of this pull request is to make logically necessary changes in the use of a Behavior object in a Calculator object.
Another implication of these changes is that typical non-Behavior instantiation of current-law and reform Calculator objects is correct but inefficient (that is, does not automatically get the significant execution speed up mentioned above and described in detail below). A subsequent pull request will change the pytest unit tests to use the new more efficient Calculator constructor idiom.
Here is the script used to generate the execution times (OLD_IDIOM was set to True on the master branch and set to False on this development branch).
The results of running this script are as follows: