Closes Issue #66:

[AlexPatrie]

What problem does this PR address?: This PR addresses an issue raised in #66 regarding an inconsistency in Pythonic floating-point arithmetic.

I will quote section 15 of the official Python documentation: "_...interestingly, there are many different decimal numbers that share the same nearest approximate binary fraction. For example, the numbers 0.1 and 0.10000000000000001 and 0.1000000000000000055511151231257827021181583404541015625 are all approximated by 3602879701896397 / 2 ** 55. Since all of these decimal values share the same approximation, any one of them could be displayed while still preserving the invariant eval(repr(x)) == x." Despite this familiar pythonic behavior we are presented with an arithmetic assertion error. In the new implementation, as for these division results in a non-integer value, the multiplication by sim.number_of_points will result in a float with a fractional part, which is then rounded to the nearest integer using the built-in round() function. This is why the result of the second expression is 500.0 instead of 499.777777347.

What features does this PR implement?: A refactoring in order of operations as per #66.

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication