[Libre-soc-bugs] [Bug 196] Formal correctness proof needed for the IEEE754 FPU
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon May 9 20:13:47 BST 2022
https://bugs.libre-soc.org/show_bug.cgi?id=196
--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #6)
> if we just rehashed the implementation verbatim in the formal correctness
> proof, then we'd be lying if we said the formal proof was any better than
> the original unknown-correctness nmigen code, we'd only be checking that the
> original code gives the same answers when run in a formal proof, not that
> those answers are actually correct.
the idea was even worse than that :) just do a real basic proof of
"the normalisation class" and so on. it was not a serious suggestion
but one that is easy to do and perhaps might work if they are chained
together then tested against other implementations.
> >
> > 2) reimplement (effectively) the algorithms in "simple" (obvious)
> > reviewable fashion and use straight "equals"
>
> that requires the fp code we have to implement at least one of the rounding
> modes correctly, otherwise it'll give different results than the formal
> proof's correct rounding, causing the equality to fail. this also kinda
> requires real numbers to compute the correctly rounded result to compare
> against.
we discussed the flexible solution here to not implement rounding yet and
come back to it later during a second phase.
the proof would also not have rounding and would also have it added later.
> >
> > 3) compute error-bounds (erf, error-function) and check results
>
> that generally requires real numbers of some sort...
ah no. i mean in digital form. express the expected difference in
digital form. similar to that Goldberg iteration checking thing.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list