Improve the robustness of EmulatedFpVar #192
Description
Summary
Rewrite EmulatedFpVar to fix reduction issues in AllocatedMulResultVar and simplify the handling of surfeit values by adopting a clearer, parameterized approach similar to bellman’s.
Problem Definition
As mentioned in #157, there are still some unresolved issues in the implementation of EmulatedFpVar. In particular, within AllocatedMulResultVar, the add and add_constant methods do not perform proper reduction when prod_of_num_of_additions grows too large. This can lead to correctness problems and makes the methods essentially unusable in practice.
Beyond this, I believe there is room for improvement in how we handle the surfeit value. Currently, there are many undocumented and complex uses of constants with surfeit values scattered throughout the codebase (for example, here and here), which makes the code harder to maintain and understand.
A potential improvement would be to follow bellman's approach, where a BigNatParam is stored alongside the limbs and encodes the maximum possible value for each limb. With this information, it becomes much easier to determine when reductions are necessary and how many limbs should be combined.
The tradeoff is a slight increase in memory usage (a few extra bytes per limb), but I believe this is justified unless there are hidden costs I may have overlooked. A careful rewrite would be needed to ensure correctness, but the payoff (clearer logic, more maintainable code, and better documentation) would be significant. During this process, we could also consider how to address #128 and #129, since bellman's implementation already captures some of this information.
I'd be really glad if someone takes this on, and I'd be happy to help review and support along the way.
Proposal
We should probably redesign and rewrite the EmulatedFpVar.
For Admin Use
- Not duplicate issue
- Appropriate labels applied
- Appropriate contributors tagged
- Contributor assigned/self-assigned