I can clarify that a little bit: it's not that you want to get
arbitrarily *large* values in your form (though maybe Gill's app
requires that), but rather that float and double are not precise, and
when you do a bunch of consecutive operations on them, you can get
rounding errors that add up to real money.
The basic problem is that "1300.5" may, if you look at the underlying
representation, *really* be "1300.50000000001", or worse,
"1300.499999999999". BigDecimal is a precise representation. And it
allows you to explicitly specify how you want rounding to be handled,
which is important in financial applications.
My approach so far has been to use "long" as the database representation
(representing a whole number of the smallest unit of currency) and
provide accessors to automatically convert to/from BigDecimal. But that
is far from an ideal solution and direct BigDecimal support would be great.
-Steve
Geert Bevin wrote:
Hi Gill,
this is indeed an oversight and I'll fix it in the coming days.
I've never has the case that an arbitrary amount of money had to be
entered through a web form. You might want to use double in the
meantime and change that over as soon as BigDecimal support is in there.
Best regards,
Geert
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
