ctubbsii commented on issue #2226: URL: https://github.com/apache/accumulo/issues/2226#issuecomment-893873619
BigDecimal seems tricky. You may need to normalize them in order to store them somehow. You can do some normalization by stripping trailing zero digits, but you still have to store the original precision in order to restore it on deserialization, and it has to be part of the ordering (example: 2.0 is not the same as 2.00, so we'd also have to decide which to sort first, the more precise or less precise values). After stripping trailing zero digits, you are still left with an unscaled integer that you need to normalize somehow if you want to do something like store the exponent first in order to order by magnitude, similar to how we store Double values. It gets further complicated that the unscaled integer is actually a BigInteger, so you'd have to store that part similar to our BigIntegerLexicoder. And then, after that, you still have to store the original scale, so we can order two equivalent numerical values lastly by precision. And, you have to deal with negative values too. I haven't seen too much pressure to implement this. Given the complexity of implementing, I probably wouldn't prioritize this. Hopefully most users will be happy with more limited precision Double values or BigInteger. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
