--- Laurie Harper <[EMAIL PROTECTED]> wrote:
> Michael Vogt wrote:
<snip>
> >
> > Is this a known problem or the expecxted behaviour?
> > What is the best way to work around it?
>
> That's the expected behaviour. Floats in Java (as in most programming
>
> languages) have limitted precision. 90.0f == 90.000001f by definition
> as
> a result of the way floats are represented internally and how strings
>
> are converted to float type. If float doesn't have sufficient
> precision
> for your needs, use double instead.
>
> If you need higher precision than even double supports, you'll need
> to
> use java.math.BigDecimal to represent your values -- though note that
>
> Validator may not support BigDecimal out of the box; you may need to
> write custom validation rules for that (I haven't checked so YMMV).
>
> L.
>
Thanks Laurie.
It makes sense. Initially I was surprised that precision was this low
for a 32 bit type, but looking at it in hex 90.000001 = 0x055D4A81 *
10^-6 I see this is getting up there.
I don't really need even float amount of precision, but I would like to
reject input that is out of the range (e.g. latitude>90).
Validator does not have BigDecimalRange (my version is even missing
doubleRange) out of the box.
Maybe I'll try a simple length check (e.g. <=7) in conjunction with the
floatRange (Not sure how to do both, yet).
Thanks,
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
