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
The following additional operations are defined on it:
@@ -110,6 +111,13 @@ TBD
110
111
- We could use the same width for `other` as for `self`, adjusted to the appropriate exponent for the value.
111
112
- We could outright reject it, requiring the user to explicitly specify precision like e.g. `value * Q(15).const(1 / 3)`.
112
113
114
+
- How should we handle rounding?
115
+
- Truncating and adding the most significant truncated bit is cheap and is effectively round to nearest with ties rounded towards positive infinity.
116
+
- Simply truncating is free, rounds towards negative infinity.
117
+
- IEEE 754 defaults to round to nearest, ties to even, which is more expensive to implement.
118
+
- Should we make it user selectable?
119
+
- We still need a default mode used when a higher precision number is passed to `.eq()`.
120
+
113
121
- Are there any other operations that would be good to have?
114
122
115
123
- Are there any operations that would be good to *not* have?
@@ -127,6 +135,7 @@ TBD
127
135
- I feel like the `i_width` and `f_width` names are difficult enough to read that it's of more importance than bikeshedding to come up with something more readable. (@whitequark)
128
136
-`.int_bits`, `.frac_bits`?
129
137
- cursed option: `int, frac = x.width`?
138
+
-`.round()` is a bit awkwardly named when it's used both to increase and decrease precision.
0 commit comments