In general I agree that the half-open interval [TS_FROM, TS_TO) should
be the default behavior for intervals due to the reasons given -
whatever detailed influence that has on discrete iterations /
upto/downto :-)
Cheers,
mg
On 18.03.2018 17:45, Alexander Veit wrote:
Hi,
2) changing the behavior of the upto method (and downto) so that, when
using a custom unit of iteration that prevents the start value from being
incremented exactly to the end value, the method returns as soon as the
current value becomes strictly later than the end value. In my first stab
at it, the method returned when the current iteration value became later
than the end value _by at least one unit_. As a result, the closure could
be called with a value later than the end parameter, which seemed
undesirable. e.g.
Judging from my experience in dealing with time intervals, the most
natural way for defining them is as half-open intervals with the lower
bound included and the upper bound excluded. This allows the whole
timeline to be completely and non-overlapping covered with such
intervals. This is not only a mathematically desireable property, but
also helps making code simpler in many cases.
I do not know, if this approach is in accordance with the general design
rules of this API, but if so, it would suggest that an ascending
iteration should not yield values greater or equal the upper bound.
