Add IEEE-754 Floating Point to Bitvector Conversion Fallback by baierd · Pull Request #512 · sosy-lab/java-smt

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

This PR adds a fallback method for FloatingPointManager.toIeeeBitvector(FloatingPointFormula):

FloatingPointManager.toIeeeBitvector(FloatingPointFormula, BitvectorFormula), returns a BooleanFormula that is the result of the equality of the FP input with the BV input (BV is equal to the floating-points bit representation according to the IEEE 754-2008 floating-point format). Special FP numbers are returned as the solver sees fit.

Tests for this method have been added. This includes the SMTLIB2 output of it, and the native toIeeeBitvector() method, showing us what solver can parse what output.

Furthermore, i added common FP type checks in the wrapping function of AbstractFloatingPointFormulaManager

…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

…resentation using fromIeeeBitvector() (BV -> FP)

…rsion-not-supported-in-all-solvers

…and +-Inf as bitvectors

…ither FP 0.0 or -0.0

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/basicimpl/AbstractFormulaManager.java

kfriedberger · 2026-02-27T22:20:04Z

+                + " operation by utilizing the 'to_fp' operation.";
+        throw new IllegalArgumentException(
+            illegalArgumentException.getMessage() + additionalMessage, illegalArgumentException);
+      }


4x getMessage --> maybe use a variable for that.

Done! Thanks for noticing!

I also extracted it into a method and moved the call due to how parsing was changed in parseAll().

kfriedberger · 2026-02-27T22:25:09Z

+   *     only used to verify the exponent and mantissa sizes of pTerm.
+   * @return input term pTerm in a {@link FloatingPointFormula}.
+   */
+  protected FloatingPointFormula wrapFloatingPointAndAssertType(


Why not just keep the name wrap and make it so complex?

The more detailed assertions were helpful when developing the BV-FP conversion, as the solvers handle things distinctly.

The check(s) are now assertions

kfriedberger · 2026-02-27T22:26:22Z

+    return getFormulaCreator().encapsulateFloatingPoint(pTerm);
+  }
+
+  protected FloatingPointFormula wrapFloatingPoint(TFormulaInfo pTerm) {


Is this second method really needed? Why not just name it wrap in this context?

I renamed both and simplified/combined them. This can of course also be done in a distinct way, but this implementation guarantees that we will always check the correct assertion.

Is this second method really needed?

It makes it easier to understand. The assertions were helpful when developing the BV-FP conversion, but are not strictly necessary. We can also use a single method that uses wrap(term, null) or so if you want.

kfriedberger · 2026-02-27T22:30:26Z

-                termManager.mk_term(Kind.FP_TO_FP_FROM_BV, bvVar, sizeExp, sizeSig),
-                pNumber));
-
-    bitwuzlaCreator.addConstraintForVariable(newVariable, equal);


Removing this piece of code will remove the reason for BitwuzlaFormulaCreator::constraintsForVariables. Please clean up the unused code there.

Good spot, thanks! I removed it.

kfriedberger · 2026-02-27T22:36:56Z

The idea of this PR is quite similar to the implementation of IntegerFormulaManager::modularCongruence, i.e., a left and right operand are combined and a boolean result is returned.

Some request from my side:

the naming is not optimal: toIEEEBitvector(fp, bv) should be renamed to equal/bitsEqual/bitwiseEqual(fp, bv), because this is the exact meaning: assignment/equality of bits and a symmetrical nature. The parameter name is ugly, too.
cleaning up special logic for basic contraints in solvers.

Overall, the idea is good. If it works for special cases like NaN, Inf, Subnormal, etc, then fine for me.

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/solvers/bitwuzla/BitwuzlaFloatingPointManager.java # src/org/sosy_lab/java_smt/solvers/cvc4/CVC4FloatingPointFormulaManager.java # src/org/sosy_lab/java_smt/solvers/cvc5/CVC5FloatingPointFormulaManager.java

…for old bv to fp workaround impl

…in Bitwuzla needed for old bv to fp workaround impl

…or msg

…ith better error msg

…or messages to a method and the invocation into parseAllImpl() as this is called for all parsing operations

…some more

…pected to throw, as if requireParser() fails, the test would fail with a weird error

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/basicimpl/AbstractFloatingPointFormulaManager.java # src/org/sosy_lab/java_smt/basicimpl/AbstractFormulaManager.java # src/org/sosy_lab/java_smt/solvers/bitwuzla/BitwuzlaFormulaCreator.java # src/org/sosy_lab/java_smt/solvers/cvc4/CVC4FormulaCreator.java # src/org/sosy_lab/java_smt/solvers/cvc5/CVC5FormulaCreator.java

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/basicimpl/AbstractFormulaManager.java

…nsive check and make the cheap checks message lazy

baierd · 2026-05-22T18:46:38Z

