Java precision question

Discussion in 'Java' started by Bryan, Jan 19, 2007.

  1. Bryan

    Bryan Guest

    Hi we are using a offshore company to convert some legacy c++ code to java.

    One of the developers is telling me that java has higher multiplication
    precision than c++, which is something I find interesting.

    Is this true? If so why? I had thought that the precision was
    determined by the data type and the architecture, i.e. a double in c++
    should have the same precision as a double in java?

    Can anyone explain this a bit to me?

    Thanks,
    B
    Bryan, Jan 19, 2007
    #1
    1. Advertising

  2. Bryan

    Chris Uppal Guest

    Bryan wrote:

    > One of the developers is telling me that java has higher multiplication
    > precision than c++, which is something I find interesting.


    It's bollocks.

    Barring running on J2ME-style devices, where I know nothing about either Java's
    floating point requirements, nor what typical C/C++ compilers do.

    -- chris
    Chris Uppal, Jan 19, 2007
    #2
    1. Advertising

  3. Bryan

    Tom Hawtin Guest

    Bryan wrote:
    >
    > One of the developers is telling me that java has higher multiplication
    > precision than c++, which is something I find interesting.
    >
    > Is this true? If so why? I had thought that the precision was
    > determined by the data type and the architecture, i.e. a double in c++
    > should have the same precision as a double in java?


    In general Java defines results for consistency over accuracy.

    The original 1.0/1.1 semantics for floating point, required every
    operation result to be rounded to a value exactly representable as
    double/float. In C++ it may stay in extended precision if it remains in
    an FLU register. 1.2+ is slack by default, with strictfp restoring the
    predictable semantics.

    http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#249198

    Trig for *large values* on x87 architectures is likely to be more
    accurate, and slower. Java requires normalisation using an arbitrary
    accurate value of pi. x87 doesn't support that directly (to be fair
    reasonable algorithms didn't exist to do it at the time the 8087 was
    first released).

    The Math and StrictMath give some information about their methods
    (although there is still specification by referencing another
    implementation).


    Tom Hawtin
    Tom Hawtin, Jan 19, 2007
    #3
  4. Bryan wrote:
    > Hi we are using a offshore company to convert some legacy c++ code to java.
    >
    > One of the developers is telling me that java has higher multiplication
    > precision than c++, which is something I find interesting.
    >
    > Is this true? If so why? I had thought that the precision was
    > determined by the data type and the architecture, i.e. a double in c++
    > should have the same precision as a double in java?
    >
    > Can anyone explain this a bit to me?


    A double in Java is /always/ IEEE-754 long (and a float in Java is
    /always/ IEEE-754 short). A double or float in C++ is whatever the
    compiler writer thought it should be.

    Similarly, in Java:
    a byte is always twos-complement 8 bits,
    a short is always twos-complement 16 bits,
    a char is always unsigned 16 bits, and is encoded in UTF-16.
    an int is always twos-complement 32 bits, and
    a long is always twos-complement 64 bits.

    In a Java class or method with the strictfp modifier, and in expressions
    evaluated at compile time, all arithmetic will be done strictly
    according to IEEE-754. Otherwise, the last few bits may be either more
    or less accurate, if it is convenient for the hardware. C++ does not go
    into the issue at all.

    --
    John W. Kennedy
    "The blind rulers of Logres
    Nourished the land on a fallacy of rational virtue."
    -- Charles Williams. "Taliessin through Logres: Prelude"
    John W. Kennedy, Jan 19, 2007
    #4
  5. Bryan

    Guest

    Tom Hawtin wrote:

    > The original 1.0/1.1 semantics for floating point, required every
    > operation result to be rounded to a value exactly representable as
    > double/float. In C++ it may stay in extended precision if it remains in
    > an FLU register. 1.2+ is slack by default, with strictfp restoring the
    > predictable semantics.
    >
    > http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#249198


    This may be misleading. The precision of virtually all floating point
    expressions in Java is unaffected by the strictfp qualfier. The only
    time
    this qualifier comes into play is when very large or small values are
    obtained
    as intermediate results. Java allows non-strictfp intermediate results
    to use
    more bits in the exponent but the number of bits used in the mantissa
    does not change (see Table 4.1 in the JLS). So regardless of
    the availability of extended precision mantissa's in the hardware,
    Java programs may not take advantage of them.

    Regards,
    Tom McGlynn
    , Jan 19, 2007
    #5
  6. John W. Kennedy wrote:
    > Bryan wrote:
    >
    >> Hi we are using a offshore company to convert some legacy c++ code to
    >> java.
    >>
    >> One of the developers is telling me that java has higher
    >> multiplication precision than c++, which is something I find interesting.
    >>
    >> Is this true? If so why? I had thought that the precision was
    >> determined by the data type and the architecture, i.e. a double in c++
    >> should have the same precision as a double in java?
    >>
    >> Can anyone explain this a bit to me?

    >
    >
    > A double in Java is /always/ IEEE-754 long (and a float in Java is
    > /always/ IEEE-754 short). A double or float in C++ is whatever the
    > compiler writer thought it should be.
    >
    > Similarly, in Java:
    > a byte is always twos-complement 8 bits,
    > a short is always twos-complement 16 bits,
    > a char is always unsigned 16 bits, and is encoded in UTF-16.
    > an int is always twos-complement 32 bits, and
    > a long is always twos-complement 64 bits.
    >
    > In a Java class or method with the strictfp modifier, and in expressions
    > evaluated at compile time, all arithmetic will be done strictly
    > according to IEEE-754. Otherwise, the last few bits may be either more
    > or less accurate, if it is convenient for the hardware.


    Not true. The absence of strictfp only permits an extended range
    exponent, no extra (or fewer) mantissa bits are permitted. The only
    other effect of not having strictfp is to alter the accuracy
    requirements for the Math methods --- strictfp must used a specified
    algorithm.

    Mark Thornton
    Mark Thornton, Jan 19, 2007
    #6
  7. Bryan

    Guest

    Mark Thornton wrote:
    > John W. Kennedy wrote:
    > > Bryan wrote:
    > >
    > >> Hi we are using a offshore company to convert some legacy c++ code to
    > >> java.
    > >>
    > >> One of the developers is telling me that java has higher
    > >> multiplication precision than c++, which is something I find interesting.
    > >>
    > >> Is this true? If so why? I had thought that the precision was
    > >> determined by the data type and the architecture, i.e. a double in c++
    > >> should have the same precision as a double in java?
    > >>
    > >> Can anyone explain this a bit to me?

    > >
    > >
    > > A double in Java is /always/ IEEE-754 long (and a float in Java is
    > > /always/ IEEE-754 short). A double or float in C++ is whatever the
    > > compiler writer thought it should be.
    > >
    > > Similarly, in Java:
    > > a byte is always twos-complement 8 bits,
    > > a short is always twos-complement 16 bits,
    > > a char is always unsigned 16 bits, and is encoded in UTF-16.
    > > an int is always twos-complement 32 bits, and
    > > a long is always twos-complement 64 bits.
    > >
    > > In a Java class or method with the strictfp modifier, and in expressions
    > > evaluated at compile time, all arithmetic will be done strictly
    > > according to IEEE-754. Otherwise, the last few bits may be either more
    > > or less accurate, if it is convenient for the hardware.

    >
    > Not true. The absence of strictfp only permits an extended range
    > exponent, no extra (or fewer) mantissa bits are permitted. The only
    > other effect of not having strictfp is to alter the accuracy
    > requirements for the Math methods --- strictfp must used a specified
    > algorithm.
    >
    > Mark Thornton


    Isn't this slightly confusing two issues? The StrictMath library is
    required to produce results identically on all platforms regardless of
    the availability of potentially more precise and efficient
    implemenetations,
    while the standard Math library is given a bit more leeway in how it is
    implemented. However I don't think a call to a Math library routine in
    a strictfp block uses StrictMath. It still uses the local version of
    the Math library
    and thus can vary from machine to machine.

    So, to ensure the same results on all machines you need to use
    StrictMath for all mathematical functions and all calculations need to
    be down within strictfp blocks (or methods or classes).

    Regards,
    Tom McGlynn
    , Jan 19, 2007
    #7
  8. wrote:
    > Mark Thornton wrote:
    >
    >>John W. Kennedy wrote:
    >>
    >>>Bryan wrote:
    >>>
    >>>
    >>>>Hi we are using a offshore company to convert some legacy c++ code to
    >>>>java.
    >>>>
    >>>>One of the developers is telling me that java has higher
    >>>>multiplication precision than c++, which is something I find interesting.
    >>>>
    >>>>Is this true? If so why? I had thought that the precision was
    >>>>determined by the data type and the architecture, i.e. a double in c++
    >>>>should have the same precision as a double in java?
    >>>>
    >>>>Can anyone explain this a bit to me?
    >>>
    >>>
    >>>A double in Java is /always/ IEEE-754 long (and a float in Java is
    >>>/always/ IEEE-754 short). A double or float in C++ is whatever the
    >>>compiler writer thought it should be.
    >>>
    >>>Similarly, in Java:
    >>> a byte is always twos-complement 8 bits,
    >>> a short is always twos-complement 16 bits,
    >>> a char is always unsigned 16 bits, and is encoded in UTF-16.
    >>> an int is always twos-complement 32 bits, and
    >>> a long is always twos-complement 64 bits.
    >>>
    >>>In a Java class or method with the strictfp modifier, and in expressions
    >>>evaluated at compile time, all arithmetic will be done strictly
    >>>according to IEEE-754. Otherwise, the last few bits may be either more
    >>>or less accurate, if it is convenient for the hardware.

    >>
    >>Not true. The absence of strictfp only permits an extended range
    >>exponent, no extra (or fewer) mantissa bits are permitted. The only
    >>other effect of not having strictfp is to alter the accuracy
    >>requirements for the Math methods --- strictfp must used a specified
    >>algorithm.
    >>
    >>Mark Thornton

    >
    >
    > Isn't this slightly confusing two issues? The StrictMath library is
    > required to produce results identically on all platforms regardless of
    > the availability of potentially more precise and efficient
    > implemenetations,
    > while the standard Math library is given a bit more leeway in how it is
    > implemented. However I don't think a call to a Math library routine in
    > a strictfp block uses StrictMath. It still uses the local version of
    > the Math library
    > and thus can vary from machine to machine.


    Sorry you're right.

    Mark
    Mark Thornton, Jan 19, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?am9l?=

    precision question

    =?Utf-8?B?am9l?=, Apr 12, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    341
    Kevin Spencer
    Apr 12, 2006
  2. Replies:
    5
    Views:
    204,430
  3. Replies:
    8
    Views:
    799
    Andrew Thompson
    Oct 7, 2006
  4. haley
    Replies:
    7
    Views:
    2,983
    Chris Uppal
    Jan 4, 2007
  5. inspired
    Replies:
    4
    Views:
    793
    Roedy Green
    Nov 28, 2010
Loading...

Share This Page