The code that tests operations on trimmed amounts previously made a
vm.assume call to enforce that the decimals of both amounts are the
same.
Since the decimal is an 8 bit value, the probability that
two (uniformly) randomly generated decimals are the same is 1/256,
meaning that the vast majority of test cases were discarded.
Now, we instead set the decimals of the first number to the decimals of
the second number. This does not change* the characteristics of the test
cases, as the amounts are sampled independently from the decimals.
*NOTE: this is only true under the assumption that the TrimmedAmount
type (which is backed by a uint72) is actually sampled from a uniform
distribution. This might not be the case depending on the fuzzer
implementation, as some fuzzers prefer certain edge cases. Nevertheless,
for most intents and purposes, it should be close enough without
significantly weakening the test cases.
The code that tests operations on trimmed amounts previously made a
vm.assumecall to enforce that the decimals of both amounts are the same.Since the decimal is an 8 bit value, the probability that two (uniformly) randomly generated decimals are the same is 1/256, meaning that the vast majority of test cases were discarded.
Now, we instead set the decimals of the first number to the decimals of the second number. This does not change* the characteristics of the test cases, as the amounts are sampled independently from the decimals.
*NOTE: this is only true under the assumption that the TrimmedAmount type (which is backed by a uint72) is actually sampled from a uniform distribution. This might not be the case depending on the fuzzer implementation, as some fuzzers prefer certain edge cases. Nevertheless, for most intents and purposes, it should be close enough without significantly weakening the test cases.