deque improvements #142
deque improvements #142
Conversation
|
|
||
| // https://docs.rs/itertools/0.10.1/itertools/macro.izip.html | ||
| #[macro_export] | ||
| macro_rules! zip { |
There was a problem hiding this comment.
Don't know if we really need this, but looping over 2+ groups of points seems to be a pretty common operation
| } | ||
| self.d.push(ele); | ||
| } | ||
| pub fn get(&self) -> &Vec<T> { |
There was a problem hiding this comment.
Can't have a method like this (or something similar that returns a &[T]) because the elements would not be in order. So there is .iter() and you can also index directly into the deque which will handle the offsets for you.
I think if you intend to access every element the .iter() method will be faster than say a
for i in 0..deque.len() {
deque[i]
}Because the arithmetic required in the index method might mess with bound check elimination. But I haven't actually checked so 🤷
There was a problem hiding this comment.
Sounds good to me
|
Also think we should probably rename this, seems more like a circular buffer but without the separate read and write pointers |
| for idx in 0..NUM_POINTS { | ||
| min_ = f64::min(mag_x[idx], f64::min(mag_y[idx], f64::min(mag_z[idx], min_))); | ||
| max_ = f64::max(mag_x[idx], f64::max(mag_y[idx], f64::max(mag_z[idx], max_))); | ||
| let mut min = f64::MAX; |
There was a problem hiding this comment.
Not sure why I chose to use min_ and max_ here, maybe thought it would get flagged by lint or something.
|
|
||
| /// Returns an iterator from the oldest values to the newest. | ||
| pub fn iter(&self) -> Iter<T> { | ||
| let (a, b) = self.data.split_at(self.index); |
There was a problem hiding this comment.
I'm not sure I follow this. Why do you need to use split_at on data?
There was a problem hiding this comment.
Because once you go past capacity the elements in data are out of order. for example if we had a deque with capacity 3
v = [1, 2, 3] // index = 0
v.push(4) // v = [4, 2, 3], index = 1
without the split v.iter() would return 4 -> 2 -> 3, when it should be 2 -> 3 -> 4. If you split at the current index (1 in this case), the right half will contain all the older elements ([2, 3]), and the left have will contain the newer ones ([4]). Then b.chain(a) will be an iterator from oldest to newest
There was a problem hiding this comment.
Ah I see now that is clever
3 participants
Currently the deque calls
vec.remove(0)when it's full and you push an element.removehas to shift all the elements to the left. This way might be a little faster