Re: benchmarks? java vs .net (sin and cos)

Discussion in 'Java' started by Patricia Shanahan, Jun 4, 2008.

  1. Razii wrote:
    > On Wed, 04 Jun 2008 09:04:01 +0100, Jon Harrop <>
    > wrote:
    >
    >
    >>>That's the only reason it's faster in partialsums benchmark.

    >>
    >>That is pure speculation.

    >
    >
    > It's not. I posted the evidence. C# gets wrong result.


    First of all, "right" vs. "wrong" is a matter of language specification.
    C# could be getting a different answer from Java, and yet produce an
    acceptable answer within the terms of its language specification.

    Similarly, Java only requires "The computed result must be within 1 ulp
    of the exact result. Results must be semi-monotonic.". One could imagine
    a language that requires the answer to be the round-to-nearest
    equivalent of a value within one part in 1e100 of the infinitely precise
    result. If a Java implementation did not get that answer, but did meet
    the Java specification, would its answer be "wrong"?

    The next question is whether Java's answer is usefully better than C#'s
    answer. As Jon Harrop indicated earlier, 1e15 radians is too big for
    useful trig precision.

    During a calculation, any infinitely precise result in the range
    [999999999999999.9375,1000000000000000.0625] gets rounded to the double
    representation of 1e15. The width of that range, regarded as an angle,
    is 0.125 radians, over seven degrees. The sine of the actual angle,
    before rounding to double, could be anywhere between about 0.8245 and
    about 0.8886.

    A 64 bit floating point calculation that depends on taking sines of
    angles around 1e15 radians is effectively operating with less than 2
    decimal digit precision. It has far, far worse numerical problems than
    the difference between the C# and Java results.

    Of course, this does not address the question of whether there are any
    angles for which Java's sine calculation is usefully more accurate than
    C#'s. 1e15 is not one of them.

    Patricia
     
    Patricia Shanahan, Jun 4, 2008
    #1
    1. Advertising

  2. [Side-note: Hi Patricia! Good to be chatting again... it's been a long
    time.]

    Patricia Shanahan <> wrote:
    > > It's not. I posted the evidence. C# gets wrong result.

    >
    > First of all, "right" vs. "wrong" is a matter of language specification.
    > C# could be getting a different answer from Java, and yet produce an
    > acceptable answer within the terms of its language specification.


    In this case I don't think it's actually a language issue at all - it's
    a standard libraries issue. C# and Java (the language) don't define any
    trig methods as far as I'm aware. So long as the compiler can get the
    value into the method accurately, and propagate the value back to the
    caller accurately, the languages are doing their jobs.

    There *are* interesting issues in terms of C# and its handling of
    floating point numbers, because it doesn't guarantee that calculations
    won't be performed at a higher precision than the type's
    representation. See
    http://msmvps.com/blogs/jon.skeet/archive/2005/10/02/68716.aspx
    for an example of this.

    > The next question is whether Java's answer is usefully better than C#'s
    > answer. As Jon Harrop indicated earlier, 1e15 radians is too big for
    > useful trig precision.


    Agreed. One thing I find interesting is that Google's result is the
    same as .NET's - if you type
    sin(1e15)
    into the search bar, you get 0.858272132, the same as the .NET answer.
    That can't be pure coincidence, but I've no idea where the similarity
    is...

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #2
    1. Advertising

  3. Razii <> wrote:
    > On Wed, 4 Jun 2008 19:49:20 +0100, Jon Skeet [C# MVP]
    > <> wrote:
    >
    > >into the search bar, you get 0.858272132, the same as the .NET answer.
    > >That can't be pure coincidence, but I've no idea where the similarity
    > >is...

    >
    > That's pretty simple to explain. Both use hardware for angle reduction
    > and get the same wrong answer. That's why it's faster but wrong. It's
    > not just 1e15
    >
    > What about these?
    >
    > Console.WriteLine(Math.Sin (1e7));
    >
    > 0.420547793190771 (C# with .NET)
    > 0.42054779319078249129850658974095 (right answer)
    >
    > Console.WriteLine(Math.Sin (1e10));
    >
    > -0.48750602507627 (C# with .NET)
    > -0.48750602508751069152779429434811 (right answer)
    >
    > I am sure there are better examples but the point is made.


    That's still of the order of at least 10 million radians. The exactly
    representable numbers immediately above and below 10 million are:

    9999999.99999999813735485076904296875
    10000000.00000000186264514923095703125

    In the same range, Math.sin varies (according to Java) between
    0.42054779488070526 and 0.4205477915008597 - that's just by changing 2
    ulps in the input. A significant change in the 9th DP, whereas C# was
    wrong in the 14th DP at 1E7.

    In other words, the error in the *output* of Math.Sin is almost
    certainly going to be dwarfed by thee error in the *input* of Math.Sin
    a that size of angle.

    This is probably why .NET went the "quick" route - because no-one
    realistically should be dealing with radian values that large in the
    first place.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #3
  4. Jon Skeet [C# MVP] wrote:
    > [Side-note: Hi Patricia! Good to be chatting again... it's been a long
    > time.]


    Hi Jon.

    >
    > Patricia Shanahan <> wrote:
    >
    >>>It's not. I posted the evidence. C# gets wrong result.

    >>
    >>First of all, "right" vs. "wrong" is a matter of language specification.
    >>C# could be getting a different answer from Java, and yet produce an
    >>acceptable answer within the terms of its language specification.

    >
    >
    > In this case I don't think it's actually a language issue at all - it's
    > a standard libraries issue. C# and Java (the language) don't define any
    > trig methods as far as I'm aware. So long as the compiler can get the
    > value into the method accurately, and propagate the value back to the
    > caller accurately, the languages are doing their jobs.

    ....

    Arguable in the case of Java. The Java Language Specification says that
    each compilation unit implicitly starts with an import of "the
    predefined package java.lang".

    I don't know whether C# has any libraries with such a privileged position.

    Patricia
     
    Patricia Shanahan, Jun 4, 2008
    #4
  5. Jon Skeet [C# MVP] wrote:
    > [Side-note: Hi Patricia! Good to be chatting again... it's been a long
    > time.]
    >
    > Patricia Shanahan <> wrote:
    >>> It's not. I posted the evidence. C# gets wrong result.

    >> First of all, "right" vs. "wrong" is a matter of language specification.
    >> C# could be getting a different answer from Java, and yet produce an
    >> acceptable answer within the terms of its language specification.

    >
    > In this case I don't think it's actually a language issue at all - it's
    > a standard libraries issue. C# and Java (the language) don't define any
    > trig methods as far as I'm aware. So long as the compiler can get the
    > value into the method accurately, and propagate the value back to the
    > caller accurately, the languages are doing their jobs.
    >


    Unlike most previous languages Java is not really separable from its
    standard library --- they come together, as do the mandated accuracy
    requirements.

    Mark Thornton
     
    Mark Thornton, Jun 4, 2008
    #5
  6. Patricia Shanahan

    Stefan Ram Guest

    Re: benchmarks? java vs .net (sin and cos)

    Patricia Shanahan <> writes:
    >Arguable in the case of Java. The Java Language Specification says that
    >each compilation unit implicitly starts with an import of "the
    >predefined package java.lang".


    Import declarations are used to interpret the following source
    code, they do not demand the ability to load certain types.

    Some profiles of some configurations of some editions of Java
    might miss some methods of the class java.lang.Math of Java SE.
     
    Stefan Ram, Jun 4, 2008
    #6
  7. Patricia Shanahan <> wrote:
    > > In this case I don't think it's actually a language issue at all - it's
    > > a standard libraries issue. C# and Java (the language) don't define any
    > > trig methods as far as I'm aware. So long as the compiler can get the
    > > value into the method accurately, and propagate the value back to the
    > > caller accurately, the languages are doing their jobs.

    > ...
    >
    > Arguable in the case of Java. The Java Language Specification says that
    > each compilation unit implicitly starts with an import of "the
    > predefined package java.lang".


    True - but it doesn't specify much about what's *in* that package, does
    it? (I imagine it references java.lang.Exception, java.lang.Throwable
    etc explicitly - but doesn't define java.lang.Math.sin.)

    > I don't know whether C# has any libraries with such a privileged position.


    Some types are referenced by the C# spec (System.Disposable, the
    generic and nongeneric IEnumerable interfaces and a few others) but not
    whole namespaces.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #7
  8. Mark Thornton <> wrote:
    > > In this case I don't think it's actually a language issue at all - it's
    > > a standard libraries issue. C# and Java (the language) don't define any
    > > trig methods as far as I'm aware. So long as the compiler can get the
    > > value into the method accurately, and propagate the value back to the
    > > caller accurately, the languages are doing their jobs.

    >
    > Unlike most previous languages Java is not really separable from its
    > standard library --- they come together, as do the mandated accuracy
    > requirements.


    Well, they come together to a *certain* extent - but they're not
    inseparable. In particular you can easily use the Java platform without
    using the Java language.

    The VM spec is also separate from the language spec, which is a good
    thing. It's just a shame that the name "Java" applies to the platform,
    the runtime, and the language. With C# it's easier to communicate the
    difference between talking about the language, the runtime, and the
    libraries. (Which isn't to say everyone gets it right, of course...)

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #8
  9. Razii <> wrote:
    > >This is probably why .NET went the "quick" route - because no-one
    > >realistically should be dealing with radian values that large in the
    > >first place.

    >
    > We are discussing partialsums benchmark .


    The post I was replying to wasn't - it was discussing sin(1e7)
    and sin(1e10). This subthread was started with a post talking about
    sin(1e15).

    I still maintain that if you're using that magnitude of angle in a real
    world application, you've got bigger problems. (In the benchmark,
    giving a value of N=2500000 means you're still taking the sin of a
    ridiculously large angle.)

    > Let's change
    >
    > Console.WriteLine("{0:f9}\tFlint Hills", a4);
    >
    > to
    >
    > Console.WriteLine("{0:f16}\tFlint Hills", a4);
    >
    > and see if even get the same answer.


    That's not the best way of finding out the exact value of a double. See
    http://pobox.com/~skeet/csharp/floatingpoint.html and download
    DoubleConverter.cs. Then you can use DoubleConverter.ToExactString to
    find out the absolutely precise value.

    > (.NET)
    > 30.3145415095625000 Flint Hills
    > 42.9952339980839000 Cookson Hills


    Using DoubleConverter and N=2500000 I get:
    2.999999999999998667732370449812151491641998291015625 (2/3)^k
    3160.81762188707580207847058773040771484375 k^-0.5
    0.99999960000020438055656768483459018170833587646484375 1/k(k+1)
    30.31454150956249549153653788380324840545654296875 Flint Hills
    42.99523399808393975263243191875517368316650390625 Cookson Hills
    15.309017154739198218749152147211134433746337890625 Harmonic
    1.6449336668483673928875532510573975741863250732421875 Riemann Zeta
    0.6931469805600938283163259256980381906032562255859375 Alt. Harmonic
    0.7853980633974355640702924574725329875946044921875 Gregory

    > (JAVA)
    > 30.3145415095632840 Flint Hills
    > 42.9952339980842500 Cookson Hills
    >
    > We don't. C# answer is most likely wrong so "fast" in this benchmark
    > comes at the cost of wrong answer.


    I love the way you go straight from "most likely" to an absolute
    assertion that the speed *is* at the cost of correctness. Note how the
    benchmark doesn't provide "correct" values. Heck, the results posted
    (in the languages I looked at, which was a fair variety) don't show
    enough significant figures to show whether they agree with .NET, Java
    or neither.

    None of the languages is going to get a perfectly accurate answer, of
    course - the accumulated error over 2.5 million additions is likely to
    be pretty significant, especially when each of the values added is only
    an approximation to the mathematical truth anyway.

    Now when a platform starts giving inappropriate answers on *sensible*
    questions, that's when I'd get more worried.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #9
  10. Jon Skeet [C# MVP] wrote:
    > Mark Thornton <> wrote:
    >>> In this case I don't think it's actually a language issue at all - it's
    >>> a standard libraries issue. C# and Java (the language) don't define any
    >>> trig methods as far as I'm aware. So long as the compiler can get the
    >>> value into the method accurately, and propagate the value back to the
    >>> caller accurately, the languages are doing their jobs.

    >> Unlike most previous languages Java is not really separable from its
    >> standard library --- they come together, as do the mandated accuracy
    >> requirements.

    >
    > Well, they come together to a *certain* extent - but they're not
    > inseparable. In particular you can easily use the Java platform without
    > using the Java language.
    >
    > The VM spec is also separate from the language spec, which is a good
    > thing. It's just a shame that the name "Java" applies to the platform,
    > the runtime, and the language.

    And at times several other things with no obvious relationship at the
    whim of Sun's marketing department. I seem to recall that the meaning of
    ..NET has had a few iterations as well.

    Mark Thornton
     
    Mark Thornton, Jun 4, 2008
    #10
  11. Mark Thornton <> wrote:
    > > The VM spec is also separate from the language spec, which is a good
    > > thing. It's just a shame that the name "Java" applies to the platform,
    > > the runtime, and the language.


    > And at times several other things with no obvious relationship at the
    > whim of Sun's marketing department. I seem to recall that the meaning of
    > .NET has had a few iterations as well.


    Oh yes indeed :) It's now mostly stabilised - although *exactly* what
    LINQ means has taken over as the "less well defined" term in my view :)

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #11
  12. Re: benchmarks? java vs .net (sin and cos)

    Razii wrote:

    > > I love the way you go straight from "most likely" to an absolute
    > > assertion that the speed is at the cost of correctness.

    >
    > That's pretty good assumption given that C# gets the wrong answer for
    > 1e7, 1e10, 1e15


    Anything using input values like that for sines is bound to get
    inaccurate answers. Anyone understanding a bit about floating point
    values knows that it is simply foolish to try to find the sine of such
    values and still expect any accuracy.

    I also wonder why one would want to do this. It doesn't make any sense.
    --
    Rudy Velthuis http://rvelthuis.de

    "A fast word about oral contraception. I asked a girl to go to
    bed with me, she said 'no'." -- Woody Allen
     
    Rudy Velthuis, Jun 4, 2008
    #12
  13. Re: benchmarks? java vs .net (sin and cos)

    Razii wrote:

    > Console.WriteLine(Math.Sin (1e7));
    >
    > 0.420547793190771 (C# with .NET)
    > 0.42054779319078249129850658974095 (right answer)
    >
    > Console.WriteLine(Math.Sin (1e10));
    >
    > -0.48750602507627 (C# with .NET)
    > -0.48750602508751069152779429434811 (right answer)


    Your "right answer" is more precise, but, due to the nature of decimal
    representations of real values, it is still off a little. Expecting
    more accuracy than the .NET program gives with a "double precision"
    floating point value is quite foolish.

    I'm sure there are libraries that will calculate the sine of 1e10 up to
    1000 decimals, but except specialized math languages, I doubt there are
    computer langusges where it makes sense to go that far. <g>
    --
    Rudy Velthuis http://rvelthuis.de

    "Asswhole = a complete ass" -- John McTaggart in bpot
     
    Rudy Velthuis, Jun 4, 2008
    #13
  14. Re: benchmarks? java vs .net (sin and cos)

    Jon Skeet [C# MVP] wrote:

    > This is probably why .NET went the "quick" route - because no-one
    > realistically should be dealing with radian values that large in the
    > first place.


    Indeed.

    --
    Rudy Velthuis http://rvelthuis.de

    "There are only two ways to live your life. One is as though
    nothing is a miracle. The other is as though everything is a
    miracle." -- Albert Einstein (1879-1955)
     
    Rudy Velthuis, Jun 4, 2008
    #14
  15. Re: benchmarks? java vs .net (sin and cos)

    Rudy Velthuis wrote:
    > Razii wrote:
    >
    >>> I love the way you go straight from "most likely" to an absolute
    >>> assertion that the speed is at the cost of correctness.

    >> That's pretty good assumption given that C# gets the wrong answer for
    >> 1e7, 1e10, 1e15

    >
    > Anything using input values like that for sines is bound to get
    > inaccurate answers. Anyone understanding a bit about floating point
    > values knows that it is simply foolish to try to find the sine of such
    > values and still expect any accuracy.
    >
    > I also wonder why one would want to do this. It doesn't make any sense.


    While I agree that it is unlikely to have any application in physics or
    engineering, sometimes mathematicians do find good reasons for computing
    apparently unlikely values. After all there was once a time when
    computations on 500+ bit integers would have been considered of no
    practical use. Now our security depends on such work.

    Before Java, the accuracy of many trig libraries was rather
    underspecified. Java's specification may be too strict, but at least it
    has one.

    Mark Thornton
     
    Mark Thornton, Jun 4, 2008
    #15
  16. Re: benchmarks? java vs .net (sin and cos)

    Mark Thornton <> wrote:
    > > I also wonder why one would want to do this. It doesn't make any sense.

    >
    > While I agree that it is unlikely to have any application in physics or
    > engineering, sometimes mathematicians do find good reasons for computing
    > apparently unlikely values. After all there was once a time when
    > computations on 500+ bit integers would have been considered of no
    > practical use. Now our security depends on such work.


    True. I think there's a significant difference between integer
    arithmetic and floating point - but I agree it's hard to predict the
    future.

    > Before Java, the accuracy of many trig libraries was rather
    > underspecified. Java's specification may be too strict, but at least it
    > has one.


    Oh indeed. The fact that there's both Math and StrictMath is
    particularly nice. It would be interesting to see a port of StrictMath
    for .NET.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #16
  17. Re: benchmarks? java vs .net (sin and cos)

    Razii <> wrote:
    > >> This is probably why .NET went the "quick" route - because no-one
    > >> realistically should be dealing with radian values that large in the
    > >> first place.

    > >
    > >Indeed.

    >
    > Skeet is wrong. It's not just limited to large values. C# just uses
    > the hardware fsin/fcos values. The value of sine for the
    > floating-point number Math.PI is around
    >
    > 1.2246467991473532E-16
    > 1.22460635382238E-16 (C# -- same answer as returned by fsin)
    >
    > Are you telling us that C# is a bad choice for software that must be
    > platform independent? On different hardware the answer would be
    > different if you are using C#.


    If you need bit-for-bit reproducability for all calculations, then I
    certainly agree that C# is unsuitable. Aside from the Math library
    calls, the CLI spec allows for a runtime to use higher precision for
    arithmetic where it wishes to. See section 12.1.3 of ECMA-335 for more
    information and a rationale.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
     
    Jon Skeet [C# MVP], Jun 4, 2008
    #17
  18. Re: benchmarks? java vs .net (sin and cos)

    Mark Thornton wrote:

    > > I also wonder why one would want to do this. It doesn't make any
    > > sense.

    >
    > While I agree that it is unlikely to have any application in physics
    > or engineering, sometimes mathematicians do find good reasons for
    > computing apparently unlikely values.


    No doubt. But any mathematician knowing anything how floating point
    numbers are implemented would think twice before doing that using
    "double precision", i.e. 8 byte floating point values.

    --
    Rudy Velthuis http://rvelthuis.de

    "There are only two tragedies in life: one is not getting what
    one wants, and the other is getting it."
    -- Oscar Wilde (1854-1900)
     
    Rudy Velthuis, Jun 4, 2008
    #18
  19. Re: benchmarks? java vs .net (sin and cos)

    Razii wrote:

    > Skeet is wrong. It's not just limited to large values. C# just uses
    > the hardware fsin/fcos values. The value of sine for the
    > floating-point number Math.PI is around
    >
    > 1.2246467991473532E-16
    > 1.22460635382238E-16 (C# -- same answer as returned by fsin)
    >
    > Are you telling us that C# is a bad choice for software that must be
    > platform independent?


    I am telling that the combination of double precision (8 byte, with 52
    bits for the mantissa) floating point values with such large values is
    simply a bad one.

    Of course .NET uses the hardware FPU on an x86 or x64 system.

    Since the error you see for Pi is ~1e-16, which is in 52nd bit of the
    mantissa (before normalization), that is excellent. Since for values
    close to 0 one can say that sin(x) = x, this means the error is as
    small as can be, using a mantissa of 52 bits. IOW, a more accurate
    result is impossible with a mantissa of 52 bits.

    If you want higher precision, don't use the builtin routines. These
    were not designed for that, just like the builtin math routines for
    most languages I know. I'm sure C, C++, Delphi etc. would give you
    similar results, on an x86.

    I just tried with C++, and indeed, I get the same result.
    --
    Rudy Velthuis http://rvelthuis.de

    "Wit makes its own welcome and levels all distinctions."
    -- Ralph Waldo Emerson (1803-1882)
     
    Rudy Velthuis, Jun 4, 2008
    #19
  20. Re: benchmarks? java vs .net (sin and cos)

    Razii wrote:

    > On Wed, 04 Jun 2008 15:56:46 -0700, "Rudy Velthuis"
    > <> wrote:
    >
    > > If you want higher precision, don't use the builtin routines.

    >
    > That was not the point. The point was that you get different answers
    > on different hardware. So the speed in this case comes at the cost
    > that software may behave differently on different hardware.


    That is the cost of using the available FPU, indeed. The alternative is
    using a library that does everything in code. Not feasible for many
    applications, I'd guess. Note that C and C++ also use the available
    hardware.
    --
    Rudy Velthuis http://rvelthuis.de

    "The nourishment is palatable" -- Emily Dickinson, dying words
     
    Rudy Velthuis, Jun 5, 2008
    #20
    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. Mark Thornton
    Replies:
    3
    Views:
    369
    Arne Vajhøj
    Jun 9, 2008
  2. Mark Thornton
    Replies:
    3
    Views:
    489
    Arne Vajhøj
    Jun 9, 2008
  3. Patricia Shanahan

    Re: benchmarks? java vs .net (sin and cos)

    Patricia Shanahan, Jun 4, 2008, in forum: C++
    Replies:
    24
    Views:
    835
    Arne Vajhøj
    Jun 9, 2008
  4. Jon Skeet [C# MVP]

    Re: benchmarks? java vs .net (sin and cos)

    Jon Skeet [C# MVP], Jun 4, 2008, in forum: Java
    Replies:
    33
    Views:
    856
    Arne Vajhøj
    Jun 17, 2008
  5. Jon Skeet [C# MVP]

    Re: benchmarks? java vs .net (sin and cos)

    Jon Skeet [C# MVP], Jun 4, 2008, in forum: C++
    Replies:
    33
    Views:
    942
    Arne Vajhøj
    Jun 17, 2008
Loading...

Share This Page