Velocity Reviews > Java > Problems adding floats

Klixx0r
Guest
Posts: n/a

 12-12-2004
I have a problem when adding 2 floats together.

I add 1.235 and 0.001 together and get 1.2360001. Substraction
works fine.

With the addition I need the answer 1.236 and just that. Is there
any solution to this problem?

Thanks

----------------------------------------------
Posted with NewsLeecher v1.0 Final
* Binary Usenet Leeching Made Easy
* http://www.newsleecher.com/?usenet
----------------------------------------------

klynn47@comcast.net
Guest
Posts: n/a

 12-12-2004
I think the problem lies in the fact that decimal numbers can't always
be converted into binary decimals exactly. There might be two possible
results when converting. You might try using BigDecimal

Matt Humphrey
Guest
Posts: n/a

 12-12-2004

"Klixx0r" <(E-Mail Removed)> wrote in message
news:su2vd.880\$(E-Mail Removed)...
> I have a problem when adding 2 floats together.
>
> I add 1.235 and 0.001 together and get 1.2360001. Substraction
> works fine.
>
> With the addition I need the answer 1.236 and just that. Is there
> any solution to this problem?

The problem is actually that you don't understand how floating point numbers
work. Many simple decimal numbers (e.g. 0.001) repeat indefinately when
represented in binary and cannot be represented precisely. If precision is
critical for you, as it would be for financial data, try BigDecimal.
Otherwise, accept that real numbers cannot be represented with perfect
precision in a finite number of bits and round the number to the something
acceptable and format the result to ignore the result. Look at Math.round /
floor / ceil and DecimalFormat.

Cheers,
Matt Humphrey http://www.velocityreviews.com/forums/(E-Mail Removed) http://www.iviz.com/

Patricia Shanahan
Guest
Posts: n/a

 12-12-2004
Klixx0r wrote:

> I have a problem when adding 2 floats together.
>
> I add 1.235 and 0.001 together and get 1.2360001. Substraction
> works fine.
>
> With the addition I need the answer 1.236 and just that. Is there
> any solution to this problem?
>
> Thanks
>
> ----------------------------------------------
> Posted with NewsLeecher v1.0 Final
> * Binary Usenet Leeching Made Easy
> * http://www.newsleecher.com/?usenet
> ----------------------------------------------
>

There are other combinations of numbers for which
subtraction will give rounding errors.

The solution depends on the actual constraints:

1. If you need exact arithmetic for short decimal fractions,
for example to do financial calculations, use
java.math.BigDecimal.

2. If you need reasonable precision for more general cases,
for example, 1/3.0, use double. Use java.text.DecimalFormat
to round on output.

I would only use float for very large quantities of low
precision data.

Patricia

Michael Borgwardt
Guest
Posts: n/a

 12-13-2004
Matt Humphrey wrote:
> The problem is actually that you don't understand how floating point numbers
> work. Many simple decimal numbers (e.g. 0.001) repeat indefinately when
> represented in binary and cannot be represented precisely. If precision is
> critical for you, as it would be for financial data, try BigDecimal.

Precision is not the issue; double offers plenty of precision. The issue is
conforming to expectations about decimal fractions and, more importantly,
having stringently defined rounding rules (i.e. imprecision).

Mark Thornton
Guest
Posts: n/a

 12-13-2004
Michael Borgwardt wrote:
> Matt Humphrey wrote:
>
>> The problem is actually that you don't understand how floating point
>> numbers
>> work. Many simple decimal numbers (e.g. 0.001) repeat indefinately when
>> represented in binary and cannot be represented precisely. If
>> precision is
>> critical for you, as it would be for financial data, try BigDecimal.

>
>
> Precision is not the issue; double offers plenty of precision. The issue is
> conforming to expectations about decimal fractions and, more importantly,
> having stringently defined rounding rules (i.e. imprecision).

The rounding rules for float and double are stringently defined, just
different to those defined on decimal fractions.

Mark Thornton