Issue15 fix version 2

[kboyd]

Better bug fix for integer overflow of #15, should be used instead of #17. No changes to internal Curve representation, only cast to double before performing totalPositives * totalNegatives operation in rocArea and mannWhitneyU.

I'm casting to double instead of long since the ultimate result of the expression is always a double. If you think a more accurate computation will occur by casting to long, performing the multiplication, and only then casting to double I can do it but that involves more casts and seems confusing.

[daslu]

Thank you for the fix!

Yes, casting just before multiplication seems to be the appropriate change, sorry if I caused the confusion.

I read into the code, this looks fine. I will test it with large examples in the next following days.

[afbarnard]

Summarizing our conversation today, these are the things I would like to see added/fixed.

• Documentation of tested scale. We decided 1M total examples would be appropriate because multiplication would not overflow the precision of a double (53 bits) and that scale is larger than all cases we are aware of and will not be a memory allocation burden (<50MiBs).
• A comment about why the fix works in the code related to the overflow(s). (So a reference to the (possible) problem and why this code avoids/fixes it.)
• Java style: whitespace, indentation, etc.

At some point we should have more scale tests, but that doesn't need to happen now.

[kboyd]

Updated branch with the following fixes.

• Fixed whitespace to match java style and rest of code.
• Added more detailed comment about why double cast should not lose precision.
• Changed test from 2^17 to 2^20 examples to match the 1M example support.

[afbarnard]

Ok, @kboyd, this all looks good. Per your request, I'll do the honors.