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
Summary
Rewrite
EmulatedFpVarto fix reduction issues inAllocatedMulResultVarand simplify the handling ofsurfeitvalues 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, withinAllocatedMulResultVar, theaddandadd_constantmethods do not perform proper reduction whenprod_of_num_of_additionsgrows 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
surfeitvalue. 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
BigNatParamis 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