lfsalasg / hashgrid Goto Github PK

If I run println!("{}", grid[cell_index].neighbors.len()); for a grid generated with PeriodicImage::NONE for all dimensions, it is returning 0 neighbors.

A confusing facto of the drop_dweller method of the HashCell struct is that I cannot use it if I'm iterating over it. Neither can I iterate using the indexes because indexes will update every time I remove something from the collection. An alternative is to use something like the retain method of the Vec collection but it does not return the removed elements.

As an alternative, I can have a method called purge where I keep the elements from the vector and return a copy of the elements that do not belong. It could look something like:

fn purge(&mut self, cell) {
let elements_to_remove = self.get_dwellers(cell).iter().filter(|x| self.bounding_cell_coord(x.coord()) == cell)
self[cell].dwellers.retain(x| self.bounding_cell_coord(x.coord()) == cell)

elements_to_remove
}

However, I am not sure about the memory and cpu performance of this method, since it has to visit every element of the cell. Another option could be to store the indexes of the elements I want to remove, reorganize that list and then remove using swap_remove. It will take exactly time n where n is the number of elements to remove. If the list is pretty ordered, then it won't be a hurdle, anyway I have to compare both methodologies.

The current example is a basic idea on how to create a 3D-Grid that contains Point3D elements, but it misses a lot of basic ideas of this crate such as:

• Implementation of the common trait: Cardinality
• Reading and walking through the grid
• Spatial concepts such as neighbors and bounding cell.
• The usage of IsoHashGrid for multithreading

All these points are features of the current crate and shoudl be depicted in the front page of the repo and the (future) documentation.

Before implementing:

• Clarify how could this impact the whole design of the API, specially in terms of cocurrency and usability
• Define the performance overhead of usin dyn. Solving #12 could help to determine this overhead

The Cardinality trait is required to register an object to HashGrid and many objects could have a similar abstraction of its cardinality: A variable with a tuple, slice or vector representing the positions in the N-Dimensional space. In these trivial cases, it should be straightforward to derive this trait.

the Point<N> struct is a the representation of a vector in the N-dimensional space and implement common lineal algebra operations like sum or multiplication. Currently it implements a naive approach. However many architectures can implement the SIMD processing and that could benefit systems of high dimensionality. So the task is:

• To implement the simd crate for the common operations (sum, extract, multiply and divide)
• To define a conditional compile option to either use SIMD or the naive approach.

Implement the Index and IndexMut traits for the HashCell struct. The index should return the elements registered in the given cell.