«

I teach some properties of the data type »double«:

public class Main
{ public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( 0.1 + 0.1 + 0.1 == 0.3 );
java.lang.System.out.println( 1.1 * 1.1 == 1.21 ); }}

false
false

. I also teach that beginners should not use the data type
»float«, because it will only cause trouble.

But now a student came up with this:

public class Main
{ public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( 0.1f + 0.1f + 0.1f == 0.3f );
java.lang.System.out.println( 1.1f * 1.1f == 1.21f ); }}

true
true

. So, now it looks as if double just does the wrong thing
and as if float just does the right thing.

How does one deal with this, when explaining, when to use
»float« and when to use »double«?

Stefan Ram wrote:
> I teach some properties of the data type »double«:
>
> public class Main
> { public static void main( final java.lang.String[] args )
> { java.lang.System.out.println( 0.1 + 0.1 + 0.1 == 0.3 );
> java.lang.System.out.println( 1.1 * 1.1 == 1.21 ); }}
>
> false
> false
>
> . I also teach that beginners should not use the data type
> »float«, because it will only cause trouble.
>
> But now a student came up with this:
>
> public class Main
> { public static void main( final java.lang.String[] args )
> { java.lang.System.out.println( 0.1f + 0.1f + 0.1f == 0.3f );
> java.lang.System.out.println( 1.1f * 1.1f == 1.21f ); }}
>
> true
> true
>
> . So, now it looks as if double just does the wrong thing
> and as if float just does the right thing.

In both cases float and double are working as should be expected. Just
because floating point types often do not represent decimal values
exactly doesn't mean that some values are not represented exactly. In
the case of float the result of 0.1f+0.1f+0.1f is not exactly equal to
0.3 (because 0.3 is not exactly representable by either float or
double). It just happens the nearest float to 0.3 (which is what 0.3f
is) is equal to the result of 0.1f+0.1f+0.1f.

There is a valuable place for the use of float and double in scientific
and engineering computation. Statistics is another area where the use of
floating point is hard to avoid. Outside of these areas they should
mostly be avoided. Unfortunately BigInteger and BigDecimal are bit
tedious to use due to the absence of operator overloading for these types.


Mark Thornton

On May 7, 12:15*pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> * I teach some properties of the data type »double«:
>
> public class Main
> { public static void main( final java.lang.String[] args )
> * { java.lang.System.out.println( 0.1 + 0.1 + 0.1 == 0.3 *);
> * * java.lang.System.out.println( * * * 1.1 * 1.1 == 1.21 ); }}
>
> false
> false
>
> * . I also teach that beginners should not use the data type
> * »float«, because it will only cause trouble.
>
> * But now a student came up with this:
>
> public class Main
> { public static void main( final java.lang.String[] args )
> * { java.lang.System.out.println( 0.1f + 0.1f + 0.1f == 0.3f *);
> * * java.lang.System.out.println( * * * *1.1f * 1.1f == 1..21f ); }}
>
> true
> true
>
> * . So, now it looks as if double just does the wrong thing
> * and as if float just does the right thing.

That is a completely deceptive appearance. You just happened to pick
examples that gave that illusion. In reality, both float and double
are doing the right thing, and you cannot count on either one to yield
an exact comparison using '==' with values that are not exactly
representable in finite-precision binary. In reality float has higher
error, because in either case expected error of a term will start at 1
ulp.

> * How does one deal with this, when explaining, when to use
> * »float« and when to use »double«?

One uses double when high precision is required, which is most of the
time. One uses float when high precision is not so necessary, as,
say, Swing does in calculating screen positions, and when speed is
more important than precision.

--
Lew

Lew wrote:
>
> One uses double when high precision is required, which is most of the
> time. One uses float when high precision is not so necessary, as,
> say, Swing does in calculating screen positions, and when speed is
> more important than precision.
>

Float is used when memory is short, you need a very large number of
values and can tolerate the lower precision. The performance advantage
is modest (and often more a result of fitting more values in the
processor cache than increased speed of the basic operation).
Any exception to this is with GPUs where float is fast but double either
slow or non existent. However this doesn't (yet) apply directly to Java.

Mark Thornton

Christian wrote:
> Also a situtation where float is preferred for me to double:
> A volatile float is written atomic *[sic] while a volatile double is not!

That is totally not true.

Volatile doubles are written atomically. JLS 17.7:
> Writes and reads of volatile long and double values are always atomic.

--
Lew

Lew wrote:
> Christian wrote:
>> Also a situtation where float is preferred for me to double:
>> A volatile float is written atomic [sic] while a volatile double is not!
>
> That is totally not true.
>
> Volatile doubles are written atomically. JLS 17.7:
>> Writes and reads of volatile long and double values are always atomic.

It was true of some early JVMs.

http://bugs.sun.com/bugdatabase/view...bug_id=4023233

Note that despite what it says in that bug report, this has been fixed.

Mark Thornton

Christian wrote:
>>> Also a situtation where float is preferred for me to double:
>>> A volatile float is written atomic *[sic] while a volatile double is not!
>

Lew wrote:
>> That is totally not true.
>
>> Volatile doubles are written atomically. *JLS 17.7:
>>> Writes and reads of volatile long and double values are always atomic.
>

Mark Thornton wrote:
> It was true of some early JVMs.
>
> http://bugs.sun.com/bugdatabase/view...bug_id=4023233
>
> Note that despite what it says in that bug report, this has been fixed.

That is so 20th century!

Note that the memory model changed significantly (with Java 5) also,
in particular with respect to the semantics of 'volatile'.

I think it's safe to challenge on the basis of the JLS an incorrect
statement about Java semantics irrespective of bugs that were fixed
years and years ago. The point is that Sun's JVM and presumably every
other one extant today conforms to the language specification
regarding atomic reads and writes of volatile longs and doubles.

As Java developers we have to go by the specification, not by bugs in
its implementations. Those that rely on violations of the
specification risk having their code break when the bug is fixed, as,
say, Apache commons-lang did in tbeir "enum" implementation prior to
Java 5 that broke when Sun fixed the bug (and Apache refused to fix
it). Java programmers have a right to expect Java implementations to
conform to the specification.

That is moot here, anyway, since volatile actually works as specified
in this matter: reads and writes of volatile longs and doubles are
atomic. To state otherwise does a huge disservice to those who might
not know better.

--
Lew

On May 7, 5:40*pm, Lew <l...@lewscanon.com> wrote:
> Those that rely on violations of the
> specification risk having their code break when the bug is fixed, as,
> say, Apache commons-lang did in tbeir "enum" implementation prior to
> Java 5 that broke when Sun fixed the bug (and Apache refused to fix
> it). *Java programmers have a right to expect Java implementations to
> conform to the specification.
>

I should clarify: the Apache commons-lang "enum" bug had nothing to do
with 'volatile'. It was that certain methods in their "enum" relied
on references to a 'class' literal causing initialization of the
owning class. When Sun fixed that initialization bug, those Apache
commons "enum" methods broke.

--
Lew

Lew wrote:
> Christian wrote:
>>>> Also a situtation where float is preferred for me to double:
>>>> A volatile float is written atomic [sic] while a volatile double is not!
>
> Lew wrote:
>>> That is totally not true.
>>> Volatile doubles are written atomically. JLS 17.7:
>>>> Writes and reads of volatile long and double values are always atomic.
>
> Mark Thornton wrote:
>> It was true of some early JVMs.
>>
>> http://bugs.sun.com/bugdatabase/view...bug_id=4023233
>>
>> Note that despite what it says in that bug report, this has been fixed.
>
> That is so 20th century!
>
> Note that the memory model changed significantly (with Java 5) also,
> in particular with respect to the semantics of 'volatile'.
>
> I think it's safe to challenge on the basis of the JLS an incorrect
> statement about Java semantics irrespective of bugs that were fixed
> years and years ago. The point is that Sun's JVM and presumably every
> other one extant today conforms to the language specification
> regarding atomic reads and writes of volatile longs and doubles.
>

Nevertheless, it can be important to check our assumptions. Long ago I
did check for atomic assignment found that it didn't work. Just a few
days ago I found some code that depended on the behaviour of
Timestamp.getTime() as exhibited by JVMs up to 1.4. In 1.4, Sun changed
the behaviour and left the documentation very confusing (especially for
those aware of the previous behaviour).

In this case I was just adding an historical note that there was some
basis for believing the assignments not to be atomic, but today it is
about as valid as suggesting that Java is slow!

Mark Thornton

On Thu, 7 May 2009, Stefan Ram wrote:

> . I also teach that beginners should not use the data type
> ?float?, because it will only cause trouble.

Interesting. FWIW, i use doubles when i'm doing mathematics, and floats
when i'm doing sums - which is an aphoristic way of saying that i use
doubles when i'm doing calculations where i care about accuracy, range,
etc, whcih is things like numerical work, data processing, whatever, and
floats when i'm doing things like calculating a load factor for a
hashtable, or the index of the 95th centile in an array, etc.

tom

--
When I see a man on a bicycle I have hope for the human race. --
H. G. Wells