You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal here is to develop a type check for "unproven" types (e.g. i8 versus i8@prove, etc). Two approaches:
(Simple) We could use integer range analysis, along with bounded unrolling to given a quick-and-dirty check. This would unroll a given module to some number of rows, then fill in all proven columns with their ranges and then try to deduce the rest. I don't know whether this will work well, however, for modules with CT_MAX. The problem being that these modules have variable rows per call, and this will interfere. We could hard-code knowledge of CT_MAX.
(Non-inductive Proof) We can improve upon the above by using a simple decision procedure for inequalities and, again, unrolling to some depth.
(Inductive Proof) Perhaps the hardest, but also the most powerful.
The text was updated successfully, but these errors were encountered:
The goal here is to develop a type check for "unproven" types (e.g.
i8
versusi8@prove
, etc). Two approaches:CT_MAX
. The problem being that these modules have variable rows per call, and this will interfere. We could hard-code knowledge ofCT_MAX
.The text was updated successfully, but these errors were encountered: