Context

Currently the Size struct holds two non-negative integers to represent width and height. While this makes sense in most situations, its use within the Rectangle struct leads to some undesirable side effects.

Problems

When we divide a Rectangle into quadrants, we try to do so as evenly as possible. However this is not always possible since the Size using integral numbers. Consider a Rectangle instance with a width of 5 and a height of 5. Dividing this into quadrants leads to four sub-rectangles each with a width and height of 2.5. Since the width and height must be represented as an integer, these sub-rectangles must be adjusted to round off their width and height.

As such, instead of four equal quadrants, we now have 4 quadrants of varying sizes (the smallest would be 2 x 2, the largest is 3 x 3, and the two remaining quadrants are 2 x 3 and 3 x 2).

Solution

The use of integers for the width and height of Size is necessary to provide well defined boundaries between the quadrants. In other words, it is not a suitable solution to allow the width and height of Size to be floating point values.

Instead, to guarantee that dividing a rectangle produces 4 equal sized quadrants, I propose to restrict the width and height of a Rectangle to be a power of two. This would require a few changes, namely:

• a way to create a Size instance given an exponent of two (e.g. `Size::new(e: 5)' would produce a size with width and height equal to 32).
• changes to tests
• changes to the way quadrants are created (this would actually be a simplification)

Problem

When simulating a large number of bodies (> 20,000) it can happen that the program terminates due to an OutOfBounds error. This happens when trying to determine which quadrant a body belongs to, but the body is not contained within the current space.

Possible Cause

The error message reports that one of the coordinates of the body's position is very slightly larger than a whole number (e.g. 32.00005). It is likely that the last step in the path chosen in the tree is incorrect due to inaccurate comparisons of floating point numbers. Currently we're using f32 to store position coordinates, perhaps f64 would solve this issue.