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

NaN result in a simple test #15

Open
monadius opened this issue Jul 17, 2016 · 5 comments
Open

NaN result in a simple test #15

monadius opened this issue Jul 17, 2016 · 5 comments
Assignees
Labels

Comments

@monadius
Copy link
Member

Test code:

var:  
[7.84, 8] x1;

cost:
sqrt(x1) * 1;

Result:

bin/dop_gelpia benchmarks/tests/sqrt.dop
[[2.82842712474619,NaN], {'x1' : [7.839999999999999, 8],}]
@monadius monadius added the bug label Jul 17, 2016
@monadius
Copy link
Member Author

Everything works well when the cost function is sqrt(x1)

@keram88 keram88 self-assigned this Jul 17, 2016
@keram88
Copy link
Member

keram88 commented Jul 17, 2016

This one will take a while to track down. If I print the result of the function call before returning, then everything works correctly. This suggests some undefined behavior.

I'll see if I can reproduce it in c++.

@keram88
Copy link
Member

keram88 commented Jul 17, 2016

This occurs for all expressions of the form x * sqrt(y), x/sqrt(y), sqrt(y)*x, sqrt(y)/x

@keram88
Copy link
Member

keram88 commented Jul 19, 2016

The newest version appears to fix this issue. In the past I've seen Rust compiler issues with SIMD values where the result of a function (in the xmm0 register) has to be observed forcefully for the return value to actually be read.

There was an issue from an old Rust compiler where the caller of a function returning a SIMD value would read the result from the eax register instead of xmm0; Gelpia used to have inline assembly code to force the return value to be read. This was fixed in some Rust version.

I'll leave this open since I'd like to do an assembly level analysis (😷) to see what the difference between the existing code and the previous code is. It may be another Rust bug.

@keram88 keram88 mentioned this issue Jul 21, 2016
@keram88
Copy link
Member

keram88 commented Jul 21, 2016

The old build.sh passed the --disable-preserve-rounding flag to configure while building GAOL. The new script in 99b9735 builds GAOL in the untrusted rounding mode. Historically, gelpia checked that the FP rounding mode never changed. This remained true for a long time, and the checks were removed. Evidently, our new code or modifications to the Rust compiler has introduced rounding mode changes. The erroneous results in issue #17 and this issue are caused by GAOL returning empty intervals which occurs if the upper bound is less than the lower bound.

To take advantage of this, it is necessary to do
make clean; make clean-requirements; make requirements; make

We will have to assess the performance impact of this change, but correctness comes first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants