Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512

baierd · 2025-09-01T14:08:15Z

This PR adds 2 fallback methods for FloatingPointManager.toIeeeBitvector(FloatingPointFormula):

FloatingPointManager.toIeeeBitvector(FloatingPointFormula, String), returning the BV representation as a new variable with the given name. Special FP numbers are returned as the solver sees fit.
FloatingPointManager.toIeeeBitvector(FloatingPointFormula, String, Map<FloatingPointFormula, BitvectorFormula>), returning the BV representation as a new variable with the given name. Special FP numbers can be mapped to expected results, with the default behavior (if no mapping has been added) being like the previous method.

Both return a tuple BitvectorFormulaAndBooleanFormula, representing the bitvector of the input FP number, as well as the additional constraint needed as BooleanFormula. The constraint needs to be added to all assertion stacks that make use of the returned BitvectorFormula.

While implementing i found a problem in our implementation of FloatingPointType. Our returned significant precision is off by one. E.g. for single precision FP, we return significant size 23. But the standard defines exponent and significant as:

eb defines the number of bits in the exponent;
sb defines the number of bits in the significand, *including* the hidden bit.

Hence it should be 24.
As a consequence, we also return this wrongly for toSMTLIBString().

The solvers generally expect this to be the case, hence why we had 4 solvers with the code type.getMantissaSize() + 1, and only one solver without the + 1

Also, we don't communicate any information about our interpretation of FP precisions, hence the users might think that by building FormulaType.getFloatingPointType(8, 24) (first input is exponent, second is significant) they get a single precision FP-type, but in reality they get a total size of 33 bits currently. Our static implementation of the single/double precisions is fine however.

I added the capability to retrieve the precision from the solver directly, instead of using the JavaSMT type, as this was needed for this implementation. ~~This addition is currently hidden from users, but could be exposed if needed.~~ I exposed this API publicly, as it seems to fit well with getSize() for bitvectors, and offers a type-independent, solver based way of getting the FP sizes.

…traint is not handed to the user

…gestion + add helper to get mantissa and exponent sizes for FPs (not finished for all solvers)

…n of user defined results for special FP numbers

…ll BV capable solvers

…ings and add it to JavaDoc

…BV transformation and width comparison

…umber mapping) and a test for FP size/mantissa/exponent in relation to BV width for toIeeeBitvector()

…ulaManager (based on solver return)

…d text for native toIeeeBitvector() in AbstractFloatingPointFormulaManager

baierd · 2025-09-01T16:24:23Z

@kfriedberger the SMTLIB2 standard defines the size of an FP as mantissa + exponent with the mantissa including the sign bit. Our current implementation excludes it, and we do not document this properly in all cases, especially the FP type constructor.

This is problematic, as the standard defines the size of a BV representation of a FP as mantissa + exponent, which is off by 1 in our returned values (this is how i noticed btw.).

My proposal (already WIP):

Fix FP type etc. to include the sign bit, and switch to what the standard defines in our internal implementation. Only MathSAT5 expects the mantissa to not include the sign bit.
Announce the FP type constructor to be deprecated in the near future due to this.
Add new constructors for FP type that specify the inclusion in the method name.
Add methods to get the sizes of mantissa and exponent to FloatingPointFormulaManager based on the solvers terms instead of our types (similar to what we do for BV width), allowing assertions and checking the solvers interpretation for our type.

I don't want to change the current FP-Type constructor, as users expect this to not change behavior.

What do you think? I am happy about thoughts/ideas.

Edit: it would probably be a good idea to also update the API for getMantissaSize() to getMantissaSizeWithSignBit() and getMantissaSizeWithoutSignBit() and deprecate the old method.

…tMantissaSizeWithSignBit() +

…he type/mantissa with/without sign bit and add sign bit to toString and toSMTLIBString representations

…a with/without sign bit and use those as far as possible to make the code unambiguous for mantissas

…IEEE BV method availability

…n bit and add some assertions for mantissa/exponent

…guous about the sign bit

…h new mantissa API

…heck against in FP toIeeeBitvector()

… the re-mapping of special values

baierd · 2025-09-02T07:08:12Z

Do we want to document the typical returns of solvers for special FP numbers? There are multiple well defined return values for NaN as bitvector for example.

baierd · 2025-09-02T07:09:38Z

@kfriedberger the SMTLIB2 standard defines the size of an FP as mantissa + exponent with the mantissa including the sign bit. Our current implementation excludes it, and we do not document this properly in all cases, especially the FP type constructor.

This is problematic, as the standard defines the size of a BV representation of a FP as mantissa + exponent, which is off by 1 in our returned values (this is how i noticed btw.).

My proposal (already WIP):
* Fix FP type etc. to include the sign bit, and switch to what the standard defines in our internal implementation. Only MathSAT5 expects the mantissa to not include the sign bit.

* Announce the FP type constructor to be deprecated in the near future due to this.

* Add new constructors for FP type that specify the inclusion in the method name.

