Closed ctb closed 2 weeks ago
Attention: Patch coverage is 93.33333%
with 1 line
in your changes missing coverage. Please review.
Project coverage is 86.45%. Comparing base (
122c4b7
) to head (5f49d1c
). Report is 1 commits behind head on latest.
Files with missing lines | Patch % | Lines |
---|---|---|
src/core/src/ffi/index/revindex.rs | 0.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Ready for review @luizirber
This PR started because we were mixing u32 and u64 in places, but I think a switch away from usize (architecture specific & mostly returned from collection lengths, and so on) to explicit u32/u64 seems good.
Initially u32
started to get into the API because wasm is 32-bits nowadays, so some function calls were easier to set up across JS/Rust. But also based on the scaled values we actually use (1 -> ~100k) u64
is way too big, u16
is too small, so... u32
it is?
(ksize should probably be u16
, has anyone ever used k > 65535
? :joy_cat: )
I would have no problem standardizing scaled on u32, too. Just want it to be one type of number :).
Maybe we can do a type alias like HashIntoType
for scaled:
https://github.com/sourmash-bio/sourmash/blob/6ae9cd32d9ac2841c98415bc1c043597536a5470/src/core/src/lib.rs#L55
would likely still need some conversions but can be done with as HashIntoType
.
(And easier to play out with changing the type too and evaluating consequences, instead of having to fix everywhere in the codebase)
sounds good!
Ready for review @luizirber !
Makes
scaled
a u32, and change a few others as well.This PR started because we were mixing u32 and u64 in places, but I think a switch away from usize (architecture specific & mostly returned from collection lengths, and so on) to explicit u32/u64 seems good.
Fixes https://github.com/sourmash-bio/sourmash/issues/3363