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

Razii wrote:
> On Wed, 04 Jun 2008 09:04:01 +0100, Jon Harrop <jon@ffconsultancy.com>
> 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

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

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

Patricia Shanahan <pats@acm.org> 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/ar.../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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

Razii <niklgfsdb@mail.com> wrote:
> On Wed, 4 Jun 2008 19:49:20 +0100, Jon Skeet [C# MVP]
> <skeet@pobox.com> 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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

Jon Skeet [C# MVP] wrote:
> [Side-note: Hi Patricia! Good to be chatting again... it's been a long
> time.]

Hi Jon.

>
> Patricia Shanahan <pats@acm.org> 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

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

Jon Skeet [C# MVP] wrote:
> [Side-note: Hi Patricia! Good to be chatting again... it's been a long
> time.]
>
> Patricia Shanahan <pats@acm.org> 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

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

Patricia Shanahan <pats@acm.org> 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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

Mark Thornton <mthornton@optrak.co.uk> 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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

Razii <nikllpgfsdb@mail.com> 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.999999999999998667732370449812151491641998291015 625 (2/3)^k
3160.81762188707580207847058773040771484375 k^-0.5
0.999999600000204380556567684834590181708335876464 84375 1/k(k+1)
30.31454150956249549153653788380324840545654296875 Flint Hills
42.99523399808393975263243191875517368316650390625 Cookson Hills
15.30901715473919821874915214721113443374633789062 5 Harmonic
1.644933666848367392887553251057397574186325073242 1875 Riemann Zeta
0.693146980560093828316325925698038190603256225585 9375 Alt. Harmonic
0.785398063397435564070292457472532987594604492187 5 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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

Jon Skeet [C# MVP] wrote:
> Mark Thornton <mthornton@optrak.co.uk> 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

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

Mark Thornton <mthornton@optrak.co.uk> 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 - <skeet@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com