Add support for Floating-Point theory (currently cvc5 only)#428
Add support for Floating-Point theory (currently cvc5 only)#428augustomafra wants to merge 8 commits intostanford-centaur:mainfrom
Conversation
|
Hi, @CyanoKobalamyne , I see that one CI test failed on my fork with "ERROR: Could not install packages due to an OSError: [Errno 28] No space left on device". Is there anything I can set on my end to have this test running on github? I relaunched it a couple of times but still hit the same issue. Thanks! |
c462a31 to
b50c8c9
Compare
95dfc7a to
63258f7
Compare
|
Hi, @CyanoKobalamyne , Could you or other project maintainers share feedback about this PR? Thanks! |
yoni206
left a comment
There was a problem hiding this comment.
Hi @augustomafra and thanks for this PR, and sorry for the delay!
It would be great for smt-switch to support floating points.
In addition to the inline comments, could you add tests to the PR? I think it would make sense to add cvc5 tests here:
https://github.com/augustomafra/smt-switch/tree/63258f708b798a34a46a6ddaf7252ece4612af5b/tests/cvc5
and more generic tests (though they would now only run with cvc5) here:
https://github.com/augustomafra/smt-switch/tree/63258f708b798a34a46a6ddaf7252ece4612af5b/tests
This would include updating this file:
https://github.com/augustomafra/smt-switch/blob/63258f708b798a34a46a6ddaf7252ece4612af5b/tests/available_solvers.cpp
| UBV_To_FP, | ||
| FP_To_UBV, | ||
| FP_To_SBV, | ||
| FP_To_REAL, |
There was a problem hiding this comment.
Can you also add python bindings as mentioned in the line below?
| FLOAT32, | ||
| FLOAT64, |
There was a problem hiding this comment.
Is there a reason only these two are added, and not generic floats, indexed by integer parameters? This would be then more consistent with the SMT-LIB standard, and can be done similarly to bit-vectors.
There was a problem hiding this comment.
Agreed, I will work on switching to the generic float type.
At first I assumed specialized types would be easier to adopt for my application, but when advancing in the project I noticed that I spent more effort in getting the indexes for each type when translating to the solver APIs. The templates were a way to work around that, but as you commented below, they shouldn't be needed anymore after changing to general floats.
| template <SortKind sk> | ||
| struct FPSizes; | ||
|
|
||
| template <> | ||
| struct FPSizes<FLOAT32> | ||
| { | ||
| static constexpr uint32_t exp = 8; | ||
| static constexpr uint32_t sig = 24; | ||
| static constexpr uint32_t size = exp + sig; | ||
| }; | ||
|
|
||
| template <> | ||
| struct FPSizes<FLOAT64> | ||
| { | ||
| static constexpr uint32_t exp = 11; | ||
| static constexpr uint32_t sig = 53; | ||
| static constexpr uint32_t size = exp + sig; | ||
| }; |
There was a problem hiding this comment.
templates are rare in smt-switch so far, and i wonder if we really need them here.
|
Hi, @yoni206 , thanks for the directions! |
Adding sort and operation definitions for Floating-Point support on smt-switch.
This is a first step for other upcoming changes on pono's SMV frontend encoding problems on the theory of Floating-Point arithmetic.