* Add methods to get the sizes of mantissa and exponent to `FloatingPointFormulaManager` based on the solvers terms instead of our types (similar to what we do for BV width), allowing assertions and checking the solvers interpretation for our type.
I don't want to change the current FP-Type constructor, as users expect this to not change behavior.

What do you think? I am happy about thoughts/ideas.

Edit: it would probably be a good idea to also update the API for getMantissaSize() to getMantissaSizeWithSignBit() and getMantissaSizeWithoutSignBit() and deprecate the old method.

I mostly finished this as proposed. You can take a look. I feel like the API changes reduce the magic + 1 and - 1 by a large amount, increasing readability of the code. My guess is that users, especially new users, will benefit from that. The deprecation warning needs to be discussed/done.

…gnBitImpl() to reduce ambiguity + improve name of variable

baierd · 2025-09-02T08:33:23Z

I now split all changes in regard to FP mantissa into a dedicated PR here. We should first handle that PR, merge it, and then continue here.

…) instead of new implementation

kfriedberger

I am unsure whether this special handling for FP2IEEEBV is really required. This feature looks errorprone and quite complex to understand. I would prefer that solvers provide their internal implementation for this, and JavaSMT just provides the wrapper/bindings instead of such parts. There might be potential, but also the burden for the developer, especially when using a method that returns additional constraints.

kfriedberger · 2025-09-03T19:55:10Z

src/org/sosy_lab/java_smt/api/FormulaType.java

+   */
+  public static FloatingPointType getFloatingPointTypeWithSignBit(
+      int exponentSize, int mantissaSizeWithSignBit) {
+    return new FloatingPointType(exponentSize, mantissaSizeWithSignBit);


Where is the difference in this method to the one before? Both methods create the same object with the same parameters, even if they are named differently.

kfriedberger · 2025-09-03T19:56:31Z

src/org/sosy_lab/java_smt/api/FloatingPointNumber.java

+   * Returns the size of the mantissa (also called a coefficient or significant), excluding the sign
+   * bit.
+   */
+  // TODO: mark as soon to be deprecated


Do we really want to remove this simple method? Is the documentation not sufficient?

Please provide a replacement code snippet for inlining deprecated code.

kfriedberger · 2025-09-03T19:59:39Z

src/org/sosy_lab/java_smt/basicimpl/AbstractFloatingPointFormulaManager.java

+            + "methods toIeeeBitvector"
+            + "(FloatingPointFormula, String) and/or "
+            + "toIeeeBitvector(FloatingPointFormula, String, Map)");
+  }


This message is quite misleading: The message will be seen by a user of the application, not by the developer calling JavaSMT. How will the user of the application (e.g., CPAchecker) change that call? That might be impossible.

kfriedberger · 2025-09-03T20:03:42Z

src/org/sosy_lab/java_smt/basicimpl/AbstractFloatingPointFormulaManager.java

@@ -519,4 +621,28 @@ protected static String getBvRepresentation(BigInteger integer, int size) {
    }
    return String.copyValueOf(values);
  }
