Open Robbepop opened 5 years ago
I was looking at the is_one
function and remembered that ApInt
s with bitwidth 1 treated as signed have only a sign bit, meaning that a bit value of 1 is treated as -1. There was a bug caused by a similar thing I dug up here: https://github.com/rust-lang/rust/issues/51582. Should I make a is_unsigned_one
and is_signed_one
and add some documentation about the corner case?
Maybe I should let the current functionality be, specify that "Returns true
if the unsigned interpretation ApInt
represents the value one (1
).", and put more general documentation higher up about bitwidth 1 ApInt
s.
Reminder to myself that advanced slice matching is going to be stabilized, so I can use stuff like
fn ls_digit<T>(x: &[T]) -> Option<&T> {
match x {
[x, ..] => Some(x),
[] => None,
}
Even though I usually like verbose member functions, I think we want to use hungarian notation for these cases of accessing the most and least significant bits:
ApInt
s will have public member functions:
lsb
for least significant bitmsb
for most significant bitset_lsb
for setting the significant bitset_msb
all the others will be removed.Maybe Int
s will have in addition to the above:
sign_bit
is_negative
is_positive
Sounds good about lsb
and msb
. Not sure about getting rid of is_even
and is_odd
since they carry more meaning than a check to lsb
etc.
Depends on what we want Apint
to be. Do we want it to be a user-friendly type or do we want it to be a generalist type that should be embedded into wrappers.
For example the stevia
crate for which I was implementing this crate mainly used it in the latter case. So not directly, but wrapped it providing its own interfaces on top.
I think there should be one standard way of getting the least significant bit. When dealing with regular integers, I always think of it in terms of the least significant bit.
Actually, we can keep is_even
and is_odd
There are the following least and most significant functions right now:
most_significant_bit
(private)least_significant_bit
(private)sign_bit
, and set and unset and flipis_even
is_odd
is_negative
is_positive
and related to these are:
from_bool
and theFrom<bool>
resize_to_bool
try_to_bool
I will check that these are optimized, but should I remove some of these (e.g.
is_negative
should only be forInt
or should it also be forApInt
?)