-
Notifications
You must be signed in to change notification settings - Fork 223
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
Port over relevant changes from bigint #25
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only issue is that you unnecessarily create a ~1kb buffer when converting to a string
@@ -1219,16 +1195,24 @@ macro_rules! impl_std_for_uint { | |||
return write!(f, "0"); | |||
} | |||
|
|||
let mut s = String::new(); | |||
let mut buf = [0_u8; $n_words*20]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why $n_words * 20
? Surely it's ceil(log10(2^($n_words - 1)))
? That's 154 for U512 but this code would create a buffer of size 1280 (way too big).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change came from https://github.com/paritytech/bigint/blob/master/src/uint.rs#L927 (part of PR #43) – not sure what their thinking was there, maybe it was making space for a somewhat long debug string (which doesn't make sense).
Should I just go ahead and replace it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait a sec, I think you're confusing uint
with fixed-hash
: here the construct_uint!
macro is called with the words not the number of bytes, so $n_words
here is 8
=> 8 * 10 == 160
which is fine I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The construct_hash!
macro takes number of bytes, which is more logical imo. Quite confusing.
uint/src/uint.rs
Outdated
#[macro_export] | ||
#[doc(hidden)] | ||
macro_rules! impl_std_for_uint { | ||
($name: ident, $n_words: tt) => {} | ||
macro_rules! impl_std_for_uint_internals { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change the name of this macro? If it's used by another macro then you should use a private pattern of that macro rather than a doc(hidden)
macro.
why do we need the same code in 2 places anyway? |
Not sure I follow, can you elaborate? The idea here is to:
|
uint/Cargo.toml
Outdated
@@ -4,27 +4,23 @@ homepage = "http://parity.io" | |||
repository = "https://github.com/paritytech/primitives" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, repository needs an update?
You import code from MIT/Apache repository, btw under GPL license while external contributors agreed under MIT/Apache contribution https://github.com/paritytech/bigint#contribution |
Use --release to run tests
Hey guys. I contributed a bit but I don't mind if you copy my code under diffirent license. About my changes in |
@Pzixel your code is correct, we were mistaken. :) And thank you for your contribution and openness to sort out the licensing stuff. Much appreciated! |
Great work! I'd also suggest to review this discussion about implementing panicing In a nutshell: rust documentation clearly says that |
@Pzixel According to this simple Rust program: fn main() {
for &i in &[128, 256, 512] {
println!("{}, {}", (i / 32) * 10, 2f64.powi(i - 1).log10().ceil());
}
}
// Prints
// 40, 39
// 80, 77
// 160, 154 You could get away with doing |
I think that the best way to handle the bad |
you can easily change the code and see that tests don't pass 🙂 |
What error? It seems like you should get an OOB index and not a UTF8 error, |
@Vurich yep, this is why I edited my post. But you probably got an old version in email notification. Nevermind. Just check it yorself if you wish, it will grant better understanding and I will be calm that I didn't lie :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, let's just merge it :)
Using |
there is already |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Here's some comments for a future PR.
#[macro_use] | ||
extern crate uint; | ||
construct_uint!(U128, 2); | ||
construct_uint!(U256, 4); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use the exported types here? Apparently, creating the types here influences the benchmark results.
#[macro_use] | ||
extern crate crunchy; | ||
#[macro_use] | ||
extern crate uint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add newline before macro invocation?
impl AsRef<Self> for primitives
The
bigint
crate is going away but there is valuable code there that is ported over in this PR.During the recent extraction of crates from
parity-ethereum
andprimitives
, theuint
crate does not instantiate any types, leaving that for consuming code to take care of (e.g.ethereum-types
orsubstrate/primitives
). This means that some code inbigint
cannot be ported touint
but should rather be checked against whatethereum-types
has today. Examples of this is theimpl U256 {…}
, the serde serialization stuff and the many conversion impls inbigint
.The
bigint
crate adds amod_inverse
function toU256
. I think this is the only feature not present inuint
. If it turns out we need this, it should probably be added toethereum-types
.The repos have diverged significantly so this port has been made manually. I am sure I have missed things, so thorough review by the
bigint
committers would be very useful.Performance
The
uint
crate did not have any benchmarks so this PR copies over the ones frombigint
. The results are odd:uint
is much faster across the board. This was unexpected and makes me suspect I did something wrong.Results for
uint
:Results for
bigint
: