-
Notifications
You must be signed in to change notification settings - Fork 8
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
Floating Point Verification Issues #158
Comments
Nagini currently treats all floating point operations as uninterpreted functions, i.e., it essentially knows nothing about what they do and therefore cannot prove anything about them. I've created a branch with experimental support for interpreted floating point values: https://github.com/marcoeilers/nagini/tree/floats The code isn't properly tested yet, and I'll probably add a warning when uninterpreted floats are used as you suggested. |
I tried using the ieee32 option on your example and a few variations and Nagini did actually terminate in ca. 42 minutes, but it could not prove the original example correct. However, this one worked:
This may mean that I got the encoding from integer literals to floats wrong, or that Z3 is incomplete here; I'll look at it when I have time. |
PR #160 is merged now. That means:
|
I don't know if this is a "bug" so much as a "limitation", but I figured I'd report it here anyway. Take the simple program
It is evident that
num * num > 0.0
will hold (regardless of the sign ofnum
, although we do restrict it to positive numbers), however the Nagini verifier reports:For comparison, here is a (nearly) equivalent program written in Dafny which does verify:
Now, I'm aware that Dafny's
real
is not an IEEE floating point type, but Python doesn't seem to natively provide a fixed-point type which can be checked. Perhaps Nagini could detect when the type is a float and indicate this might happen?The text was updated successfully, but these errors were encountered: