Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let ApInt::resize_to_bool just return the least-significant bit (should be faster) #42

Open
Robbepop opened this issue Jul 14, 2019 · 8 comments

Comments

@Robbepop
Copy link
Owner

No description provided.

@AaronKutch
Copy link
Contributor

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 flip
  • is_even
  • is_odd
  • is_negative
  • is_positive

and related to these are:

  • from_bool and the From<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 for Int or should it also be for ApInt?)

@AaronKutch
Copy link
Contributor

AaronKutch commented Aug 17, 2019

I was looking at the is_one function and remembered that ApInts 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: rust-lang/rust#51582. Should I make a is_unsigned_one and is_signed_one and add some documentation about the corner case?

@AaronKutch
Copy link
Contributor

AaronKutch commented Aug 17, 2019

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 ApInts.

@AaronKutch
Copy link
Contributor

AaronKutch commented Jan 21, 2020

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,
}

@AaronKutch
Copy link
Contributor

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:
ApInts will have public member functions:

  • lsb for least significant bit
  • msb for most significant bit
  • set_lsb for setting the significant bit
  • set_msb
    all the others will be removed.

Maybe Ints will have in addition to the above:

  • sign_bit
  • is_negative
  • is_positive

@Robbepop
Copy link
Owner Author

Robbepop commented Jan 21, 2020

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.

@AaronKutch
Copy link
Contributor

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.

@AaronKutch
Copy link
Contributor

Actually, we can keep is_even and is_odd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants