Re: [math] Negative max in class Incrementor

[Gilles]

On Fri, 28 Aug 2015 21:25:12 -0500, Ole Ersoy wrote:

On 08/28/2015 04:29 PM, Gilles wrote:

On Fri, 28 Aug 2015 11:48:28 -0500, Ole Ersoy wrote:

This is a side note.  In the class Incrementor there's a
MaxCountExceededCallback that triggers the 
MaxCountExceededException.
It might make sense to place the code that throws the exception in 
a

static utility method inside the exception, eliminating the cb
property, the MaxCountExceededCallback interface, and corresponding
Incrementor constructor.  So we could do:

public void incrementCount() throws MaxCountExceededException() {
   MaxCountExceededException.throw(++count, max);
}


The callback is intended to let the user choose which action the 
counter
exhaustion should trigger. IIRC your proposal, this would not be 
possible

anymore.

OK - Got it.  I too easily associated the 'MaxCountExceeded' callback
with the MaxCountExceededException.  My first thought was that (Even
though the doc says otherwise) if the max is exceeded, then this is
bad, and so an exception should be triggered.  How about removing the
MaxCountExceededException


?
The exception could be used independently of the callback interface.


and using a more "Stream" like interface?:

emitter.on('start', cb);
emitter.on('increment', cb);
emitter.on('end', cb);


What would be the gain?
[Seems overkill for the counter functionality as currently used within 
CM.]



P.S.
Plus one for "Incrementor(long start, long max).


What do you think of the new API
  https://issues.apache.org/jira/browse/MATH-1259
?

Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Negative max in class Incrementor

[Ole Ersoy]

On 08/29/2015 06:59 AM, Gilles wrote:

On Fri, 28 Aug 2015 21:25:12 -0500, Ole Ersoy wrote:

On 08/28/2015 04:29 PM, Gilles wrote:

On Fri, 28 Aug 2015 11:48:28 -0500, Ole Ersoy wrote:

This is a side note.  In the class Incrementor there's a
MaxCountExceededCallback that triggers the MaxCountExceededException.
It might make sense to place the code that throws the exception in a
static utility method inside the exception, eliminating the cb
property, the MaxCountExceededCallback interface, and corresponding
Incrementor constructor.  So we could do:

public void incrementCount() throws MaxCountExceededException() {
   MaxCountExceededException.throw(++count, max);
}


The callback is intended to let the user choose which action the counter
exhaustion should trigger. IIRC your proposal, this would not be possible
anymore.

OK - Got it.  I too easily associated the 'MaxCountExceeded' callback
with the MaxCountExceededException.  My first thought was that (Even
though the doc says otherwise) if the max is exceeded, then this is
bad, and so an exception should be triggered.  How about removing the
MaxCountExceededException


?
The exception could be used independently of the callback interface.

If the IntegerSequence becomes an IntegerSequenceEmitter, and in general 
commons math follows a pattern of listening for events like `start`, 
`increment`, and `end` then we will never exceed the max.

What would be the gain?

- Shorter implementation
- No exceptions
- Event emitter pattern (Which is a popular design pattern for light coupling 
of objects).
- The event emitter can be extended to add more events
- We can skip checking `canIncrement()`
- It introduces a different way of thinking about algorithm design





[Seems overkill for the counter functionality as currently used within CM.]

I think we will gain utility, simplify both current and future code, and 
possibly establish a better development pattern for algorithms if we use an 
exception free IntegerSequenceEmitter.




P.S.
Plus one for "Incrementor(long start, long max).


What do you think of the new API
  https://issues.apache.org/jira/browse/MATH-1259
?


I think it should work like this:
===
Incrementor.build().setStart(start).
setNumberOfSteps(numberOfSteps)
.stepSize(stepSize).
setCallback(CallbackEnum.START, startCB).
seCallback(CallbackEnum.END, endCB).
setCallback(CallbackEnum.INCREMENT, incrementCB).
down()
||
up();
===

If down is called at the end then we get a sequence like 15, 10, 5...If up() is 
called then ...

Callbacks are optional.  We can call increment or increment(10) indefinitely 
without an exception being thrown.  We should be able to retrieve the number of 
increments left, as is included in the current design.

It's up to the developer to calculate the number of steps.  So for example if 
the max is 17 and the start is 5 and the step size is 5, then the developer has 
to decide if she wants 3 or 4 steps completed.

Cheers,
- Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Fwd: svn commit: r963495 - /websites/production/commons/content/proper/commons-csv/archives/1.2/download_csv.cgi

