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

A Calculator should take user-defined functions that are called at calculation time #84

Closed
talumbau opened this issue Dec 18, 2014 · 3 comments

Comments

@talumbau
Copy link
Member

This would be a means to provide a friendly developer/user of the package with a way to add something to the model (credit, deduction, etc.). The idea is that a user may write a function and then register it with the calculator. The calculator will call it at the proper time. It could look like this:

def give_everyone_ten_grand(p):
    p.e00100 += 10000

calc = Calculator(tax_dta, default_year=91)

#Register callback here
calc.register_income_callback(give_everyone_ten_grand)

results = calc.run_all()

There are two things happening here. One is that run_all is now a method on a calculator that will call all of the functions in the designated sequence. Second is that this designated sequence would have a few spots to run any registered UDFs (user-defined functions). So, it would look like:

self.CapGains()
self.SSBenefits()
self.all_income_udfs()
self.AGI()

all_income_udfs would execute any registered income functions. We could have such a mechanism for income, deductions, credits, etc.

This capability would not be available through the web application, since it would involve execution of arbitrary code. Anyone using the package on their local machine would be able to do this though.

@talumbau
Copy link
Member Author

The unspoken question in this issue is, "Is this a good and/or useful idea?" @copper-head @MattHJensen

@martinholmer
Copy link
Collaborator

Issue #84, which was raised almost two years ago on 18-Dec-2014, would seem to have been superseded by the general method contained in pull request #1081.
Is there any reason why issue #84 should not be closed?

@talumbau @MattHJensen @feenberg

@MattHJensen
Copy link
Contributor

Agree that this issue has been superseded by #429. Closing

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

No branches or pull requests

3 participants