SOIT accuracy regarding the c10300 variable about tax-calculator HOT 3 CLOSED

It looks like this line is governing the SAS code:

if FLPDYR ge 2011 then c10300 = c09200 - e10000 - e09710 - e09720

Does that get you the right result? If so, the rest of the lines aren’t needed.

@feenberg, could you suggest a way that I could I verify that this is correct for 2013 (and onwards) from first principles?

Matt

On Jan 22, 2015, at 1:27 PM, Jake Lyons <[email protected]mailto:[email protected]> wrote:

In the SOIT() function it looks like there may be a bug, but I am not sure what the correct fix should be.

Should the linehttps://github.com/OpenSourcePolicyCenter/Tax-Calculator/blob/jit/taxcalc/calculate.py#L2410
c10300 = c10300 - c10300 - c10950 - e11451 - e11452
be
c10300 = c10300 - c10950 - e11451 - e11452 ?

and also the linehttps://github.com/OpenSourcePolicyCenter/Tax-Calculator/blob/jit/taxcalc/calculate.py#L2411
c10300 = c09200 - e09710 - e09720 - e10000 - e11601 - e11602
be
c10300 = c10300 - c09200 - e09710 - e09720 - e10000 - e11601 - e11602?

OR

if the second linehttps://github.com/OpenSourcePolicyCenter/Tax-Calculator/blob/jit/taxcalc/calculate.py#L2411 referenced above is correct, than the above 7 lineshttps://github.com/OpenSourcePolicyCenter/Tax-Calculator/blob/jit/taxcalc/calculate.py#L2403-2410 of code are not needed, as they do not impact the accuracy of that variable.

@feenberghttps://github.com/feenberg and @MattHJensenhttps://github.com/MattHJensen, is this an error? And if so, which would be the correct fix?

Additionally, if the first suggestion is correct I think it would be easier to read and less error prone if the bulk of that function was consolidated into a single assignment of the c10300 variable instead of re-assignment, such as
c10300 = c09200 - e10000 - e59680 - ... - ... - e11601 - e11602 all at once.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/95.

from tax-calculator.

At the SOI there is great concern over how much of each credit is applied
against income tax, other tax or refunded. I don't think we care at all.
This means that the last paragraphs of the taxcalc.sas code can be
replaced with:

_refund = c59660 + c11070 + c10960;
_ospctax = c09200-_refund
c10300 = max(0,_ospctax)

c09200 is just tax after non-refundable credits but the relevant number
for all economic issues is _ospctax. We may need c10300 to compare to CBO
forecasts. In my uploads, _ospctax will be _nbertax.

Dan

On Thu, 22 Jan 2015, Jake Lyons wrote:

In the SOIT() function it looks like there may be a bug, but I am not sure
what the correct fix should be.

Should the line
c10300 = c10300 - c10300 - c10950 - e11451 - e11452
be
c10300 = c10300 - c10950 - e11451 - e11452 ?

and also the line
c10300 = c09200 - e09710 - e09720 - e10000 - e11601 - e11602
be
c10300 = c10300 - c09200 - e09710 - e09720 - e10000 - e11601 - e11602?

OR

if the second line referenced above is correct, than the above 7 lines of
code are not needed, as they do not impact the accuracy of that variable.

@feenberg and @MattHJensen, is this an error? And if so, which would be the
correct fix?

Additionally, if the first suggestion is correct I think it would be easier
to read and less error prone if the bulk of that function was consolidated
into a single assignment of the c10300 variable instead of re-assignment,
such as
c10300 = c09200 - e10000 - e59680 - ... - ... - e11601 - e11602 all at once.

—
Reply to this email directly or view it on
GitHub.[AHvQVS0abgxasH3Z6-VqFZTOfZJO28w6ks5nkTiigaJpZM4DV8Wc.gif]

from tax-calculator.

dealt with in #129, closing

from tax-calculator.