the naming is not optimal: toIEEEBitvector(fp, bv) should be renamed to equal/bitsEqual/bitwiseEqual(fp, bv), because this is the exact meaning: assignment/equality of bits and a symmetrical nature. The parameter name is ugly, too.

I chose toIEEEBitvector(fp, bv) as the SMTLIB2 standard defines this new implementation as the canonical way of implementing the functionality that we offer with the method toIEEEBitvector(fp). I would argue that changing the name could lead to users not understanding that this offers the same functionality.

Note: It returns a BooleanFormula only because the standard defines it that way. We could theoretically switch the bitvector and bool, such that a BitvectorFormula is returned, and a BooleanFormula is needed as argument. Alternativly: we can always just return a tuple of <BitvectorFormula, BooleanFormula>.

If it works for special cases like NaN, Inf, Subnormal, etc, then fine for me.

It works due to SMTLIB(2) only defining each special FP number only once. Hence "all" bitvector NaN representations return the "same" NaN (as defined by SMTLIB2). If translated back, the original bitvector is returned. I added tests for all special FP numbers that check this.

…rsion-not-supported-in-all-solvers

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 7 commits February 7, 2026 23:37

Fix problem with new FP test and add another new FP tests for NaN rep…

9f63898

…resentation using fromIeeeBitvector() (BV -> FP)

Merge branch 'master' into 504-ieee-floating-point-to-bitvector-conve…

72ad0e3

…rsion-not-supported-in-all-solvers

Rename NaN bit String variable in FP tests

1a5e5dc

Add a FP test for BV -> FP transformation for special FP numbers +-0 …

86c4ab8

…and +-Inf as bitvectors

Fix test in FloatingPointFormulaManagerTest in which solvers return e…

914d367

…ither FP 0.0 or -0.0

Format

dba1560

Merge branch 'master' into 504-ieee-floating-point-to-bitvector-conve…

31d23af

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/basicimpl/AbstractFormulaManager.java

kfriedberger reviewed Feb 27, 2026

View reviewed changes

baierd added this to the Release after 6.0.0 milestone Mar 1, 2026

baierd added enhancement API labels Mar 1, 2026

baierd added 16 commits March 26, 2026 17:03

Remove Bitwuzla internal tracking for "additional" assertions needed …

e424dfd

…for old bv to fp workaround impl

Remove methods for our internal tracking for "additional" assertions …

9230799

…in Bitwuzla needed for old bv to fp workaround impl

Re-use method return in a variable for parsing errors with better err…

a9a111f

…or msg

Correct oversight with double conditions for parsing error handling w…

6b97afc

…ith better error msg

Move re-throwing of IllegalArgumentException for improved parsing err…

37d5fce

…or messages to a method and the invocation into parseAllImpl() as this is called for all parsing operations

Simplify wrapping of FP terms in AbstractFloatingPointFormulaManager

955c029

Simplify wrapping of FP terms in AbstractFloatingPointFormulaManager …

ddc38ce

…some more

Add new method for cases in which checks that dump is parseable is ex…

2405704

…pected to throw, as if requireParser() fails, the test would fail with a weird error

Update switch case to J17 for BV to FP special value single prec FP test

5501179

Revert changes to IntelliJ misc

81a928c

Extend test for generic FP special number from BV and their model values

4ffac52

Merge branch 'master' into 504-ieee-floating-point-to-bitvector-conve…

a7036ef

…rsion-not-supported-in-all-solvers # Conflicts: # src/org/sosy_lab/java_smt/basicimpl/AbstractFormulaManager.java

Use assertion instead of precondition for FP type check for more expe…

69f86ff

…nsive check and make the cheap checks message lazy

Make other FP type check before wrapping an assertion as well

332e001

Merge branch 'master' into 504-ieee-floating-point-to-bitvector-conve…

b2ca7fe

…rsion-not-supported-in-all-solvers

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

Add IEEE-754 Floating Point to Bitvector Conversion Fallback#512
baierd wants to merge 92 commits into
masterfrom
504-ieee-floating-point-to-bitvector-conversion-not-supported-in-all-solvers

baierd commented Sep 1, 2025 •

edited

Loading

Uh oh!

baierd commented Sep 1, 2025 •

edited

Loading

Uh oh!

kfriedberger Feb 27, 2026

Uh oh!

baierd Mar 26, 2026

Uh oh!

kfriedberger Feb 27, 2026

Uh oh!

baierd Mar 27, 2026

Uh oh!

baierd May 22, 2026

Uh oh!

kfriedberger Feb 27, 2026

Uh oh!

baierd Mar 27, 2026

Uh oh!

baierd Mar 27, 2026

Uh oh!

kfriedberger Feb 27, 2026

Uh oh!

baierd Mar 26, 2026

Uh oh!

kfriedberger commented Feb 27, 2026

Uh oh!

baierd commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kfriedberger commented Feb 27, 2026

Uh oh!

baierd commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

baierd commented Sep 1, 2025 •

edited

Loading

baierd commented Sep 1, 2025 •

edited

Loading