float to int conversion

[diego.manilla]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008
System.out.println(new Double(21082007.0).intValue()); // -> 21082007

Why?

System.out.println(new BigDecimal(21082007.0F).intValue()); // ->
21082008
System.out.println(new BigDecimal(21082007.0D).intValue()); // ->
21082007

Again, why?

And what's the proper way of doing it, using always a double?

Thanks in advance

 

[Daniel Pitts]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008
System.out.println(new Double(21082007.0).intValue()); // -> 21082007

Why?

System.out.println(new BigDecimal(21082007.0F).intValue()); // ->
21082008
System.out.println(new BigDecimal(21082007.0D).intValue()); // ->
21082007

Again, why?

And what's the proper way of doing it, using always a double?

Thanks in advance

Floating point numbers are inherently inaccurate.
I have to comment that those numbers look like dates. If they are
dates, you should use either a Date object, or at worse an integral
(long or int) value that represents the milliseconds or nanoseconds
from some epoch. Luckily for you, Java supports those out of the
bag...

If I was wrong about it being a date, you still should figure out if
you REALLY need it to be a float or double. Even double has the same
problem you're seeing, it just doesn't happen at the same time.

 

[diego.manilla]

Floating point numbers are inherently inaccurate.
I have to comment that those numbers look like dates. If they are
dates, you should use either a Date object, or at worse an integral
(long or int) value that represents the milliseconds or nanoseconds
from some epoch. Luckily for you, Java supports those out of the
bag...

If I was wrong about it being a date, you still should figure out if
you REALLY need it to be a float or double. Even double has the same
problem you're seeing, it just doesn't happen at the same time.

Hi, thanks for your reply. Yes, those numbers represent dates, and
yes, I would have used another data type to store them, but that's not
my choice. The fields are declared with a decimal data type in the
DDBB I'm accessing to, so I was using resultSet.getFloat() to retrieve
the values, and then casting to int and using a DateFormat to parse
the values. I think it's probable that resultSet.getInt() will have
the same problems.

 

[Lew]

This is no different from the first case.

How many digits of accuracy does float support?
double?

<http://mindprod.com/jgloss/ieee754.html>

Floating point numbers are inherently inaccurate.
I have to comment that those numbers look like dates. If they are
dates, you should use either a Date object, or at worse an integral
(long or int) value that represents the milliseconds or nanoseconds
from some epoch. Luckily for you, Java supports those out of the
bag...

If I was wrong about it being a date, you still should figure out if
you REALLY need it to be a float or double. Even double has the same
problem you're seeing, it just doesn't happen at the same time.

No one can claim to be a programmer without having read
<http://docs.sun.com/source/806-3568/ncg_goldberg.html>

 

[Lew]

Hi, thanks for your reply. Yes, those numbers represent dates, and
yes, I would have used another data type to store them, but that's not
my choice. The fields are declared with a decimal data type in the

What is the exact type in the data store?

What is the date format, DDMMYYYY?

DDBB

DBMS? If not, what is a "DDBB"?

I'm accessing to, so I was using resultSet.getFloat() to retrieve
the values, and then casting to int and using a DateFormat to parse
the values. I think it's probable that resultSet.getInt() will have
the same problems.

Floating-point types are the worst possible choice here, much, much worse than
using an integral type. You couldn't be more mistaken.

Note that Java has BigInteger and BigDecimal types.
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getBigDecimal(java.lang.String)>
<http://java.sun.com/javase/6/docs/a...html#setBigDecimal(int, java.math.BigDecimal)>

 

[Gordon Beaton]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008
System.out.println(new Double(21082007.0).intValue()); // -> 21082007

Why? [...]
And what's the proper way of doing it, using always a double?

Java floats use a 23-bit mantissa, so can't represent every 25-bit
number exactly. Java double uses 52 bits.

Why don't you use an int (32 bit) for this? It seems to me your
"dates" can't get significantly bigger than about 31 million.

/gordon

--

 

[Roedy Green]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008

see http://mindprod.com/applet/converter.html

you can do that more simply without creating a dummy Float object:

// to int i from float f
// best
i = (int)f;
// or
i = Math.round(f);
// or
i = (int)Math.ceil(f);
// or
i = (int)Math.floor(f);
// to see the IEEE bits inside a float
i = Float.floatToIntBits(f);

 

[Roedy Green]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008

21082007.0 is an implied double. It gets converted to a float to be
passed as a parameter.

See http://mindprod.com/jgloss/primitive.html

float has only 6 to 7 significant digits, so effectively you are
passing

21082000.0

You are "lucky" you got as close as you did (ints do better).

 

[Roedy Green]

And what's the proper way of doing it, using always a double?

It depends how much precision you need. Because modern floating point
hardware is all built on double, normally the only time you use float
is for float[] to conserve space when you don't need the precision.

see http://mindprod.com/jgloss/primitive.html

 

[Roedy Green]

System.out.println(new Float(21082007.0).intValue()); // -> 21082008
System.out.println(new Double(21082007.0).intValue()); // -> 21082007

read the essays at
http://mindprod.com/jgloss/primitive.html
http://mindprod.com/jgloss/floatingpoint.html

There are many other lions lying in wait.

 

[Roedy Green]

I have to comment that those numbers look like dates.

In that case see http://mindprod.com/jgloss/calendar.html
Java has a whole set of special tools for dealing with dates and
times. You never use double or float.

The human calendar it just too whacky to be described by the
regularity of the rational numbers or even Java floating point.