Re: Smart number formatting
- From: "Oliver Wong" <owong@xxxxxxxxxxxxxx>
- Date: Wed, 28 Sep 2005 16:42:19 GMT
"Rob McDonald" <robm@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:dhbnov$33t$1@xxxxxxxxxxxxxxxxxxxxxx
>> What if the user enters in "1.2000000476837158"? Wouldn't they be pissed
> off
>> if the program thought their number was "stupid" and changed it to "1.2"?
>
> A good point, but a highly unlikely scenario in this program. Especially
> considering that a user should have no expectation of 16 significant
> digits.
> In this case, anything the user inputs after the 8th decimal point renders
> the same binary representation.
If you want your software to be robust, it must perform within
specifications even in "highly unlikely scenarios".
> I have also considered counting the number of digits the user inputs to
> the
> right of the decimal point. The input precision could be stored, and then
> resurrected as a dynamic rounding limit. Again, a lot of work for
> something
> that seems simple.
This will fail if the stored number of significant digits is greater
than the number of digits which are significant in the decimal
representation of a float or double. E.g. if the user enters in a number
with 20 significant digits after the decimal point, you might store the fact
that there's 20 significant decimal digits after the decimal point, but as
soon as you're storing the original value entered by the user itself in a
double, you no longer have those 20 digits.
But yes, this is a lot of work when you could just, for example, store
the numbers as BigDecimals or as Strings.
> The other approach that might work capitalizes on the fact that the
> floating
> point representation of a number is always within one bit of the true
> value.
> So, the true value is bounded by floating point values one bit higher and
> lower than the given representation. How can these bounds be compared to
> figure out the true value?
Impossible. There are an infinite number of rational values between your
two bounds, any of which could have been the "true value".
> This basically amounts to losing a bit of precision... Compare the 31 bit
> representation of the number to the 32 bit representation, and keep
> everything where the two representations are the same. 31 bits is more
> than
> enough for these purposes.
You might need to go back and look at your product's requirements.
Floating points (i.e. float and double) are great when precision isn't
critical. Not so great when rounding errors can lead to disaster (e.g.
dealing with financial data). What do you need for your program to work?
>> Are all your numbers rational (i.e. as opposed to real numbers?) If
> so,
>> you might want to look at java.math.BigDecimal.
>
> Well, it is impossible for a human to type in an irrational number as
> input
> (who would have the time (:) so that would work. However, it would still
> require me to store a string of integers in the database. So, I might as
> well stick with a simpler solution.
I vaguely recall Java's BigDecimal type to map cleanly onto SQL's
DECIMAL type. You'd have to consult your documentation to verify this
though.
- Oliver
.
- References:
- Smart number formatting
- From: Rob McDonald
- Re: Smart number formatting
- From: Oliver Wong
- Re: Smart number formatting
- From: Rob McDonald
- Smart number formatting
- Prev by Date: Re: output ascii text file
- Next by Date: How to write a file header?
- Previous by thread: Re: Smart number formatting
- Next by thread: Re: Smart number formatting
- Index(es):
Relevant Pages
|
