Add Choose[BigDecimal]

[dmurvihill]

I was initially going to just do this as part of #636, but now I'm not sure if a Choose[BigDecimal] implicit is even a good idea.

Any practical generator of real numbers can never be truly uniform, as Gen.choose purports to be. This isn't a problem for choose[Double], choose[Long], or even choose[BigInt], as all three of those values have bounded precision anyway. But when we try to implement choose[BigDecimal], we have to somehow accept a new free variable, precision, that is not available via the Gen.choose interface.

One way around this could be: instead of implementing choose[BigDecimal], provide a Choose[BigDecimal] factory that accepts a precision and whose result the user could declare as implicit. Seems pretty clunky, but still maybe easier than writing a BigDecimal generator directly?

[ashawley]

Thanks for creating this issue. I don't use a lot of arbitrary precision, and you sound like you have a specific use-case in mind, but why would you need to specify precision? What would be wrong with?

Gen.choose(BigDecimal("-9.22337203685477580E+214748366"), BigDecimal("9.223372036854775807E-2147483629")) 

[dmurvihill]

The numbers returned by that generator could be any size from 128 bits all the way up to 500MB in length.

[ashawley]

Ok, and that is what a precision parameter you mentioned would help avoid, or is this just an issue with the large numbers I chose as an example? I assumed BigDecimal had an efficient implementation, but this isn't the case?

[dmurvihill]

Let's simplify and say we are asking for Gen.choose(BigDecimal("-1.0"), BigDecimal("+1.0")).

Can this generator produce 0.1? If so, can it produce 0.11? How about 0.11111111111111111111111111111111111111111111111111111111111111111111, or even a string of 2^32 1s? Where does it end? That question can only be answered by the user based on their analysis of what is "close enough" for their use case.

[ashawley]

Good point. Finding the range between the values would likely determine what the scale should be. According to the documentation for java.math.BigDecimal, subtraction adopts the largest scale of the two operands. Would that be sufficient?

[dmurvihill]

Oh, I really like that. Hang on a minute.

[non]

#670