commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] Negative max in class Incrementor
Date Sun, 30 Aug 2015 13:18:45 GMT

On Sat, 29 Aug 2015 22:21:55 -0500, Ole Ersoy wrote:
> I'm deleting most of the discussion, because I think I may be
> throwing too many ingredients on the table.  For further context
> please see the previous thread.
>> I don't get that.  Here the main purpose is to set a hard limit
>> that will raise an exception (to avoid that some algo from running
>> forever).
> Well there are two concerns here.  One is the precise number of steps
> that should be executed and the other is whether we need to raise the
> exception.
> To stop the algorithm from running forever we let the `end` callback
> notify the thing doing the incrementing that we are done.  Does that
> make sense?

Not sure. The current usage is
1. Set the hard limit (and action when that limit is reached)
2. Let the incrementor do its thing (count and call "trigger").

IIUC, you propose that the increment tells its caller that the
limit has been reached. Then, I suppose, the caller will have to
act, rather than the incrementor.
Unless I'm missing something, I don't see the advantage (in the
examples from CM).

> Secondly suppose we expect a sequence like 5, 10, 15, 20...but the
> max is 17.  Do we loop past 17 and let that be the final loop, thus
> passing in 20 to the increment listener / cb, or do we stop at 15?

The proposed IntegerSequence.Incrementor would trigger the callback
if "increment()" is called again after 15 is returned.
Note that the increment does not stop by itself. If a range is created
its last value will be 15 (and the callback will never be called, by

> By
> letting the developer calculate the number of steps, avoiding the use
> of a max, we gain simplicity and flexibility.

In all CM usage, the number of steps is unknown; the Incrementor is
intended to avoid an infinite loop.

> Lastly perhaps the `increment` callback wants to notify the
> `incrementer / algorithm` that it's done.  In this case we only
> specify the `start` and `stepSize` arguments and leave it up to the
> `increment` callback to realize the termination point and stop the
> algorithm.

Cf. previous paragraph.
Termination of the counter is not the same as termination of the
algorithm.  In CM usage, the latter must occur first, and the second
signals a failure.


P.S. I'll commit the "IntegerSequence" class. You can try and patch it
      (or design an alternative) to show what you mean on some specific
      CM use of the old "Incrementor".

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message