Can any #python folks develop an opinion about https://github.com/glyph/Fritter/pull/10 ? I don't need a full code review but it would be really useful to have thoughts about whether it's clear when this would be useful, if it would in fact be useful, or if "discrete" is both a correct and useful shorthand for what it's doing.
Note that a float's step size becomes ever coarser as the float's number becomes larger. I once did a quick and dirty discrete simulator that used floats for time, and far sooner than I expected the smallest possible time (float) step was stepping over timepoints where it should have stopped.
@glyph
To put it cutely: time is money, don't express it in floats. :)
@merula thank you so much for this perspective! Not quite what I'm looking for on this particular change, but it's definitely something I will think about: getting away from floats entirely in Python is very difficult. You may note that in Fritter, Scheduler is already generic over a "time" type ("WhenT"): https://fritter.readthedocs.io/en/latest/api/fritter.boundaries.Scheduler.html
@merula This is mostly to draw a distinction between "physical" time (floats) and "civil" time (datetimes) but for finer-grained use-cases like your discrete simulation, it would definitely be possible to create an `int` scheduler too. Perhaps this suggests that MemoryDriver should *also* be generic, and not hard-coded to `float`.
In fact, yeah: https://github.com/glyph/Fritter/issues/12
@merula I gotta ask though, what bananas time scale were you simulating on that your base time quantum is "minute" and double-precision IEE754 floating-point numbers were *not fine-grained enough* ??