+
+  public static final class BitvectorFormulaAndBooleanFormula {


Why not just use a Google-Auto-class? In the future this might be a record.

kfriedberger · 2025-09-03T20:04:23Z

src/org/sosy_lab/java_smt/basicimpl/AbstractFloatingPointFormulaManager.java

+  }
+
+  @Override
+  public BitvectorFormulaAndBooleanFormula toIeeeBitvector(


This method is weird. Does is really handle NaN as expected?

kfriedberger · 2025-09-03T20:07:30Z

src/org/sosy_lab/java_smt/api/FloatingPointFormulaManager.java

+  int getMantissaSizeWithSignBit(FloatingPointFormula number);
+
+  /** Returns the size of the exponent for the given {@link FloatingPointFormula}. */
+  int getExponentSize(FloatingPointFormula number);


Do we really need these two methods?
The user already can access the FormulaType directly and extract exponentSize and mantissaSize from the returned FP-FormulaType.

kfriedberger · 2025-09-03T20:08:15Z

src/org/sosy_lab/java_smt/solvers/bitwuzla/BitwuzlaFloatingPointManager.java

+  protected int getExponentSizeImpl(Term fp) {
+    return fp.sort().fp_exp_size();
+  }
+


I doupt the requirement for these two methods.

BaierD added 12 commits August 13, 2025 19:43

Remove workaround for toIeeeBitvector() in Bitwuzla as the extra cons…

6a91ebf

…traint is not handed to the user

Add fallback for toIeeeBitvector() based on the SMTLIB2 standards sug…

5c86496

…gestion + add helper to get mantissa and exponent sizes for FPs (not finished for all solvers)

Add extended toIeeeBitvector() fallback implementation with the optio…

06e365f

…n of user defined results for special FP numbers

Add bool manager to all FP managers for new toIeeeBitvector() impl

d00e534

Simplify toIeeeBitvector() fallback implementation

bc5a5e3

Add CVC4 implementation for getMantissaSize() and getExponentSize()

6e6ec7e

Add CVC5 implementation for getMantissaSize() and getExponentSize()

f584f6b

Add Mathsat5 implementation for getMantissaSize() and getExponentSize()

9df8f21

Add Z3 implementation for getMantissaSize() and getExponentSize()

105e7f2

Add internal API to retrieve the width of a BV and implement it for a…

4ec7107

…ll BV capable solvers

Add test for FP special number identity for equal precisions

97c1fe4

Add preconditions for FP toIeeeBitvector() method special number mapp…

fdaabcc

…ings and add it to JavaDoc

baierd self-assigned this Sep 1, 2025

baierd linked an issue Sep 1, 2025 that may be closed by this pull request

IEEE Floating-point to Bitvector Conversion Not Supported in All Solvers #504

Open

BaierD added 7 commits September 1, 2025 17:21

Add native Mathsat test for mantissa not including the sign bit with …

3ecd133

…BV transformation and width comparison

Add tests for FP toIeeeBitvector() fallback (without custom special n…

52dbeb5

…umber mapping) and a test for FP size/mantissa/exponent in relation to BV width for toIeeeBitvector()

Add public API to get exponent and mantissa size in FloatingPointForm…

353b12c

…ulaManager (based on solver return)

Add note about mantissa und sign bit in FloatingPointNumber.java

6c554d0

Remove accidental double implementation of bitvector width getter

9603aa6

Use existing BV size getter + make size getters for FP public + exten…

1f09a65

…d text for native toIeeeBitvector() in AbstractFloatingPointFormulaManager

Extend delegate FloatingPointManagers with FP size methods

43ee2a0

BaierD added 8 commits September 1, 2025 19:36

Rename new FloatingPointFormulaManager method getMantissaSize() to ge…

a27cc7e

…tMantissaSizeWithSignBit() +

Add JavaDoc to FormulaType.FloatingPointType and add methods to get t…

de90781

…he type/mantissa with/without sign bit and add sign bit to toString and toSMTLIBString representations

Add JavaDoc to FloatingPointNumber and add methods to get the mantiss…

b652b7f

…a with/without sign bit and use those as far as possible to make the code unambiguous for mantissas

Add suppression of return value to test method checking native FP to …

11926f1

…IEEE BV method availability

Extend FP tests with new mantissa API to be unambiguous about the sig…

17227ac

…n bit and add some assertions for mantissa/exponent

Extend FloatingPointFormulaManager with new mantissa API to be unambi…

31ffd68

…guous about the sign bit

Rename getMantissaSize() in FloatingPointFormulaManager delegates wit…

3cc3a99

…h new mantissa API

Update Bitwuzla with new unambiguous FP mantissa size getters

cd3a9c1

BaierD added 8 commits September 1, 2025 19:43

Update CVC4 with new unambiguous FP mantissa size getters

2fbe5bd

Update CVC5 with new unambiguous FP mantissa size getters

b789362

Update MathSAT5 with new unambiguous FP mantissa size getters

2fc661c

Update Z3 with new unambiguous FP mantissa size getters

7b2b1de

Update SolverVisitorTest with new unambiguous FP mantissa size getters

dbacf94

Use mantissa size without sign bit when building special numbers to c…

2d27890

…heck against in FP toIeeeBitvector()

Fix off-by-one FP mantissa bug when casting BV to FP

15efd20

Extend FP tests with new tests for toIeeeBitvector() fallback testing…

ba26c93

… the re-mapping of special values

baierd requested a review from kfriedberger September 2, 2025 07:05

Remove done TODO

9c72a5b

Rename internal method getMantissaSizeImpl() to getMantissaSizeWithSi…

85a5b4e

…gnBitImpl() to reduce ambiguity + improve name of variable

baierd mentioned this pull request Sep 2, 2025

Fix Floating-Point Mantissa Not Including Sign Bit #513

Open

BaierD added 2 commits September 2, 2025 10:38

Apply checkstyle and ECJ suggestions

edf028d

Use type information for FP exponent and mantissa in toIeeeBitvector(…

567e120

…) instead of new implementation

kfriedberger reviewed Sep 3, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512

Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512

Uh oh!

baierd commented Sep 1, 2025 •

edited

Loading

Uh oh!

baierd commented Sep 1, 2025 •

edited

Loading

Uh oh!

baierd commented Sep 2, 2025

Uh oh!

baierd commented Sep 2, 2025 •

edited

Loading

Uh oh!

baierd commented Sep 2, 2025

Uh oh!

kfriedberger left a comment

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

kfriedberger Sep 3, 2025

Uh oh!

Uh oh!

Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512

Are you sure you want to change the base?

Add IEEE-754 Floating Point to Bitvector Conversion Fallback #512

Uh oh!

Conversation

baierd commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baierd commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baierd commented Sep 2, 2025

Uh oh!

baierd commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baierd commented Sep 2, 2025

Uh oh!

kfriedberger left a comment

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

kfriedberger Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

baierd commented Sep 1, 2025 •

edited

Loading

baierd commented Sep 1, 2025 •

edited

Loading

baierd commented Sep 2, 2025 •

edited

Loading