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
Huffman Bug Fix #699
Huffman Bug Fix #699
Conversation
a currently failing test #700 that passes if rebased on this branch. |
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.
I think u128
is not supported on all platforms. Could it be a problem for embedded?
// N.B.: p1 + p2 can never actually saturate as you would need to have 2**64 max u64s | ||
// from the input to overflow. However, saturating is a reasonable behavior here as | ||
// huffman tree construction would treat all such elements as "very likely". | ||
let p = Reverse(p1.0.saturating_add(p2.0)); |
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.
If it can never happen, why not just have +
?
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.
i'd rather define the behavior correctly here should it ever overflow rather than wrapping around. Perhaaps defensively, but it'd be possible someone were to update the types/sizes later without appreciating this point.
I think u128 is supported on all platforms, either with a native type or a wrapper. We could also do the same trick with u32 and u64 and it wouldn't be an issue either (u32 is plenty IMO). |
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.
Thanks for testing this. ACK modulo removing the error variant.
@@ -220,7 +221,10 @@ impl TaprootSpendInfo { | |||
let (p1, s1) = node_weights.pop().expect("len must be at least two"); | |||
let (p2, s2) = node_weights.pop().expect("len must be at least two"); | |||
// Insert the sum of first two in the tree as a new node | |||
let p = p1.checked_add(p2).ok_or(TaprootBuilderError::ScriptWeightOverflow)?; |
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 you also remove the Error variant from the error enum?
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.
done
… from ever happening with wider integers
9a40597
to
f2a6827
Compare
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.
ACK f2a6827
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.
utACK f2a6827
1518517 Decrease Huffman weight type to 32 bits (Jeremy Rubin) Pull request description: This builds on #699 but is the more bikesheddable part since it changes the API. > u32 of weight should be enough for any branch. -- Bill Gates ACKs for top commit: dr-orlovsky: utACK 1518517 Kixunil: ACK 1518517 Tree-SHA512: 9c507ae6129dda8dc069b0a142181a78cf89cb3ebf9d2169c46662822cb4ea9ed075bf484528f5399fe0ed383a425174a702e2d685f31c246f5a86c46ed17c3a
I noticed one cleanup & one bugfix while looking into the huffman algorithm: