added count_ones function

[fuine]

This solves #4. Please note that proposed implementation can most probably be further optimized (for example if the remainder is 0 then we can completely skip mask creation and sum modification). Please let me know what do you think about this @bluss.

[bluss]

It should be a half open range (start inclusive, end exclusive), this way it's consistent with how slicing a vec works for example.

[fuine]

Please take a look at the test below, especially at these assertions:

assert_eq!(fb.count_ones(70..95), 1);
assert_eq!(fb.count_ones(70..96), 2);

I think it does what you expect it to do (ranges work just like in vec)

[bluss]

Can both of these masks be correct at the same time? One needs to include the start of a block, the other the end of it.

[fuine]

It looks suspicious but extensive debug printing (praise {:032b}) shows that it is indeed correct. Both masks in principle do the same - they leave bits on the beginning of the block. Then these bits get counted. For the first block you need to subtract their count (because you already counted them in during the first loop iteration, and they are not needed as they don't lie in the desired range). For the last block you simply need to add the number of ones in the remaining part and so addition is used.

[bluss]

Thanks for the explanation

[fuine]

Sorry for the delay on the review, apparently i didn't submit my comments when i originally wrote them...

[bluss]

This is the only part that is not like slicing a vec

[fuine]

So you propose that we get rid of that assertion, or maybe change error message to the one resembling usual slicing error with index outside of bounds? When you use index outside of bounds you get the message thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', ../ src/libcollections/vec.rs:1306

[bluss]

Slicing a vector permits "end == self.len()", so this should too.

[bluss]

And start == end == self.len() too for that matter.

[fuine]

Ah i see it now. I'm not sure why i wrote it incorrectly, but it's fixed now. Thanks for heads up!

[bluss]

Great. It still needs the start <= end actually. Unfortunately nothing checks that for us.

diff --git a/src/lib.rs b/src/lib.rs
index 8cb7b45..8cd25dd 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -148,8 +148,7 @@ impl FixedBitSet
     {
         let start = range.start().unwrap_or(0);
         let end = range.end().unwrap_or(self.length);
-        // range makes sure that range.start <= range.end
-        assert!(end <= self.length);
+        assert!(start <= end && end <= self.length);
         let (first_block, first_rem) = div_rem(start, BITS);
         let (last_block, last_rem) = div_rem(end, BITS);
         let mut sum = 0usize;
@@ -300,6 +299,23 @@ fn count_ones() {
     assert_eq!(fb.count_ones(70..96), 2);
     assert_eq!(fb.count_ones(70..99), 2);
     assert_eq!(fb.count_ones(..), 9);
+    assert_eq!(fb.count_ones(0..100), 9);
+    assert_eq!(fb.count_ones(0..0), 0);
+    assert_eq!(fb.count_ones(100..100), 0);
+}
+
+#[should_panic]
+#[test]
+fn count_ones_oob() {
+    let fb = FixedBitSet::with_capacity(100);
+    fb.count_ones(90..101);
+}
+
+#[should_panic]
+#[test]
+fn count_ones_negative_range() {
+    let fb = FixedBitSet::with_capacity(100);
+    fb.count_ones(90..80);
 }

[fuine]

Fixed, thanks for the fix. I'm not sure why i assumed that start <= end, but it was indeed a mistake. Do you want me to squash commits before merge? Or do you still see some rough edges that should be polished?

[bluss]

It's fine now. Thanks for working on this.

[fuine]

Thanks! As always working with you is a pleasure :)