[Gary Gregory]

Thanks Sebb!

Gary

-- Forwarded message --
From: 
Date: Sat, Aug 29, 2015 at 2:23 PM
Subject: svn commit: r963495 -
/websites/production/commons/content/proper/commons-csv/archives/1.2/download_csv.cgi
To: notificati...@commons.apache.org


Author: sebb
Date: Sat Aug 29 21:23:53 2015
New Revision: 963495

Log:
Fix executable property

Modified:

websites/production/commons/content/proper/commons-csv/archives/1.2/download_csv.cgi
 (props changed)

Propchange:
websites/production/commons/content/proper/commons-csv/archives/1.2/download_csv.cgi
--
svn:executable = *





-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Negative max in class Incrementor

[Gilles]

On Sat, 29 Aug 2015 15:56:38 -0500, Ole Ersoy wrote:

On 08/29/2015 06:59 AM, Gilles wrote:

On Fri, 28 Aug 2015 21:25:12 -0500, Ole Ersoy wrote:

On 08/28/2015 04:29 PM, Gilles wrote:

On Fri, 28 Aug 2015 11:48:28 -0500, Ole Ersoy wrote:

This is a side note.  In the class Incrementor there's a
MaxCountExceededCallback that triggers the 
MaxCountExceededException.
It might make sense to place the code that throws the exception 
in a

static utility method inside the exception, eliminating the cb
property, the MaxCountExceededCallback interface, and 
corresponding

Incrementor constructor.  So we could do:

public void incrementCount() throws MaxCountExceededException() {
   MaxCountExceededException.throw(++count, max);
}


The callback is intended to let the user choose which action the 
counter
exhaustion should trigger. IIRC your proposal, this would not be 
possible

anymore.
OK - Got it.  I too easily associated the 'MaxCountExceeded' 
callback
with the MaxCountExceededException.  My first thought was that 
(Even

though the doc says otherwise) if the max is exceeded, then this is
bad, and so an exception should be triggered.  How about removing 
the

MaxCountExceededException


?
The exception could be used independently of the callback interface.

If the IntegerSequence becomes an IntegerSequenceEmitter, and in
general commons math follows a pattern of listening for events like
`start`, `increment`, and `end` then we will never exceed the max.

What would be the gain?

- Shorter implementation


Of what?


- No exceptions


Hmm, in this case, the main usage in CM is to throw an exception
when an iterative algorithm exhausts the counter...


- Event emitter pattern (Which is a popular design pattern for light
coupling of objects).
- The event emitter can be extended to add more events
- We can skip checking `canIncrement()`


But the user code must listen to the events, instead.  No?


- It introduces a different way of thinking about algorithm design


I'm ready to believe it but are we ready for yet another change
in paradigm within CM?
Already several issues awaits the fluent API upgrade...

You can always formulate a general request, and suggest a plan
for updating the whole library. :-)



[Seems overkill for the counter functionality as currently used 
within CM.]

I think we will gain utility, simplify both current and future code,
and possibly establish a better development pattern for algorithms if
we use an exception free IntegerSequenceEmitter.




P.S.
Plus one for "Incrementor(long start, long max).


What do you think of the new API
  https://issues.apache.org/jira/browse/MATH-1259
?


I think it should work like this:
===
Incrementor.build().setStart(start).
setNumberOfSteps(numberOfSteps)
.stepSize(stepSize).
setCallback(CallbackEnum.START, startCB).
seCallback(CallbackEnum.END, endCB).
setCallback(CallbackEnum.INCREMENT, incrementCB).
down()
||
up();
===

If down is called at the end then we get a sequence like 15, 10,
5...If up() is called then ...


Method 'up' and 'down' are the equivalent of a positive or negative
increment, respectively.
At first sight, the latter seems more usual in the context of a math
library.
Then, the "stepSize" should be restricted to positive.



Callbacks are optional.  We can call increment or increment(10)
indefinitely without an exception being thrown.


Not indefinitely, only up to MAX_VALUE...


 We should be able to
retrieve the number of increments left, as is included in the current
design.


We could add that, if the need arises.


It's up to the developer to calculate the number of steps.  So for
example if the max is 17 and the start is 5 and the step size is 5,
then the developer has to decide if she wants 3 or 4 steps completed.


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).

Regards,
Gilles



Cheers,
- Ole





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Negative max in class Incrementor

[Ole Ersoy]

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?

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? By letting the developer 
calculate the number of steps, avoiding the use of a max, we gain simplicity 
and flexibility.

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.

Cheers,
- Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org