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
SaturatingNum's SatSymmetric computations on signed integers only saturate to the symmetric lower bound on overflow of the computation, but not if the result is minBound. One would expect SatSymmetric computations to not have a bias, but the computations do have a slight bias this way.
Clash.Prelude P> P.map (\n -> satSub SatSymmetric n 1 :: Signed 4) [(-8) .. (-5)]
[-7,-8,-7,-6]
Clash.Prelude P> P.map (\n -> satAdd SatSymmetric n (-1) :: Signed 4) [(-8) .. (-5)]
[-7,-8,-7,-6]
Clash.Prelude P> satMul SatSymmetric 2 (-4) :: Signed 4
-8
Clash.Prelude P> satAdd SatSymmetric 0 (-1) :: Signed 1
-1
Since it is fundamentally valid to use the value minBound as input to these computations, which also introduces bias, perhaps the correct solution is to introduce a new datatype that only represents values within symmetric bounds.
The text was updated successfully, but these errors were encountered:
SaturatingNum
'sSatSymmetric
computations on signed integers only saturate to the symmetric lower bound on overflow of the computation, but not if the result isminBound
. One would expectSatSymmetric
computations to not have a bias, but the computations do have a slight bias this way.Since it is fundamentally valid to use the value
minBound
as input to these computations, which also introduces bias, perhaps the correct solution is to introduce a new datatype that only represents values within symmetric bounds.The text was updated successfully, but these errors were encountered: