In Standard Honk, relations were introduced to represent individual polynomial constraints, i.e. the number powers of alpha needed to construct the larger sumcheck relation is equal to the number of relations. This allows us to defer multiplication by alpha when batching relation contributions in a way that saves a ton of field muls. For Ultra Honk it's less clear that this is the right approach. In the "elliptic widget" for example, there are really two relations, both of which require some common computation. If we split them into two relations as we've been doing, the savings we get from deferring multiplication by alpha may be outweighed by having to repeat otherwise shareable computations. It would also be convenient just for the sake of readability and code complexity. The "gen perm widget" is conceptually simple but is made up of 4 separate constraints and thus requires 4 powers of alpha. It would be nice to have a single object that handles this rather than 4 separate relations.
The current approach is to simply multiply by powers of alpha within certain ultra relations but this is technically not valid since it will lead to use of repeated powers of alpha in the batching process. An approach might be to make the external loop responsible for batching over all relations aware of the number of powers used by each relation so it can update accordingly.
In Standard Honk, relations were introduced to represent individual polynomial constraints, i.e. the number powers of alpha needed to construct the larger sumcheck relation is equal to the number of relations. This allows us to defer multiplication by alpha when batching relation contributions in a way that saves a ton of field muls. For Ultra Honk it's less clear that this is the right approach. In the "elliptic widget" for example, there are really two relations, both of which require some common computation. If we split them into two relations as we've been doing, the savings we get from deferring multiplication by alpha may be outweighed by having to repeat otherwise shareable computations. It would also be convenient just for the sake of readability and code complexity. The "gen perm widget" is conceptually simple but is made up of 4 separate constraints and thus requires 4 powers of alpha. It would be nice to have a single object that handles this rather than 4 separate relations.
The current approach is to simply multiply by powers of alpha within certain ultra relations but this is technically not valid since it will lead to use of repeated powers of alpha in the batching process. An approach might be to make the external loop responsible for batching over all relations aware of the number of powers used by each relation so it can update accordingly.