Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

whack another penny mole #2198

Closed
chadwhitacre opened this issue Mar 28, 2014 · 20 comments
Closed

whack another penny mole #2198

chadwhitacre opened this issue Mar 28, 2014 · 20 comments

Comments

@chadwhitacre
Copy link
Contributor

We have another off-by-a-penny bug in MassPay. Reticketing from #2190.

@chadwhitacre
Copy link
Contributor Author

The target amount for the bad row is 676.00.

@chadwhitacre
Copy link
Contributor Author

We're computing 662.75. This is a case like #1673. Originally there we checked for both 0.25 and 0.75 as amounts to upload that could never hit the target amount we were aiming for, but then in ba2b611 I dropped it back to only 0.25. Why? What issue/PR was that commit on?

@chadwhitacre
Copy link
Contributor Author

#2029, per the commit description.

@chadwhitacre
Copy link
Contributor Author

I have the distinct feeling of not truly understanding the math behind what is going on here.

@chadwhitacre
Copy link
Contributor Author

It feels like to truly solve this and stop playing whack-a-mole, we should understand the math.

@chadwhitacre
Copy link
Contributor Author

Like, presumably, I added 0.75 in #1674 because I thought that was right, and then removed it in #2029 because I thought it was wrong. So which is it? Is there some other pattern beyond the 0.25, 0.75 one?

@chadwhitacre
Copy link
Contributor Author

Given a target amount, we want to find an amount that, when fed into PayPal's fee function, will result in the target amount or a penny less.

What is the precise inverse of PayPal's fee function?

@chadwhitacre
Copy link
Contributor Author

That's the problem: it's not precise.

PayPal's fee is 2%, so the inverse is X / 1.02. Since we can only upload pre-fee amounts to two decimal places, however, there are cases where we can't hit the target amount+fee.

@chadwhitacre
Copy link
Contributor Author

So we need to identify what those cases are and payout slightly less in those cases (with a note about the penny—or two?—we're leaving in their Gittip).

@chadwhitacre
Copy link
Contributor Author

screen shot 2014-03-28 at 5 45 11 pm

@chadwhitacre
Copy link
Contributor Author

That's 52¢ through 88¢, divided by 1.02.

@chadwhitacre
Copy link
Contributor Author

I don't have time to get to the bottom of this right now.

@chadwhitacre
Copy link
Contributor Author

I tried bringing back the 0.75 case, and MassPay was still off by a penny. Whack-a-mole indeed.

@rummik
Copy link
Contributor

rummik commented Mar 28, 2014

@whit537 Should it be X - (X * 0.02)? Seems like division triggers a lot of issues with floating point math.

@chadwhitacre
Copy link
Contributor Author

@rummik Can't say right now. I am going to run MassPay for #2190 off by a penny and get to the bottom of it later.

@chadwhitacre
Copy link
Contributor Author

We can eat a penny.

@rummik
Copy link
Contributor

rummik commented Mar 29, 2014

...What. I just looked at bin/masspay.py#L81-L83. PayPal is rounding to the nearest cent? Isn't the correct banking procedure to always round up with fees?

@rummik
Copy link
Contributor

rummik commented Mar 29, 2014

As we're seeing here, the math gets very unpredictable if they do that.

@rummik
Copy link
Contributor

rummik commented Mar 30, 2014

After poking a bit, it looks like X * 100 * 0.02 % 1 >= 0.5 is the correct way to determine if we'll need to eat a penny. We can also calculate it as X * 0.02 % 0.01 >= 0.005, since Decimal maintains precision at four decimal places, but I find using cents to be easier to understand. :P

@chadwhitacre
Copy link
Contributor Author

Closing this one. We would have dealt with the 676.00 just fine if I hadn't taken the 0.75 check out in #2029.

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

No branches or pull requests

2 participants