-
Notifications
You must be signed in to change notification settings - Fork 56
Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512
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
base: master
Are you sure you want to change the base?
Changes from 63 commits
6a91ebf
5c86496
06e365f
d00e534
bc5a5e3
6e6ec7e
f584f6b
9df8f21
105e7f2
4ec7107
97c1fe4
fdaabcc
3ecd133
52dbeb5
353b12c
6c554d0
9603aa6
1f09a65
43ee2a0
a27cc7e
de90781
b652b7f
11926f1
17227ac
31ffd68
3cc3a99
cd3a9c1
2fbe5bd
b789362
2fc661c
7b2b1de
dbacf94
2d27890
15efd20
ba26c93
9c72a5b
85a5b4e
edf028d
567e120
87a90df
6fa0b35
68aa184
de440e1
8973957
bfe56ac
aae26af
95bd69b
638472c
faca8c9
8f3a60e
7b2b45b
ddfac9d
2fc367e
275802e
e5e0c81
10df745
9a27db3
1b6a671
24230d9
76ffa33
41c0784
f805aeb
a824dac
2ada968
2f98439
9e0eee4
f7ac283
1b227a2
9f63898
72ad0e3
1a5e5dc
86c4ab8
914d367
dba1560
31d23af
45e6c92
e424dfd
9230799
a9a111f
6b97afc
37d5fce
955c029
ddc38ce
2405704
a669c12
5501179
81a928c
4ffac52
a7036ef
69f86ff
332e001
b2ca7fe
3a94b47
22473cf
3d99c92
bb10cdb
ba1ef64
6d32196
1997b3a
c2601e6
0c8d8f6
2343880
7114c51
7d9bbe7
7d0fdaa
779a4cc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -299,12 +299,50 @@ FloatingPointFormula castFrom( | |
| FloatingPointFormula fromIeeeBitvector(BitvectorFormula number, FloatingPointType pTargetType); | ||
|
|
||
| /** | ||
| * Create a formula that produces a representation of the given floating-point value as a | ||
| * bitvector conforming to the IEEE 754-2008 FP format. The bit size of the resulting bitvector is | ||
| * equal to the total size of the {@link FloatingPointNumber}s precision. | ||
| * Returns a {@link BitvectorFormula} equal to the representation of the given floating-point | ||
| * value as a bitvector conforming to the IEEE 754-2008 FP format. The bit size of the resulting | ||
| * bitvector is equal to the total size of the {@link FloatingPointFormula}s {@link | ||
| * FloatingPointType}. This method is not natively supported by all solvers, and SMTLIB2 output | ||
| * generated containing formulas originating from this method is often not parsable by other | ||
| * solvers. You can use the method {@link #toIeeeBitvector(FloatingPointFormula, | ||
| * BitvectorFormula)} to avoid both problems. | ||
| */ | ||
| BitvectorFormula toIeeeBitvector(FloatingPointFormula number); | ||
|
|
||
| /** | ||
| * Create a {@link BooleanFormula} representing the equality of the bitvector representation of | ||
| * the given {@link FloatingPointFormula}s value with the given {@link BitvectorFormula}, | ||
| * conforming to the IEEE 754-2008 floating-point format. The size m of the given {@link | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
| * BitvectorFormula} has to be equal to the sum of the sizes of the exponent eb and mantissa sb | ||
| * (including the hidden bit) of the given {@link FloatingPointFormula}. This implementation can | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
| * be used independently of {@link #toIeeeBitvector(FloatingPointFormula)}, as it does not rely on | ||
| * an SMT solvers support for {@link #toIeeeBitvector(FloatingPointFormula)}. Behavior for special | ||
| * FP values (NaN, Inf, etc.) is not defined, and returned values are solver dependent. This | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. First, there are no "returned values" here. Second, if behavior is simply mentioned as "not defined" it means that probably almost no caller can safely use it without wrapping it in lots of ITEs, creating a trap in the API. After all, the best way to do something should also be the easiest way. But I suspect that "not defined" is not really true and one can rely on some behavior rules, just that these are more vague than for other operations, right? What are these rules? For example, can I rely on the fact that if the float is a NaN that there is at least one bv value that is determined as equal to it? And that no bv value that has a defined float representation could compare as equal to a NaN value?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
SMTLIB2 applies. Meaning that, from the point of view of SMTLIB2, there is only one NaN etc. The solvers do accept all valid NaN BV representations when transforming from BV to FP as NaN. But they return just one canonical FP NaN representation per default. I added a test for this. Btw. i checked the default BV representations of NaN in all solvers. Some examples:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
All BV NaN representations seem to work as NaN. When transformed to FP, they are canonized. They do not compare equal as FPs. Fun fact: no SMT solver returns the same bit representation for NaN as bitvector that is used in the floating-point number when transforming via
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now the JavaDoc just says "Behavior for special FP values (NaN, Inf, etc.), is solver dependent." Wasn't there an explanation about how to handle this at some point, i.e., the hint to handle special values manually by adding conditions?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but everyone working with SMT should know how to do this. It might even be dangerous to mention it here; if they don't also modify other sources of BV/FP constants/conversions, unexpected behavior might ensue. If we knew enough about how these things work or the details, i would be in favor of providing this information. Currently, i don't think that we have the full picture.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added some new tests for this; when transforming bitvectors to FP numbers, their model values still represent the original BV. So there should not be a problem. If problems arise, we could provide an option that ensures that this operation, as well as its inverse function, return values that are equal in all solvers that support it. I would recommend that CPAchecker switches to using the newly implemented method of this PR per default, as then the SMTLIB2 output of each solver supporting BV to/from FP is parsable by every other solver that supports it. This would also result in some integration/usage testing. (I can take care of this)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are saying "I would recommend that CPAchecker switches to using the newly implemented method" and also "everyone working with SMT should know how to do this" with respect to handling of special values. But honestly, from reading the JavaDoc it would not be clear to me what I have to do in order to properly migrate the code in CPAchecker to the new method.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I recommend switching because then more solvers can be used with this feature and the SMTLIB2 output of solvers using this new call, instead of As for the special FP values; I don't think that we should be the canonical source of information about these beyond the standard or the solvers. It is unfortunate that there is not much to go by, but i want to avoid putting wrong information out there. The tests give a base sense of what is happening, but we can not guarantee that the behavior is always like this!
You create a new bitvector variable, replace The problem here is less the new API in my opinion, but the old one that does not stick to the standard.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But how do I handle special values? This is what you referred to with "everyone working with SMT should know how to do this", but I don't know what I need to do and you also didn't answer this in your response.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The easiest is using ITE constructs, but you can of course use any logical formula that fits your purpose. You can for example check the bits in the bitvector (that is equal to your FP number) for the NaN pattern, and if it is some NaN, you return a single, canonical NaN, else the initial bitvector. Note: maybe a public example (not a test) that shows exactly this would be a good idea? |
||
| * method is based on a suggestion in the (<a | ||
| * href="https://smt-lib.org/theories-FloatingPoint.shtml">SMTLIB2 standard</a>), with eb being | ||
| * the {@link FloatingPointFormula}s exponent bit size, sb being its mantissa with the hidden bit, | ||
| * and eb + sb equal to the bit size of the used {@link BitvectorFormula} parameter, illustrated | ||
| * in SMTLIB2 as: | ||
| * | ||
| * <p>(= ((_ to_fp eb sb) bitvectorFormulaSetToBeEqualToFpNumber) fpNumber) | ||
| * | ||
| * <p>Example usage in SMTLIB2, asserting the equality of the 2 parameters: | ||
| * | ||
| * <p>(declare-fun bitvectorFormulaSetToBeEqualToFpNumber () (_ BitVec m)) | ||
| * | ||
| * <p>(assert (= ((_ to_fp eb sb) bitvectorFormulaSetToBeEqualToFpNumber) fpNumber)) | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
| * | ||
| * <p>Note: SMTLIB2 output of this method uses the SMTLIB2 keyword 'to_fp' as described above. | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
| * | ||
| * @param fpNumber the {@link FloatingPointFormula} to be converted into an IEEE bitvector. | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
| * @param bitvectorFormulaSetToBeEqualToFpNumber a {@link BitvectorFormula} that is set to be | ||
| * equal to the IEEE bitvector representation of the {@link FloatingPointFormula} parameter. | ||
| * @return a {@link BooleanFormula} representing the result of the equality of the two parameters, | ||
| * i.e. (= ((_ to_fp eb sb) bitvectorFormulaSetToBeEqualToFpNumber) fpNumber). | ||
| */ | ||
| BooleanFormula toIeeeBitvector( | ||
| FloatingPointFormula fpNumber, BitvectorFormula bitvectorFormulaSetToBeEqualToFpNumber); | ||
|
PhilippWendler marked this conversation as resolved.
Outdated
|
||
|
|
||
| FloatingPointFormula round(FloatingPointFormula formula, FloatingPointRoundingMode roundingMode); | ||
|
|
||
| // ----------------- Arithmetic relations, return type NumeralFormula ----------------- | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.