@karlos:
Difficult to answer that (for me) I didn't tested it in detail.
Disclaimer: can be completely wrong what I write here, just some very
basic tests on the surface where done! Don't slaughter me if it is completely BS.
https://blog.alb42.de/2018/03/03/vampire-2-7-fpu-part-2/ just this test as you see the
b := b * 1.0000000001;
Needs 11 significant decimals precision
Single has 6-9 significant decimals
Double had 15-17 significant decimals
Vampire (at the current released Version 2.7) does not see this
1 at the 11. position.
That means it has less than 11 significant decimals.
I remember I tried with 9 and it somehow worked (with large
error but that is to be expected at the edge of precision)
So it
looks like it uses like single 23 bits for the significant
but it's not Single/32 bit because the numbers can still go up to 10^308
That means the exponent is still 11 bits long as you would expect
for a Double/64 bit.
So it's something new ;-) the VampireDouble with 23 bit significant 11 bit exponent (and a sign bit)
35 bit (but of course in memory the length of 64 bit)
I hope that make some sense.
It could be (and this is what I hope :-P) that this was a bug and solved with the Round() Bug they already solved.
Therefore I'm very careful to claim that all as a fact and continue to investigate when the new fixed version is out.
But the exact information only Gunnar can give you I guess.
My understanding is that its "not quite 64 bit IEEE" due to some current limitations imposed by gate counts.
Sure, that's the reason, but
my preferred solution would be to make the Single/32 bit calculations in the FPGA and double/extended trap like before to FEmu. or something like this. But maybe they tried but didn't worked as expected.