Closed Ravenwater closed 6 years ago
Update: exploring the state space, I have been able to make a specific es (0, and 1) work, but have not been able to find the equation that is correct for the parameterization. The detail here is that as the parameterization grows the exponent field, the boundary conditions change. The case in point is the first exponent, that is, es = 1. It will shift the scale to 2, 4, 6, etc. and the exponent calculation now needs to deal with the ambiguity of (scale >> es). For example, scale 4 and 5 both map to 4, but their rounding behavior is opposite: a little bit less on scale 5 number needs to project to scale 6, a little bit less on scale 4 number projects to scale 4.
New algorithm based on composing an unconstrained posit, determining how to round when truncating, then truncating and conditionally incrementing. That algorithm appears to be consistent across the parameterization of the posit configurations.
There is a known issue of the library making an incorrect rounding choices for posit configurations with exponent bits. It is related to the logic to deal with geometric rounding when bits propagate from the exponent field to the regime field.
The current design tries to create combinatoric equations to set the bits as it tries to model how hardware would compute these fields. The data path pipeline is set up as a floating point value pipeline with values being represented by their triple (sign, binary scale, fraction without hidden bit). As we are trying to reinterpret a triple into a posit triple (regime, exponent, fraction without hidden bit) there is ambiguity how to set up the equations for regime and exponent extractions as a function of nbits and es. This ambiguity appears to be the cause for this particular bug.