Would this be fixed in anyway if on your part or on MASON part the "double" used
for time was replaced with BigDecimal?
I am running in the same issue and it's not as easily fixable as just "switching to
int". I have a population evolving and eventually getting faster and faster and
sooner or later they hit a point where floating-point arithmetic errors matter more
than their actual relative speed.
I guess the overhead of having bigDecimal is too high for MASON, but it would be
nice as an option because now I'd really need precision.