Problem with encoding a very large BigInteger or BigDecimal without fraction

[mpnd]

We have an issue to encode a very large BigDecimal. For example, when I tried to encode 7.533938258014959827307132527342E+545 I got the following error:

Error com.n1analytics.paillier.EncodeException: Input value cannot be encoded.
   at com.n1analytics.paillier.StandardEncodingScheme.encode(StandardEncodingScheme.java:115)
   at com.n1analytics.paillier.StandardEncodingScheme.encode(StandardEncodingScheme.java:239)
   ...

The reason why I got the error is as follows:

1. The number is a BigDecimal, however because it doesn't have a fraction part, Javallier encodes the number as a BigInteger to prevent precision loss. (StandardEncodingScheme line 224-240)
2. When encoding a non-zero BigInteger, the number is repeatedly divided by the encoding base until the number is not divisible by the encoding base anymore. At each step, the exponent is incremented by one. (StandardEncodingScheme line 107-113)
3. If the resulting number is greater than the PaillierContext's maxSignificand OR is less than the minSignificand then EncodeException is thrown. In this case the number is greater than maxSignificand. (StandardEncodingScheme line 114-116).

The problem is when encoding a BigInteger greater than maxSignificand OR less than the minSignificand, some of these numbers cannot be encoded either because the number is not divisible by the encoding base or the result of the repeat division (as mentioned in step 2 above) is not in the minSignificand to maxSignificand range.

[hardbyte]

We provide a method to explicitly encode as a BigDecimal and then we ignore it and encode as a BigInteger. Can we add a check that the size of the BigDecimal is small enough to be encoded as a BigInteger? Otherwise if the BigInteger encoding fails we should fall back to the BigDecimal encoding.

[unzvfu]

I'd be inclined to get rid of BigDecimal support altogether. Do we have a concrete use case?

By limiting support to single- and double-precision floats we (i) simplify the interface and (ii) have a much easier time with the a priori analysis of overflow likelihood that needs to be done with every algorithm that uses an encoded number.

[unzvfu]

After discussion: Seems we agree that supporting BigDecimal has limited utility for us, although it's a fairly logical thing to want to do in principle. Need to reconsider the situation when we get around to reviewing and improving the encoding schemes; in the mean time, changing this interface would break a bunch of other stuff.