Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Math.Cos(double.MaxValue) returns different values on Windows and other platforms #5616

Closed
mellinoe opened this issue Apr 13, 2016 · 7 comments
Assignees
Labels
Milestone

Comments

@mellinoe
Copy link
Contributor

Scenario:

Console.WriteLine(Math.Cos(double.MaxValue));

Expected behavior

double.MaxValue is returned according to the .NET Framework documentation:

Acceptable values of d range from approximately -9223372036854775295 to approximately 9223372036854775295. For values outside this range, the Cos method returns d unchanged rather than throwing an exception.

Actual behavior

on Windows, double.MaxValue is returned. On my Ubuntu test machine, -0.999987689... is returned.

This may be an acceptable difference in behavior, as long as we've acknowledged it. It seems like we could easily match this behavior by doing some parameter boundary checks, but it may not be worth it. I'm assuming this behavior difference is coming from the native cosine functions we are using.

@gkhanna79
Copy link
Member

@janvorli PTAL

@janvorli
Copy link
Member

Here is top of the call stack of the Math.Cos invocation on Linux:

  * frame #0: 0x00007ffff73cacf0 libm.so.6`???
    frame dotnet/coreclr#1: 0x00007ffff6624df1 libcoreclr.so`COMDouble::Cos(d=1.7976931348623157E+308) + 49 at floatnative.cpp:147

and here is the source:

FCIMPL1_V(double, COMDouble::Cos, double d) 
    FCALL_CONTRACT;

    return (double) cos(d);
FCIMPLEND

So the behavior clearly reflects the C++ math library cos behavior on each platform.
I would prefer keeping it as is instead of adding the overhead of simulating the windows behavior.

@mellinoe
Copy link
Contributor Author

Yes, this is what I expected to be the cause, but it's good to have confirmation. I am fine with this behavior difference as well, but I wanted to call it out to make sure it had seen some scrutiny other than my own. I'm not sure if we have a list of such low-level behavioral differences, but if we do we should document this one.

@janvorli
Copy link
Member

I am not aware of such a list. @richlander do we have some doc where a list of platform specific differences as @mellinoe has suggested would fit?

@gkhanna79
Copy link
Member

@leecow @blackdwarf Can you please add this to the documented difference list we prepare for each release?

@janvorli
Copy link
Member

I can see a reference to this issue was added to https://github.com/dotnet/core/blob/master/release-notes/1.1/1.1.0-preview1-known-issues.md, so I am closing this issue.

@omajid
Copy link
Member

omajid commented Nov 18, 2016

Would adding a math library that has matching results on all platforms be worth it? Java has a StrictMath (separate from the regular Math) class that requires implementations to return values that match published algorithms.

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@msftgits msftgits added this to the 1.1.x milestone Jan 30, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Jan 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants