date:20150925


On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles  
wrote:



On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

On Fri, Sep 25, 2015 at 5:09 PM, Gilles 


wrote:

On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:


On 9/25/15 7:03 AM, Gilles wrote:


On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:


Hi Ole,


for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of
logging
facility to CM.
If the outcome is positive, there are a handful of 
alternatives,

some of
them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).



Could someone summarize why those alternatives were deemed "more
viable"?

btw. the same discussion has been done for other commons


components as
well, and the result usually was: do not add logging



What was the rationale?


Look at the archives.  We have discussed this multiple times in 
the

past in [math] and each time came to the conclusion that Thomas
succinctly states above.  What has changed now?



We also discussed several times to stick with Java 5.
Fortunately, that has changed. [Although sticking with Java 7 is 
still

a bad decision IMHO.]

As for logging, IIRC, the sole argument was "no dependency" 
because

(IIRC) of the potential "JAR hell".


that's not correct. The decision to not include any dependencies 
has

nothing to do with "JAR hell".



Although I can't find it now, I'm pretty sure that I more than once
got such an answer.

In order to prevent JAR hell, commons components strictly stick to 
the

"Versioning guidelines" [1]



I can't see how it relates.
But if you mean that no JAR hell can emerge from using a logging 
framework,

then that's good news.

The no-dependency rule is more related to the proposal of the 
component,

see [2]



Thanks for the reminder; in that document, we read:

  (1) Scope of the Package
   [...]
   5. Limited dependencies. No external dependencies beyond Commons
components and the JDK

So we are fine if use "Log4j 2" as kindly offered by Gary.

My long-standing mentioning of slf4j was only because of its
"weightlessness" (thanks to the no-op implementation of its API).
If "Log4j 2" has followed this path, good for everyone.

No objection, then?



I'm still not clear what log4j 2 adds -- most Apache java projects 
seem to

use log4j 1.2, seems to work well. -- H



I can only answer about "slf4j" where the "f" stands for facade: it's 
"only"
an API, with bridges to several logging frameworks (log4j, logback, 
etc.).


The separation of concerns (API vs one of several implementations to 
choose from)
allows the top-level application to uniformly configure logging or to 
disable it

completely (if choosing the "no-op" implementation).

Hopefully, this flexibility has been included in "Log4j 2" (TBC by the 
experts).


Regards,
Gilles






[...]



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

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 02:00:13 +0200, Bernd Eckenfels wrote:
For such a simple case like logging in a (math) library you can also 
use

the JDK jul logging.


This may make you change your mind:
  
http://stackoverflow.com/questions/11359187/why-not-use-java-util-logging



However I really do not see a need for it


Examples were given in this thread.


(and I
think it can negatively impact the user experience of a lib if it 
does

logging even when it has no environmental interactions)


Could you elaborate on "negatively impact"?  Thanks.



Am Sat, 26 Sep
2015 01:47:09 +0200 schrieb Gilles :


Thanks for the reminder; in that document, we read:

   (1) Scope of the Package
[...]
5. Limited dependencies. No external dependencies beyond Commons
components and the JDK

So we are fine if use "Log4j 2" as kindly offered by Gary.

My long-standing mentioning of slf4j was only because of its
"weightlessness" (thanks to the no-op implementation of its API).
If "Log4j 2" has followed this path, good for everyone.

No objection, then?


Uh, be carefull with the trigger of that gun you point at somenes
chest :)


Sure. :-D

Regards,
Gilles



Gruss
Bernd




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

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Bernd Eckenfels

For such a simple case like logging in a (math) library you can also use
the JDK jul logging.

However I really do not see a need for it (and I
think it can negatively impact the user experience of a lib if it does
logging even when it has no environmental interactions)


Am Sat, 26 Sep
2015 01:47:09 +0200 schrieb Gilles :

> Thanks for the reminder; in that document, we read:
> 
>(1) Scope of the Package
> [...]
> 5. Limited dependencies. No external dependencies beyond Commons 
> components and the JDK
> 
> So we are fine if use "Log4j 2" as kindly offered by Gary.
> 
> My long-standing mentioning of slf4j was only because of its
> "weightlessness" (thanks to the no-op implementation of its API).
> If "Log4j 2" has followed this path, good for everyone.
> 
> No objection, then?

Uh, be carefull with the trigger of that gun you point at somenes
chest :)

Gruss
Bernd

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

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Hasan Diwan

On 25 September 2015 at 16:47, Gilles  wrote:

> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>
>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles 
>> wrote:
>>
>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>
>>> On 9/25/15 7:03 AM, Gilles wrote:

 On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>
> Hi Ole,
>>
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
>> If the outcome is positive, there are a handful of alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
>>
>>
> Could someone summarize why those alternatives were deemed "more
> viable"?
>
> btw. the same discussion has been done for other commons
>
>> components as
>> well, and the result usually was: do not add logging
>>
>>
> What was the rationale?
>
>
 Look at the archives.  We have discussed this multiple times in the
 past in [math] and each time came to the conclusion that Thomas
 succinctly states above.  What has changed now?


>>> We also discussed several times to stick with Java 5.
>>> Fortunately, that has changed. [Although sticking with Java 7 is still
>>> a bad decision IMHO.]
>>>
>>> As for logging, IIRC, the sole argument was "no dependency" because
>>> (IIRC) of the potential "JAR hell".
>>>
>>>
>> that's not correct. The decision to not include any dependencies has
>> nothing to do with "JAR hell".
>>
>
> Although I can't find it now, I'm pretty sure that I more than once
> got such an answer.
>
> In order to prevent JAR hell, commons components strictly stick to the
>> "Versioning guidelines" [1]
>>
>
> I can't see how it relates.
> But if you mean that no JAR hell can emerge from using a logging framework,
> then that's good news.
>
> The no-dependency rule is more related to the proposal of the component,
>> see [2]
>>
>
> Thanks for the reminder; in that document, we read:
>
>   (1) Scope of the Package
>[...]
>5. Limited dependencies. No external dependencies beyond Commons
> components and the JDK
>
> So we are fine if use "Log4j 2" as kindly offered by Gary.
>
> My long-standing mentioning of slf4j was only because of its
> "weightlessness" (thanks to the no-op implementation of its API).
> If "Log4j 2" has followed this path, good for everyone.
>
> No objection, then?


I'm still not clear what log4j 2 adds -- most Apache java projects seem to
use log4j 1.2, seems to work well. -- H

>
>
>
> Gilles
>
>
> [1] http://commons.apache.org/releases/versioning.html
>> [2] http://commons.apache.org/proper/commons-math/proposal.html
>>
>> Thomas
>>
>>
>> If there are now well-formed answers proving that the fear was
>>> unfounded, that is also a change.
>>>
>>> IMO, logging is quite important for any "non-obvious" code.[1]
>>> [I'm again stating that, in that respect, CM is not like the other
>>> "Commmons" components.]
>>>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>>> It also makes a code easier to debug while developing or modifying it
>>> (without resorting to poor man's logging, then deleting the "print",
>>> then reinstating them, then deleting them again, ad nauseam).
>>>
>>> Gilles
>>>
>>> [1] No quality or complexity judgment implied.
>>>
>>>
>>> Phil
>>>


>
> Gilles
>
> Thomas
>
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
>> wrote:
>>
>> Hello,
>>
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up.
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>>
>>>
>>>
>>>
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>>
>>>
>>>
>>>
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-t

Re: [Math] Utilitzation of SLF4J?

On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
On Fri, Sep 25, 2015 at 5:09 PM, Gilles

wrote:

On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:

On 9/25/15 7:03 AM, Gilles wrote:

On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:

Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of
logging
facility to CM.
If the outcome is positive, there are a handful of alternatives,
some of
them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).

Could someone summarize why those alternatives were deemed "more
viable"?

btw. the same discussion has been done for other commons

components as
well, and the result usually was: do not add logging

What was the rationale?

Look at the archives. We have discussed this multiple times in the
past in [math] and each time came to the conclusion that Thomas
succinctly states above. What has changed now?

We also discussed several times to stick with Java 5.
Fortunately, that has changed. [Although sticking with Java 7 is
still

a bad decision IMHO.]

As for logging, IIRC, the sole argument was "no dependency" because
(IIRC) of the potential "JAR hell".

that's not correct. The decision to not include any dependencies has
nothing to do with "JAR hell".

Although I can't find it now, I'm pretty sure that I more than once
got such an answer.

In order to prevent JAR hell, commons components strictly stick to
the

"Versioning guidelines" [1]

I can't see how it relates.
But if you mean that no JAR hell can emerge from using a logging
framework,

then that's good news.

The no-dependency rule is more related to the proposal of the
component,

see [2]

Thanks for the reminder; in that document, we read:

(1) Scope of the Package
[...]
5. Limited dependencies. No external dependencies beyond Commons
components and the JDK

So we are fine if use "Log4j 2" as kindly offered by Gary.

My long-standing mentioning of slf4j was only because of its
"weightlessness" (thanks to the no-op implementation of its API).
If "Log4j 2" has followed this path, good for everyone.

No objection, then?

Gilles

[1] http://commons.apache.org/releases/versioning.html
[2] http://commons.apache.org/proper/commons-math/proposal.html

Thomas

If there are now well-formed answers proving that the fear was
unfounded, that is also a change.

IMO, logging is quite important for any "non-obvious" code.[1]
[I'm again stating that, in that respect, CM is not like the other
"Commmons" components.]

(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).

Gilles

[1] No quality or complexity judgment implied.

Phil

Gilles

Thomas

On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy
wrote:

Hello,

We have been discussing various ways to view what's happening
internally
with algorithms, and the topic of including SLF4J has come up.
I know that
this was discussed earlier and it was decided that CM is a low
level
dependency, therefore it should minimize the transitive
dependencies that
it introduces. The Java community has adopted many means of
dealing with
potential logging conflicts, so I'm requesting that we use SLF4J
for
logging.

I know that JBoss introduced its own logging system, and this
made me a
bit nervous about this suggestion, so I looked up strategies for
switching
their logger out with SLF4J:

http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many
dependencies that
might use commons-logging instead of SLF4J looks something like
this:

http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set
of

dependencies. At this point the fix should be a permanent. If
someone has
has a very intricate scenario that we have not yet seen, they
could use
(And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole

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

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Hasan Diwan

Oughtn't there be an option to have logging for developers? If you'd like
to use it, feel free; if not, don't. Including log4j (or slf or
commons-logging, so on) doesn't add too much weight to the jar -- one file,
a small properties file, and 4-lines in the pom file. If there is interest,
I can submit a patch adding log4j and log4j.properties to JIRA. Let me
know? -- H

On 25 September 2015 at 16:26, Gilles  wrote:

> On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:
>
> I say something like: "I had to fork some CM class to insert
> log statements."
> You say something like: "No, you don't; write test or inspect
> the code."
>
> You had been more constructive:
>   http://markmail.org/thread/a5jl6fkjjtm5qbsw
>
> Even if Ole may have picked the wrong example with Tomcat, the
> actual request is to be able to follow the execution of a fairly
> complex algorithm, like an optimizer, when applied to a fairly
> complex user's code, in order to figure out whether there is a
> problem; and if so, where it is (in the user's model, in the
> call, in the optimizer, whether there is a mismatch between the
> user's expectations and the capability of the selected algorithm,
> etc.)
>
> Ole's first example with an excerpt of the Levenberg-Marquardt
> implementation is actually a hit: a few years ago, a bug was found
> somewhere right around that same code:
>   https://issues.apache.org/jira/browse/MATH-406
> It's an example where logging is a valuable help in debugging.
> Another is the poor man's logging fiddling to track the cause of
> the erratic behaviour of one of the CI machines.
>
> Gilles
>
>
> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>>>
>>>
>>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>>
 I disagree. Good tests, API contracts, exception management and
 documentation can and should eliminate the need for cluttering
 low-level library code with debug logging.

>>>
>>> Logging could be viewed as clutter.  Constructed the right way,
>>> the logging statements could also be viewed as comments.
>>>
>>> I agree that good tests, API contracts, and in general keeping the
>>> design as minimalistic and simple as possible should be the first
>>> criteria to review before introducing logging.  When the code is
>>> trivial I leave logging out, unless I need to put in a few
>>> statements in order to track collaboration between components in
>>> an algorithm.
>>> Other times the method is as simple as it gets and I have to have
>>> logging.  For example take the LevenbergMarquardtOptimizer
>>> optimize() method.  It's atomic in the sense that what's in the
>>> method belongs in the method.  There are several loops within the
>>> main loop, etc. and tracking what's going, even with a observer
>>> being notified on each increment, would be far from elegant.
>>>
>>
>> Why, exactly do you need to "track what is going on?"  If you need
>> to do that as a user of the code, some kind of listener or API to
>> give you the information that you need is appropriate.  Dumping text
>> to an external resource to "solve" this usually indicates smelliness
>> somewhere - either in the library API or the client code.
>>
>>
>>> For example perhaps we want to see what's going on with the
>>> parameters in this small (5% of the method size) section of code:
>>>
>>
>> What parameters and where did they come from?  If from the client,
>> the client can validate them.  If the library needs to validate or
>> confirm suitability, then it should do that in code or via tests.
>>
>>>
>>> // compute the scaled predicted reduction
>>> // and the scaled directional derivative
>>> for (int j = 0; j < solvedCols; ++j) {
>>> int pj = permutation[j];
>>> double dirJ = lmDir[pj];
>>> work1[j] = 0;
>>> for (int i = 0; i <= j; ++i) {
>>> work1[i] += weightedJacobian[i][pj] * dirJ;
>>> }
>>> }
>>>
>>> If there is something wrong with this in production, the shortest
>>> path to figuring that out is reviewing a trace.  The longer path
>>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>>> the data.
>>>
>>> If we wanted to observe this section of code the observer would be
>>> looking at sub loops of of the optimize method.  So that's doable,
>>> but it creates an interface design for the observer that's
>>> cluttered with events corresponding to various low level algorithm
>>> details.
>>>
>>>
>>> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.
>

>>> It's pretty tragic that anyone of us should have to do this.  It's
>>> also wasteful, because if Gilles has to do this, then there's a
>>> good chance that others have to do it to.  The reason Tomcat logs
>>> at various levels is s

Re: [Math] Utilitzation of SLF4J?


On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:

I say something like: "I had to fork some CM class to insert
log statements."
You say something like: "No, you don't; write test or inspect
the code."

You had been more constructive:
  http://markmail.org/thread/a5jl6fkjjtm5qbsw

Even if Ole may have picked the wrong example with Tomcat, the
actual request is to be able to follow the execution of a fairly
complex algorithm, like an optimizer, when applied to a fairly
complex user's code, in order to figure out whether there is a
problem; and if so, where it is (in the user's model, in the
call, in the optimizer, whether there is a mismatch between the
user's expectations and the capability of the selected algorithm,
etc.)

Ole's first example with an excerpt of the Levenberg-Marquardt
implementation is actually a hit: a few years ago, a bug was found
somewhere right around that same code:
  https://issues.apache.org/jira/browse/MATH-406
It's an example where logging is a valuable help in debugging.
Another is the poor man's logging fiddling to track the cause of
the erratic behaviour of one of the CI machines.

Gilles


On 9/25/15 11:01 AM, Ole Ersoy wrote:



On 09/25/2015 11:34 AM, Phil Steitz wrote:

I disagree. Good tests, API contracts, exception management and
documentation can and should eliminate the need for cluttering
low-level library code with debug logging.


Logging could be viewed as clutter.  Constructed the right way,
the logging statements could also be viewed as comments.

I agree that good tests, API contracts, and in general keeping the
design as minimalistic and simple as possible should be the first
criteria to review before introducing logging.  When the code is
trivial I leave logging out, unless I need to put in a few
statements in order to track collaboration between components in
an algorithm.
Other times the method is as simple as it gets and I have to have
logging.  For example take the LevenbergMarquardtOptimizer
optimize() method.  It's atomic in the sense that what's in the
method belongs in the method.  There are several loops within the
main loop, etc. and tracking what's going, even with a observer
being notified on each increment, would be far from elegant.


Why, exactly do you need to "track what is going on?"  If you need
to do that as a user of the code, some kind of listener or API to
give you the information that you need is appropriate.  Dumping text
to an external resource to "solve" this usually indicates smelliness
somewhere - either in the library API or the client code.



For example perhaps we want to see what's going on with the
parameters in this small (5% of the method size) section of code:


What parameters and where did they come from?  If from the client,
the client can validate them.  If the library needs to validate or
confirm suitability, then it should do that in code or via tests.


// compute the scaled predicted reduction
// and the scaled directional derivative
for (int j = 0; j < solvedCols; ++j) {
int pj = permutation[j];
double dirJ = lmDir[pj];
work1[j] = 0;
for (int i = 0; i <= j; ++i) {
work1[i] += weightedJacobian[i][pj] * dirJ;
}
}

If there is something wrong with this in production, the shortest
path to figuring that out is reviewing a trace.  The longer path
is to stop the server.  Grab the data.  Open up a debugger.  Run
the data.

If we wanted to observe this section of code the observer would be
looking at sub loops of of the optimize method.  So that's doable,
but it creates an interface design for the observer that's
cluttered with events corresponding to various low level algorithm
details.


Several times, I've been obliged to create a modified version of 
CM

to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.


It's pretty tragic that anyone of us should have to do this.  It's
also wasteful, because if Gilles has to do this, then there's a
good chance that others have to do it to.  The reason Tomcat logs
at various levels is so that we can see what's going on in
production and track down bugs.


No.  Have a look at the Tomcat logging code.  It is mostly
initialization, shutdown and exceptions or warnings.  This is
necessary because tomcat is a container - there is no client
application to catch exceptions or get API results back.  The analog
for the kind of instrumentation you are proposing inside [math]
would be like tomcat larding itself up with debug logging throughout
the request processing lifecycle, which it does not do.   It is a
bad analogy in any case, because Tomcat is a container, which is 2
big steps up the processing chain from a low-level library.

Phil


Lets become one with the logging and make it into something that
strengthens both code inte

Re: [Math] Utilitzation of SLF4J?




On 09/25/2015 03:06 PM, Phil Steitz wrote:

On 9/25/15 11:01 AM, Ole Ersoy wrote:


On 09/25/2015 11:34 AM, Phil Steitz wrote:

I disagree. Good tests, API contracts, exception management and
documentation can and should eliminate the need for cluttering
low-level library code with debug logging.

Logging could be viewed as clutter.  Constructed the right way,
the logging statements could also be viewed as comments.

I agree that good tests, API contracts, and in general keeping the
design as minimalistic and simple as possible should be the first
criteria to review before introducing logging.  When the code is
trivial I leave logging out, unless I need to put in a few
statements in order to track collaboration between components in
an algorithm.
Other times the method is as simple as it gets and I have to have
logging.  For example take the LevenbergMarquardtOptimizer
optimize() method.  It's atomic in the sense that what's in the
method belongs in the method.  There are several loops within the
main loop, etc. and tracking what's going, even with a observer
being notified on each increment, would be far from elegant.

Why, exactly do you need to "track what is going on?"

I hope that I don't.  Most of the time code we write, especially the CM code, 
is rock solid.  When implementing complex algorithms we break it down to simple 
building blocks, reason about it, break it down some more, unit test it, and it 
looks fantastic.  Then we hit a snag, and start putting in println statements.  
Then we delete these after the fix, cut up 5 chickens, and pray.

If an issue occurs, then there is a low probability that it is a CM component.  
The traces can help prove that it is not the CM component.

If the code is now rock solid, then the log statements bother no one.  We put 
the code back in production, trace initially to make sure everything looks 
healthy, and then turn off logging.  On the flip side if we notice that 
something else seems off, we're back to putting in the println statements again.

Watching traces of CM components in production is an additional insurance 
policy for guaranteeing quality.

Also if there is an issue, and someone needs to understand it fast, the best 
way is to watch data flow through the system.  For new contributors, this could 
be a good way to get up to speed on an algorithm.



   If you need
to do that as a user of the code, some kind of listener or API to
give you the information that you need is appropriate.

I agree, but as I showed with the LevenbergMarquardtOptimizer attempting inject 
code into the optimize() method is a non trivial exercise.  Components should 
have a simple way to examine discrete steps that are being performed.


   Dumping text
to an external resource to "solve" this usually indicates smelliness
somewhere - either in the library API or the client code.

Or it is a precaution to ensure that no one forgot to flush.




For example perhaps we want to see what's going on with the
parameters in this small (5% of the method size) section of code:

What parameters and where did they come from?  If from the client,
the client can validate them.  If the library needs to validate or
confirm suitability, then it should do that in code or via tests.

 // compute the scaled predicted reduction
 // and the scaled directional derivative
 for (int j = 0; j < solvedCols; ++j) {
 int pj = permutation[j];
 double dirJ = lmDir[pj];
 work1[j] = 0;
 for (int i = 0; i <= j; ++i) {
 work1[i] += weightedJacobian[i][pj] * dirJ;
 }
 }

If there is something wrong with this in production, the shortest
path to figuring that out is reviewing a trace.  The longer path
is to stop the server.  Grab the data.  Open up a debugger.  Run
the data.

If we wanted to observe this section of code the observer would be
looking at sub loops of of the optimize method.  So that's doable,
but it creates an interface design for the observer that's
cluttered with events corresponding to various low level algorithm
details.



Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.

It's pretty tragic that anyone of us should have to do this.  It's
also wasteful, because if Gilles has to do this, then there's a
good chance that others have to do it to.  The reason Tomcat logs
at various levels is so that we can see what's going on in
production and track down bugs.

No.  Have a look at the Tomcat logging code.  It is mostly
initialization, shutdown and exceptions or warnings.


I agree, but I would argue that these should be far simpler to reason about 
than the life cycle of some of the CM algorithms.


   This is
necessary because tomcat is a container - there is no cli

[validator] Inconsistent behavior in UrlValidator

2015-09-25 Thread Adrian Crum

I was just looking at the UrlValidator test and I noticed that localhost 
is allowed in the URL if the ALLOW_LOCAL_URLS flag is set, and it is not 
allowed if the ALLOW_LOCAL_URLS flag is not set.


If the ALLOW_LOCAL_URLS is not set, a loopback IP address (127.0.0.1) 
URL will validate. It seems to me that it shouldn't - to be consistent 
with the localhost behavior.


What do you think?

--
Adrian Crum
Sandglass Software
www.sandglass-software.com

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

Re: [Math] Utilitzation of SLF4J?

On 9/25/15 11:01 AM, Ole Ersoy wrote:
>
>
> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>> I disagree. Good tests, API contracts, exception management and
>> documentation can and should eliminate the need for cluttering
>> low-level library code with debug logging.
>
> Logging could be viewed as clutter.  Constructed the right way,
> the logging statements could also be viewed as comments.
>
> I agree that good tests, API contracts, and in general keeping the
> design as minimalistic and simple as possible should be the first
> criteria to review before introducing logging.  When the code is
> trivial I leave logging out, unless I need to put in a few
> statements in order to track collaboration between components in
> an algorithm.  
> Other times the method is as simple as it gets and I have to have
> logging.  For example take the LevenbergMarquardtOptimizer
> optimize() method.  It's atomic in the sense that what's in the
> method belongs in the method.  There are several loops within the
> main loop, etc. and tracking what's going, even with a observer
> being notified on each increment, would be far from elegant.

Why, exactly do you need to "track what is going on?"  If you need
to do that as a user of the code, some kind of listener or API to
give you the information that you need is appropriate.  Dumping text
to an external resource to "solve" this usually indicates smelliness
somewhere - either in the library API or the client code.

>
> For example perhaps we want to see what's going on with the
> parameters in this small (5% of the method size) section of code:

What parameters and where did they come from?  If from the client,
the client can validate them.  If the library needs to validate or
confirm suitability, then it should do that in code or via tests.
>
> // compute the scaled predicted reduction
> // and the scaled directional derivative
> for (int j = 0; j < solvedCols; ++j) {
> int pj = permutation[j];
> double dirJ = lmDir[pj];
> work1[j] = 0;
> for (int i = 0; i <= j; ++i) {
> work1[i] += weightedJacobian[i][pj] * dirJ;
> }
> }
>
> If there is something wrong with this in production, the shortest
> path to figuring that out is reviewing a trace.  The longer path
> is to stop the server.  Grab the data.  Open up a debugger.  Run
> the data.
>
> If we wanted to observe this section of code the observer would be
> looking at sub loops of of the optimize method.  So that's doable,
> but it creates an interface design for the observer that's
> cluttered with events corresponding to various low level algorithm
> details.
>
>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>
> It's pretty tragic that anyone of us should have to do this.  It's
> also wasteful, because if Gilles has to do this, then there's a
> good chance that others have to do it to.  The reason Tomcat logs
> at various levels is so that we can see what's going on in
> production and track down bugs.

No.  Have a look at the Tomcat logging code.  It is mostly
initialization, shutdown and exceptions or warnings.  This is
necessary because tomcat is a container - there is no client
application to catch exceptions or get API results back.  The analog
for the kind of instrumentation you are proposing inside [math]
would be like tomcat larding itself up with debug logging throughout
the request processing lifecycle, which it does not do.   It is a
bad analogy in any case, because Tomcat is a container, which is 2
big steps up the processing chain from a low-level library.

Phil

> Lets become one with the logging and make it into something that
> strengthens both code integrity and comprehensibility.  Everyone
> take take out your Feng Shui mat and do some deep breathing right
> now.
>
>> Here again, tests, good design, code inspection are the way to go in
>> low-level components.  I have also spent a lot of time researching
>> bugs in [math], other Commons components and other complex systems.
>> My experience is a little different: excessive logging / debug code
>> for code that contains it often just tends to get in the way,
> It's a very good point.  Sometimes we come across logging
> statements that are just noise.  Given how rigorous we are about
> reviewing everything though, I think a win win would be to limit
> the noise during code review, and pledge not to "Call our mom" in
> the middle of the code, etc.
>
>> especially after it has rotted a bit.  Rather than adding more code
>> to maintain so that you can have less conceptual control over the
>> functional code, it is better, IMNSHO, to focus on making the
>> functional code as simple as possible with clean well-documented,
>>

Re: [Math] Utilization of Lombok




On 09/25/2015 12:55 PM, Thomas Neidhart wrote:

On 09/25/2015 05:04 PM, Ole Ersoy wrote:

Hi Thomas,

On 09/25/2015 08:45 AM, Thomas Neidhart wrote:

Hi Ole,

can you explain why you think that the addition of lombok brings any
benefit to our users?

Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
the following set of parameters:

 /* configuration parameters */
 /** Positive input variable used in determining the initial step
bound. */
 private final double initialStepBoundFactor;
 /** Desired relative error in the sum of squares. */
 private final double costRelativeTolerance;
 /**  Desired relative error in the approximate solution parameters. */
 private final double parRelativeTolerance;
 /** Desired max cosine on the orthogonality between the function vector
  * and the columns of the jacobian. */
 private final double orthoTolerance;
 /** Threshold for QR ranking. */
 private final double qrRankingThreshold;

And corresponding getters:
 /**
  * Gets the value of a tuning parameter.
  * @see #withInitialStepBoundFactor(double)
  *
  * @return the parameter's value.
  */
 public double getInitialStepBoundFactor() {
 return initialStepBoundFactor;
 }

 /**
  * Gets the value of a tuning parameter.
  * @see #withCostRelativeTolerance(double)
  *
  * @return the parameter's value.
  */
 public double getCostRelativeTolerance() {
 return costRelativeTolerance;
 }

 /**
  * Gets the value of a tuning parameter.
  * @see #withParameterRelativeTolerance(double)
  *
  * @return the parameter's value.
  */
 public double getParameterRelativeTolerance() {
 return parRelativeTolerance;
 }

 /**
  * Gets the value of a tuning parameter.
  * @see #withOrthoTolerance(double)
  *
  * @return the parameter's value.
  */
 public double getOrthoTolerance() {
 return orthoTolerance;
 }

 /**
  * Gets the value of a tuning parameter.
  * @see #withRankingThreshold(double)
  *
  * @return the parameter's value.
  */
 public double getRankingThreshold() {
 return qrRankingThreshold;
 }

Lombok will generate all of these.  Eclipse can do the same thing, but
if we delete one of the parameters, then the corresponding getter also
has to be deleted.  Also Lombok cuts down on the source code noise,
since it is a byte code generator.  The generated code does not appear
in the source.

Lombok also has a @Builder annotation that can be used to generate a
inner static builder class that provides a fluent construction API. So
if we break off the LevenbergMarquardtOptimizer configuration into its
own class, and generate all the getters and the fluid API, there should
be substantial code reduction.

Gilles is also working on a snapshot capability for neural nets, and the
@Synchronized annotation could come in handy here.  These are the items
I have looked at so far.


>From my point of view, lombok can help developers by taking over some
tedious tasks, but this is quite irrelevant in the case of CM as the
majority of work goes into algorithm design and verification rather
than in
writing getters/setters (which btw has pretty good IDE support).

I agree that the majority of time goes into the design of the
algorithm.  For me personally, when I'm looking at code, and it has a
ton of boilerplate, it does slow my productivity...just because of all
the noise.  I'm happy once I've gotten it as DRY as possible.

The more boilerplate, the more reluctant we are going to be to undertake
refactoring, and we will make more mistakes (At least I will :) ).


   So this
would just add additional complexity and the gain is very unclear.

I think you will find it refreshing once you try it.  At this point
though I just wanted to float the idea.  I'll complete the experiment
and publish the result.  At that point we will have a good baseline to
gage whether adding it will add enough value to offset the cost of
adding it.

Well I know lombok.

Super!


Keep in mind that it is a bit more difficult to integrate it into our
build-chain. As you probably know, in order to generate proper javadoc,
you need to use delombok first to create source files which can be used
for the javadoc process.

I was thinking about that too actually.  Here's how I was thinking it could be 
done in the case of the LevenbergMarquardtOptimizer. First split the 
configuration piece off.  Then javadoc the properties of the configuration 
only.  In the class header explain that the boilerplate has been generated 
using Lombok and put a reference to it there.  If someone is smart enough to 
figure out how to work with the optimizer, then this should be trivial.

So to summarize - move to a process of providing minimal javadoc and zero 
boilerplate.  Explain to users that Lombok is used to facilitate this, so 
methods

Re: [Math] Utilitzation of SLF4J?




On 09/25/2015 11:34 AM, Phil Steitz wrote:

I disagree. Good tests, API contracts, exception management and documentation 
can and should eliminate the need for cluttering low-level library code with 
debug logging.


Logging could be viewed as clutter.  Constructed the right way, the logging 
statements could also be viewed as comments.

I agree that good tests, API contracts, and in general keeping the design as 
minimalistic and simple as possible should be the first criteria to review 
before introducing logging.  When the code is trivial I leave logging out, 
unless I need to put in a few statements in order to track collaboration 
between components in an algorithm.  Other times the method is as simple as it 
gets and I have to have logging.  For example take the 
LevenbergMarquardtOptimizer optimize() method.  It's atomic in the sense that 
what's in the method belongs in the method.  There are several loops within the 
main loop, etc. and tracking what's going, even with a observer being notified 
on each increment, would be far from elegant.

For example perhaps we want to see what's going on with the parameters in this 
small (5% of the method size) section of code:

// compute the scaled predicted reduction
// and the scaled directional derivative
for (int j = 0; j < solvedCols; ++j) {
int pj = permutation[j];
double dirJ = lmDir[pj];
work1[j] = 0;
for (int i = 0; i <= j; ++i) {
work1[i] += weightedJacobian[i][pj] * dirJ;
}
}

If there is something wrong with this in production, the shortest path to 
figuring that out is reviewing a trace.  The longer path is to stop the server. 
 Grab the data.  Open up a debugger.  Run the data.

If we wanted to observe this section of code the observer would be looking at 
sub loops of of the optimize method.  So that's doable, but it creates an 
interface design for the observer that's cluttered with events corresponding to 
various low level algorithm details.



Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.


It's pretty tragic that anyone of us should have to do this.  It's also 
wasteful, because if Gilles has to do this, then there's a good chance that 
others have to do it to.  The reason Tomcat logs at various levels is so that 
we can see what's going on in production and track down bugs.  Lets become one 
with the logging and make it into something that strengthens both code 
integrity and comprehensibility.  Everyone take take out your Feng Shui mat and 
do some deep breathing right now.


Here again, tests, good design, code inspection are the way to go in
low-level components.  I have also spent a lot of time researching
bugs in [math], other Commons components and other complex systems.
My experience is a little different: excessive logging / debug code
for code that contains it often just tends to get in the way,

It's a very good point.  Sometimes we come across logging statements that are just noise. 
 Given how rigorous we are about reviewing everything though, I think a win win would be 
to limit the noise during code review, and pledge not to "Call our mom" in the 
middle of the code, etc.


especially after it has rotted a bit.  Rather than adding more code
to maintain so that you can have less conceptual control over the
functional code, it is better, IMNSHO, to focus on making the
functional code as simple as possible with clean well-documented,
test-validated API contracts.


Totally agree.  I think this should be the first priority, and that logging 
should be used when there are no simple clean alternatives.




It also makes a code easier to debug while developing or modifying it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).

Pretty sure we have all been here.

Cheers,
- Ole




Gilles

[1] No quality or complexity judgment implied.


Phil


Gilles


Thomas


On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
wrote:


Hello,

We have been discussing various ways to view what's happening
internally
with algorithms, and the topic of including SLF4J has come up.
I know that
this was discussed earlier and it was decided that CM is a low
level
dependency, therefore it should minimize the transitive
dependencies that
it introduces.  The Java community has adopted many means of
dealing with
potential logging conflicts, so I'm requesting that we use SLF4J
for
logging.

I know that JBoss introduced its own logging system, and this
made me a
bit nervous about this suggestion, so I looked up strategies for
switching
their logger out with SLF4J:



http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j



The ge

Re: [Math] Utilization of Lombok

On 09/25/2015 05:04 PM, Ole Ersoy wrote:
> Hi Thomas,
> 
> On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> can you explain why you think that the addition of lombok brings any
>> benefit to our users?
> Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
> the following set of parameters:
> 
> /* configuration parameters */
> /** Positive input variable used in determining the initial step
> bound. */
> private final double initialStepBoundFactor;
> /** Desired relative error in the sum of squares. */
> private final double costRelativeTolerance;
> /**  Desired relative error in the approximate solution parameters. */
> private final double parRelativeTolerance;
> /** Desired max cosine on the orthogonality between the function vector
>  * and the columns of the jacobian. */
> private final double orthoTolerance;
> /** Threshold for QR ranking. */
> private final double qrRankingThreshold;
> 
> And corresponding getters:
> /**
>  * Gets the value of a tuning parameter.
>  * @see #withInitialStepBoundFactor(double)
>  *
>  * @return the parameter's value.
>  */
> public double getInitialStepBoundFactor() {
> return initialStepBoundFactor;
> }
> 
> /**
>  * Gets the value of a tuning parameter.
>  * @see #withCostRelativeTolerance(double)
>  *
>  * @return the parameter's value.
>  */
> public double getCostRelativeTolerance() {
> return costRelativeTolerance;
> }
> 
> /**
>  * Gets the value of a tuning parameter.
>  * @see #withParameterRelativeTolerance(double)
>  *
>  * @return the parameter's value.
>  */
> public double getParameterRelativeTolerance() {
> return parRelativeTolerance;
> }
> 
> /**
>  * Gets the value of a tuning parameter.
>  * @see #withOrthoTolerance(double)
>  *
>  * @return the parameter's value.
>  */
> public double getOrthoTolerance() {
> return orthoTolerance;
> }
> 
> /**
>  * Gets the value of a tuning parameter.
>  * @see #withRankingThreshold(double)
>  *
>  * @return the parameter's value.
>  */
> public double getRankingThreshold() {
> return qrRankingThreshold;
> }
> 
> Lombok will generate all of these.  Eclipse can do the same thing, but
> if we delete one of the parameters, then the corresponding getter also
> has to be deleted.  Also Lombok cuts down on the source code noise,
> since it is a byte code generator.  The generated code does not appear
> in the source.
> 
> Lombok also has a @Builder annotation that can be used to generate a
> inner static builder class that provides a fluent construction API. So
> if we break off the LevenbergMarquardtOptimizer configuration into its
> own class, and generate all the getters and the fluid API, there should
> be substantial code reduction.
> 
> Gilles is also working on a snapshot capability for neural nets, and the
> @Synchronized annotation could come in handy here.  These are the items
> I have looked at so far.
> 
>>
>> >From my point of view, lombok can help developers by taking over some
>> tedious tasks, but this is quite irrelevant in the case of CM as the
>> majority of work goes into algorithm design and verification rather
>> than in
>> writing getters/setters (which btw has pretty good IDE support).
> 
> I agree that the majority of time goes into the design of the
> algorithm.  For me personally, when I'm looking at code, and it has a
> ton of boilerplate, it does slow my productivity...just because of all
> the noise.  I'm happy once I've gotten it as DRY as possible.
> 
> The more boilerplate, the more reluctant we are going to be to undertake
> refactoring, and we will make more mistakes (At least I will :) ).
> 
>>   So this
>> would just add additional complexity and the gain is very unclear.
> I think you will find it refreshing once you try it.  At this point
> though I just wanted to float the idea.  I'll complete the experiment
> and publish the result.  At that point we will have a good baseline to
> gage whether adding it will add enough value to offset the cost of
> adding it.

Well I know lombok.

Keep in mind that it is a bit more difficult to integrate it into our
build-chain. As you probably know, in order to generate proper javadoc,
you need to use delombok first to create source files which can be used
for the javadoc process.

In general I do not think that lombok is the right tool for a library
like CM, and I do not know any other library that uses lombok. It
certainly has strengths and uses for application development though.

Thomas

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

Re: [Math] Utilitzation of SLF4J?

On 9/25/15 8:09 AM, Gilles wrote:
> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>> On 9/25/15 7:03 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
 Hi Ole,

 for a start, I think you are asking the wrong question.
 First of all we need to agree that we want to add some kind of
 logging
 facility to CM.
 If the outcome is positive, there are a handful of alternatives,
 some of
 them more viable than slf4j in the context of CM (e.g. JUL or
 commons-logging).
>>>
>>> Could someone summarize why those alternatives were deemed "more
>>> viable"?
>>>
 btw. the same discussion has been done for other commons
 components as
 well, and the result usually was: do not add logging
>>>
>>> What was the rationale?
>>
>> Look at the archives.  We have discussed this multiple times in the
>> past in [math] and each time came to the conclusion that Thomas
>> succinctly states above.  What has changed now?
>
> We also discussed several times to stick with Java 5.
> Fortunately, that has changed. [Although sticking with Java 7 is
> still
> a bad decision IMHO.]
>
> As for logging, IIRC, the sole argument was "no dependency" because
> (IIRC) of the potential "JAR hell".
>
> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]

I disagree.  Good tests, API contracts, exception management and
documentation can and should eliminate the need for cluttering
low-level library code with debug logging.
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.

Here again, tests, good design, code inspection are the way to go in
low-level components.  I have also spent a lot of time researching
bugs in [math], other Commons components and other complex systems. 
My experience is a little different: excessive logging / debug code
for code that contains it often just tends to get in the way,
especially after it has rotted a bit.  Rather than adding more code
to maintain so that you can have less conceptual control over the
functional code, it is better, IMNSHO, to focus on making the
functional code as simple as possible with clean well-documented,
test-validated API contracts.  

> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>> Phil
>>>
>>>
>>> Gilles
>>>
 Thomas


 On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
 wrote:

> Hello,
>
> We have been discussing various ways to view what's happening
> internally
> with algorithms, and the topic of including SLF4J has come up.
> I know that
> this was discussed earlier and it was decided that CM is a low
> level
> dependency, therefore it should minimize the transitive
> dependencies that
> it introduces.  The Java community has adopted many means of
> dealing with
> potential logging conflicts, so I'm requesting that we use SLF4J
> for
> logging.
>
> I know that JBoss introduced its own logging system, and this
> made me a
> bit nervous about this suggestion, so I looked up strategies for
> switching
> their logger out with SLF4J:
>
>
>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>
>
>
> The general process I go through when working with many
> dependencies that
> might use commons-logging instead of SLF4J looks something like
> this:
>
>
>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>
>
>
> With JDK9 individual modules can define their own isolated set of
> dependencies.  At this point the fix should be a permanent.  If
> someone has
> has a very intricate scenario that we have not yet seen, they
> could use
> (And probably should use) OSGi to isolate dependencies.
>
> WDYT?
>
> Cheers,
> - Ole
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> .
>



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

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Gary Gregory

On Fri, Sep 25, 2015 at 8:50 AM, Phil Steitz  wrote:

> On 9/25/15 8:45 AM, Ole Ersoy wrote:
> > Hi Thomas,
> >
> > On 09/25/2015 08:54 AM, Thomas Neidhart wrote:
> >> Hi Ole,
> >>
> >> for a start, I think you are asking the wrong question.
> >> First of all we need to agree that we want to add some kind of
> >> logging
> >> facility to CM.
> > Well it has to be SLF4J because that's the one I'm most familiar
> > with :).  We did discuss having observers that can listen in on
> > increment events that algorithms publish.  This would provide a
> > dependency free method for doing so with one drawback.  Now
> > everyone that wants the algorithm to log has to implement logging.
>
> This is the right approach, IMO, for reasons that have been stated
> in the archives.  Has more as much to do with separation of concerns
> and clean API contracts as dependencies and conflicts.
>

Note that Log4j 2 (we just released 2.4) has a clean separation between
logging API and implementations, including it's own of course.

We are also an active group of developers here to help you should you it!
:-)

https://logging.apache.org/log4j/2.x/index.html

Gary


>
> Phil
> >
> >> If the outcome is positive, there are a handful of alternatives,
> >> some of
> >> them more viable than slf4j in the context of CM (e.g. JUL or
> >> commons-logging).
> > Would you be upset if it was SLF4J?  This is minor, but I like the
> > @SLF4J annotation that Lombok provides.
> >
> >>
> >> btw. the same discussion has been done for other commons
> >> components as
> >> well, and the result usually was: do not add logging
> > I think for the reason that commons should not introduce
> > transitive dependencies?  This has been solved fairly well (Below).
> >
> > Cheers,
> > - Ole
> >
> >>
> >> Thomas
> >>
> >>
> >> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> We have been discussing various ways to view what's happening
> >>> internally
> >>> with algorithms, and the topic of including SLF4J has come up.
> >>> I know that
> >>> this was discussed earlier and it was decided that CM is a low
> >>> level
> >>> dependency, therefore it should minimize the transitive
> >>> dependencies that
> >>> it introduces.  The Java community has adopted many means of
> >>> dealing with
> >>> potential logging conflicts, so I'm requesting that we use SLF4J
> >>> for
> >>> logging.
> >>>
> >>> I know that JBoss introduced its own logging system, and this
> >>> made me a
> >>> bit nervous about this suggestion, so I looked up strategies for
> >>> switching
> >>> their logger out with SLF4J:
> >>>
> >>>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
> >>>
> >>>
> >>> The general process I go through when working with many
> >>> dependencies that
> >>> might use commons-logging instead of SLF4J looks something like
> >>> this:
> >>>
> >>>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
> >>>
> >>>
> >>> With JDK9 individual modules can define their own isolated set of
> >>> dependencies.  At this point the fix should be a permanent.  If
> >>> someone has
> >>> has a very intricate scenario that we have not yet seen, they
> >>> could use
> >>> (And probably should use) OSGi to isolate dependencies.
> >>>
> >>> WDYT?
> >>>
> >>> Cheers,
> >>> - Ole
> >>>
> >>>
> >>> -
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
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] Utilitzation of SLF4J?

On 9/25/15 8:45 AM, Ole Ersoy wrote:
> Hi Thomas,
>
> On 09/25/2015 08:54 AM, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
> Well it has to be SLF4J because that's the one I'm most familiar
> with :).  We did discuss having observers that can listen in on
> increment events that algorithms publish.  This would provide a
> dependency free method for doing so with one drawback.  Now
> everyone that wants the algorithm to log has to implement logging.

This is the right approach, IMO, for reasons that have been stated
in the archives.  Has more as much to do with separation of concerns
and clean API contracts as dependencies and conflicts.

Phil
>
>> If the outcome is positive, there are a handful of alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
> Would you be upset if it was SLF4J?  This is minor, but I like the
> @SLF4J annotation that Lombok provides.
>
>>
>> btw. the same discussion has been done for other commons
>> components as
>> well, and the result usually was: do not add logging
> I think for the reason that commons should not introduce
> transitive dependencies?  This has been solved fairly well (Below).
>
> Cheers,
> - Ole
>
>>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up. 
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


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

Re: [Math] Utilitzation of SLF4J?

Hi Thomas,

On 09/25/2015 08:54 AM, Thomas Neidhart wrote:

Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of logging
facility to CM.

Well it has to be SLF4J because that's the one I'm most familiar with :). We
did discuss having observers that can listen in on increment events that
algorithms publish. This would provide a dependency free method for doing so
with one drawback. Now everyone that wants the algorithm to log has to
implement logging.

If the outcome is positive, there are a handful of alternatives, some of
them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).

Would you be upset if it was SLF4J? This is minor, but I like the @SLF4J
annotation that Lombok provides.

btw. the same discussion has been done for other commons components as
well, and the result usually was: do not add logging

I think for the reason that commons should not introduce transitive
dependencies? This has been solved fairly well (Below).

Cheers,
- Ole

Thomas

On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy wrote:

Hello,

We have been discussing various ways to view what's happening internally
with algorithms, and the topic of including SLF4J has come up. I know that
this was discussed earlier and it was decided that CM is a low level
dependency, therefore it should minimize the transitive dependencies that
it introduces. The Java community has adopted many means of dealing with
potential logging conflicts, so I'm requesting that we use SLF4J for
logging.

I know that JBoss introduced its own logging system, and this made me a
bit nervous about this suggestion, so I looked up strategies for switching
their logger out with SLF4J:

http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many dependencies that
might use commons-logging instead of SLF4J looks something like this:

http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of
dependencies. At this point the fix should be a permanent. If someone has
has a very intricate scenario that we have not yet seen, they could use
(And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole

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

Re: [Math] Utilitzation of SLF4J?

On Fri, Sep 25, 2015 at 5:09 PM, Gilles 
wrote:

> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>
>> On 9/25/15 7:03 AM, Gilles wrote:
>>
>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>
 Hi Ole,

 for a start, I think you are asking the wrong question.
 First of all we need to agree that we want to add some kind of
 logging
 facility to CM.
 If the outcome is positive, there are a handful of alternatives,
 some of
 them more viable than slf4j in the context of CM (e.g. JUL or
 commons-logging).

>>>
>>> Could someone summarize why those alternatives were deemed "more
>>> viable"?
>>>
>>> btw. the same discussion has been done for other commons
 components as
 well, and the result usually was: do not add logging

>>>
>>> What was the rationale?
>>>
>>
>> Look at the archives.  We have discussed this multiple times in the
>> past in [math] and each time came to the conclusion that Thomas
>> succinctly states above.  What has changed now?
>>
>
> We also discussed several times to stick with Java 5.
> Fortunately, that has changed. [Although sticking with Java 7 is still
> a bad decision IMHO.]
>
> As for logging, IIRC, the sole argument was "no dependency" because
> (IIRC) of the potential "JAR hell".
>

that's not correct. The decision to not include any dependencies has
nothing to do with "JAR hell".

In order to prevent JAR hell, commons components strictly stick to the
"Versioning guidelines" [1]

The no-dependency rule is more related to the proposal of the component,
see [2]

[1] http://commons.apache.org/releases/versioning.html
[2] http://commons.apache.org/proper/commons-math/proposal.html

Thomas


> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.
> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>
> Phil
>>
>>>
>>>
>>> Gilles
>>>
>>> Thomas


 On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
 wrote:

 Hello,
>
> We have been discussing various ways to view what's happening
> internally
> with algorithms, and the topic of including SLF4J has come up.
> I know that
> this was discussed earlier and it was decided that CM is a low
> level
> dependency, therefore it should minimize the transitive
> dependencies that
> it introduces.  The Java community has adopted many means of
> dealing with
> potential logging conflicts, so I'm requesting that we use SLF4J
> for
> logging.
>
> I know that JBoss introduced its own logging system, and this
> made me a
> bit nervous about this suggestion, so I looked up strategies for
> switching
> their logger out with SLF4J:
>
>
>
>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>
>
> The general process I go through when working with many
> dependencies that
> might use commons-logging instead of SLF4J looks something like
> this:
>
>
>
>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>
>
> With JDK9 individual modules can define their own isolated set of
> dependencies.  At this point the fix should be a permanent.  If
> someone has
> has a very intricate scenario that we have not yet seen, they
> could use
> (And probably should use) OSGi to isolate dependencies.
>
> WDYT?
>
> Cheers,
> - Ole
>

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

Re: [Math] Utilitzation of SLF4J?

On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:

On 9/25/15 7:03 AM, Gilles wrote:

On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:

Hi Ole,

Could someone summarize why those alternatives were deemed "more
viable"?

btw. the same discussion has been done for other commons
components as
well, and the result usually was: do not add logging

What was the rationale?

Look at the archives. We have discussed this multiple times in the
past in [math] and each time came to the conclusion that Thomas
succinctly states above. What has changed now?

We also discussed several times to stick with Java 5.
Fortunately, that has changed. [Although sticking with Java 7 is still
a bad decision IMHO.]

As for logging, IIRC, the sole argument was "no dependency" because
(IIRC) of the potential "JAR hell".

If there are now well-formed answers proving that the fear was
unfounded, that is also a change.

IMO, logging is quite important for any "non-obvious" code.[1]
[I'm again stating that, in that respect, CM is not like the other
"Commmons" components.]

Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.
It also makes a code easier to debug while developing or modifying it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).

Gilles

[1] No quality or complexity judgment implied.

Phil

Gilles

Thomas

On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy
wrote:

Hello,

I know that JBoss introduced its own logging system, and this
made me a
bit nervous about this suggestion, so I looked up strategies for
switching
their logger out with SLF4J:

http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many
dependencies that
might use commons-logging instead of SLF4J looks something like
this:

http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of
dependencies. At this point the fix should be a permanent. If
someone has
has a very intricate scenario that we have not yet seen, they
could use
(And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole

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

Re: [Math] Utilization of Lombok


Hi Thomas,

On 09/25/2015 08:45 AM, Thomas Neidhart wrote:

Hi Ole,

can you explain why you think that the addition of lombok brings any
benefit to our users?

Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has the 
following set of parameters:

/* configuration parameters */
/** Positive input variable used in determining the initial step bound. */
private final double initialStepBoundFactor;
/** Desired relative error in the sum of squares. */
private final double costRelativeTolerance;
/**  Desired relative error in the approximate solution parameters. */
private final double parRelativeTolerance;
/** Desired max cosine on the orthogonality between the function vector
 * and the columns of the jacobian. */
private final double orthoTolerance;
/** Threshold for QR ranking. */
private final double qrRankingThreshold;

And corresponding getters:
/**
 * Gets the value of a tuning parameter.
 * @see #withInitialStepBoundFactor(double)
 *
 * @return the parameter's value.
 */
public double getInitialStepBoundFactor() {
return initialStepBoundFactor;
}

/**
 * Gets the value of a tuning parameter.
 * @see #withCostRelativeTolerance(double)
 *
 * @return the parameter's value.
 */
public double getCostRelativeTolerance() {
return costRelativeTolerance;
}

/**
 * Gets the value of a tuning parameter.
 * @see #withParameterRelativeTolerance(double)
 *
 * @return the parameter's value.
 */
public double getParameterRelativeTolerance() {
return parRelativeTolerance;
}

/**
 * Gets the value of a tuning parameter.
 * @see #withOrthoTolerance(double)
 *
 * @return the parameter's value.
 */
public double getOrthoTolerance() {
return orthoTolerance;
}

/**
 * Gets the value of a tuning parameter.
 * @see #withRankingThreshold(double)
 *
 * @return the parameter's value.
 */
public double getRankingThreshold() {
return qrRankingThreshold;
}

Lombok will generate all of these.  Eclipse can do the same thing, but if we 
delete one of the parameters, then the corresponding getter also has to be 
deleted.  Also Lombok cuts down on the source code noise, since it is a byte 
code generator.  The generated code does not appear in the source.

Lombok also has a @Builder annotation that can be used to generate a inner 
static builder class that provides a fluent construction API. So if we break 
off the LevenbergMarquardtOptimizer configuration into its own class, and 
generate all the getters and the fluid API, there should be substantial code 
reduction.

Gilles is also working on a snapshot capability for neural nets, and the 
@Synchronized annotation could come in handy here.  These are the items I have 
looked at so far.



>From my point of view, lombok can help developers by taking over some
tedious tasks, but this is quite irrelevant in the case of CM as the
majority of work goes into algorithm design and verification rather than in
writing getters/setters (which btw has pretty good IDE support).


I agree that the majority of time goes into the design of the algorithm.  For 
me personally, when I'm looking at code, and it has a ton of boilerplate, it 
does slow my productivity...just because of all the noise.  I'm happy once I've 
gotten it as DRY as possible.

The more boilerplate, the more reluctant we are going to be to undertake 
refactoring, and we will make more mistakes (At least I will :) ).


  So this
would just add additional complexity and the gain is very unclear.

I think you will find it refreshing once you try it.  At this point though I 
just wanted to float the idea.  I'll complete the experiment and publish the 
result.  At that point we will have a good baseline to gage whether adding it 
will add enough value to offset the cost of adding it.

Cheers,
- Ole


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

Re: [Math] LeastSquaresOptimizer Design




On 09/25/2015 06:55 AM, Gilles wrote:

On Thu, 24 Sep 2015 21:41:10 -0500, Ole Ersoy wrote:

On 09/24/2015 06:01 PM, Gilles wrote:

On Thu, 24 Sep 2015 17:02:15 -0500, Ole Ersoy wrote:

On 09/24/2015 03:23 PM, Luc Maisonobe wrote:

Le 24/09/2015 21:40, Ole Ersoy a écrit :

Hi Luc,

I gave this some more thought, and I think I may have tapped out to
soon, even though you are absolutely right about what an exception does
in terms bubbling execution to a point where it stops or we handle it.

Suppose we have an Optimizer and an Optimizer observer. The optimizer
will emit three different events given in the process of stepping
through to the max number of iterations it is allotted:
- SOLUTION_FOUND
- COULD_NOT_CONVERGE_FOR_REASON_1
- COULD_NOT_CONVERGE_FOR_REASON_2
- END (Max iterations reached)

So we have the observer interface:

interface OptimizerObserver {

 success(Solution solution)
 update(Enum enum, Optimizer optimizer)
 end(Optimizer optimizer)
}

So if the Optimizer notifies the observer of `success`, then the
observer does what it needs to with the results and moves on.  If the
observer gets an `update` notification, that means that given the
current [constraints, numbers of iterations, data] the optimizer cannot
finish.  But the update method receives the optimizer, so it can adapt
it, and tell it to continue or just trash it and try something
completely different.  If the `END` event is reached then the Optimizer
could not finish given the number of allotted iterations. The Optimizer
is passed back via the callback interface so the observer could allow
more iterations if it wants to...perhaps based on some metric indicating
how close the optimizer is to finding a solution.

What this could do is allow the implementation of the observer to throw
the exception if 'All is lost!', in which case the Optimizer does not
need an exception.  Totally understand that this may not work
everywhere, but it seems like it could work in this case.

WDYT?

With this version, you should also pass the optimizer in case of
success. In most cases, the observer will just ignore it, but in some
cases it may try to solve another problem, or to solve again with
stricter constraints, using the previous solution as the start point
for the more stringent problem. Another case would be to go from a
simple problem to a more difficult problem using some kind of
homotopy.

Great - whoooh - glad you like this version a little better - for a
sec I thought I had complete lost it :).


IIUC, I don't like it: it looks like "GOTO"...


Inside the optimizer it would work like this:

while (!done) {
   if (can't converge) {
   observer.update(Enum.CANT_CONVERGE, this);
   }
}


That's fine. What I don't like is to have provision for changing the
optimizer's settings and reuse the same instance.

If the design of the optimizer allows for this, then the interface for the 
Observer would facilitate it.  The person implementing the interface could 
throw an exception when they get the Enum.CANT_CONVERGE message, in which case 
the semantics are the same as they are now.

On the other hand if the optimizer is not designed for reuse, perhaps for the 
reason that it causes more complexity than it's worth, the Observer interface 
could just exclude this aspect.


The optimizer should be instantiated at the lowest possible level; it
will report everything to the observer, but the "report" is not to be
confused with the "optimizer".

The design of the observer is flexible.  It gives the person implementing the 
interface the ability to change the state of what is being observed.  It's a 
bit like warming up leftovers.  You are the observer.  You grab yesterdays the 
pizza.  Throw in in the microwave.  The microwave is the optimizer.  We hit the 
30 second button, and check on the pizza.  If we like it, we take it out, 
otherwise we hit 30 seconds again, or we throw the whole thing out, because we 
just realized that the Pizza rat took a chunk out:
https://www.youtube.com/watch?v=UPXUG8q4jKU





Then in the update method either modify the optimizer's parameters or
throw an exception.


If I'm referring to Luc's example of a high-level code "H" call to some
mid-level code "M" itself calling CM's optimizer "CM", then "M" may not
have enough info to know whether it's OK to retry "CM", but on the other
hand, "H" might not even be aware that "M" is using "CM".

So in this case the person implementing the Observer interface would keep the 
semantics that we have now.  There is one important distinction though.  The 
person uses the Enum parameter, indicating the root cause of the message, to 
throw their own (Meaningful to them) exception.



As I tried to explain several times along the years (but failed to
convince) is that the same problem exists with the exceptions: however
detailed the message, it might not make sense to the person that reads
the console because he is at level "H" and may have no idea that "CM"
is used deep down

Re: [Math] Utilitzation of SLF4J?

On 9/25/15 7:03 AM, Gilles wrote:
> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
>> If the outcome is positive, there are a handful of alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
>
> Could someone summarize why those alternatives were deemed "more
> viable"?
>
>> btw. the same discussion has been done for other commons
>> components as
>> well, and the result usually was: do not add logging
>
> What was the rationale?

Look at the archives.  We have discussed this multiple times in the
past in [math] and each time came to the conclusion that Thomas
succinctly states above.  What has changed now?

Phil
>
>
> Gilles
>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy 
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up. 
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


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

Re: [Math] Utilitzation of SLF4J?

On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:

Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of
logging

facility to CM.
If the outcome is positive, there are a handful of alternatives, some
of

them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).

Could someone summarize why those alternatives were deemed "more
viable"?

btw. the same discussion has been done for other commons components
as

well, and the result usually was: do not add logging

What was the rationale?

Gilles

Thomas

On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy
wrote:

Hello,

We have been discussing various ways to view what's happening
internally
with algorithms, and the topic of including SLF4J has come up. I
know that

this was discussed earlier and it was decided that CM is a low level
dependency, therefore it should minimize the transitive dependencies
that
it introduces. The Java community has adopted many means of dealing
with

potential logging conflicts, so I'm requesting that we use SLF4J for
logging.

I know that JBoss introduced its own logging system, and this made
me a
bit nervous about this suggestion, so I looked up strategies for
switching

their logger out with SLF4J:

http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many dependencies
that
might use commons-logging instead of SLF4J looks something like
this:

http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of
dependencies. At this point the fix should be a permanent. If
someone has
has a very intricate scenario that we have not yet seen, they could
use

(And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole

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

Re: [Math] Utilitzation of SLF4J?

Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of logging
facility to CM.
If the outcome is positive, there are a handful of alternatives, some of
them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).

btw. the same discussion has been done for other commons components as
well, and the result usually was: do not add logging

Thomas


On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy  wrote:

> Hello,
>
> We have been discussing various ways to view what's happening internally
> with algorithms, and the topic of including SLF4J has come up.  I know that
> this was discussed earlier and it was decided that CM is a low level
> dependency, therefore it should minimize the transitive dependencies that
> it introduces.  The Java community has adopted many means of dealing with
> potential logging conflicts, so I'm requesting that we use SLF4J for
> logging.
>
> I know that JBoss introduced its own logging system, and this made me a
> bit nervous about this suggestion, so I looked up strategies for switching
> their logger out with SLF4J:
>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>
> The general process I go through when working with many dependencies that
> might use commons-logging instead of SLF4J looks something like this:
>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>
> With JDK9 individual modules can define their own isolated set of
> dependencies.  At this point the fix should be a permanent.  If someone has
> has a very intricate scenario that we have not yet seen, they could use
> (And probably should use) OSGi to isolate dependencies.
>
> WDYT?
>
> Cheers,
> - Ole
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Utilization of Lombok

Hi Ole,

can you explain why you think that the addition of lombok brings any
benefit to our users?

>From my point of view, lombok can help developers by taking over some
tedious tasks, but this is quite irrelevant in the case of CM as the
majority of work goes into algorithm design and verification rather than in
writing getters/setters (which btw has pretty good IDE support). So this
would just add additional complexity and the gain is very unclear.

Thomas


On Fri, Sep 25, 2015 at 3:31 PM, Ole Ersoy  wrote:

> Hello,
>
> I'm going to utilize Lombok in a CM design experiment.  Once the
> experiment is done CM can decide if it likes Lombok.  I know that CM tries
> to stay dependency free, so I just want to make clear that Lombok is
> compile time only:
> http://stackoverflow.com/questions/6107197/how-does-lombok-work
>
> Lombok eliminates the need to code boilerplate plate code, like getters,
> setters, toString().  It can also generate a fluid builder for
> configuration objects, check for null arguments, etc.  It also has an
> @Synchronized annotation that is an improvement on the synchronized keyword.
>
> Lombok alters the byte code, keeping the source code clean and minimal.
> The additional generated code and be seen using an Eclipse plugin.  So for
> example when looking at the outline view, you can see the generated
> getters, etc.
>
>
> https://standardofnorms.wordpress.com/2013/05/10/reducing-java-boilerplate-code-with-lombok-with-eclipse-installation/
>
> Cheers,
> - Ole
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Math] Utilization of Lombok


Hello,

I'm going to utilize Lombok in a CM design experiment.  Once the experiment is 
done CM can decide if it likes Lombok.  I know that CM tries to stay dependency 
free, so I just want to make clear that Lombok is compile time only:
http://stackoverflow.com/questions/6107197/how-does-lombok-work

Lombok eliminates the need to code boilerplate plate code, like getters, 
setters, toString().  It can also generate a fluid builder for configuration 
objects, check for null arguments, etc.  It also has an @Synchronized 
annotation that is an improvement on the synchronized keyword.

Lombok alters the byte code, keeping the source code clean and minimal.  The 
additional generated code and be seen using an Eclipse plugin.  So for example 
when looking at the outline view, you can see the generated getters, etc.

https://standardofnorms.wordpress.com/2013/05/10/reducing-java-boilerplate-code-with-lombok-with-eclipse-installation/

Cheers,
- Ole


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

Re: [Math] LeastSquaresOptimizer Design


On Thu, 24 Sep 2015 22:07:58 -0500, Ole Ersoy wrote:

Why should the instance throwing the exception hold a field with the
information?
Separation of concerns: optimizer does the computation,
then the exception holds what's needed for a full report of the 
failure.

I would see what makes sense on on case by case basis.  For example
if the Observer, which is implemented by the client / person using 
CM,

realizes that it can't continue it can throw an application specific
exception using a set of Enums that are coded for the application.

if ( optimizer.yourNeverGonnaGetItEver() ) {

   throw new
ApplicationSpecificException(ApplicationErrorCodes.PARTYS_OVER,
optimizer);
}

The error code should be specific enough for the application to
understand the the optimizer argument is the optimizer (Object type),
and then it can construct the message from there.


IMO, we shouldn't force the optimizer instance to hold fields just for
the sake of reporting (the optimizer could make a "CurrentStateReport"
instances on the fly to be passed to the observer at every iteration).

Unless I'm missing something, I don't see the benefit of passing the
optimizer.
All arguments used to instantiate the optimizer must be known already
at the caller's level.  The "CurrentStateReport" should only contain
computed values that would allow the caller to decide whether to stop
or continue. In the former case, the caller would be responsible to
merge the initial arguments list and computed values in order to
proceed (e.g. instantiate a new optimizer with the current best model
parameters as initial values).



Or the report is done at the observer's level, based on complete
information routinely returned by the optimizer at every step (cf.
previous mail).

I would stick with the same process in this case.


?

Regards,
Gilles



Cheers,
- Ole



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

[Math] Utilitzation of SLF4J?


Hello,

We have been discussing various ways to view what's happening internally with 
algorithms, and the topic of including SLF4J has come up.  I know that this was 
discussed earlier and it was decided that CM is a low level dependency, 
therefore it should minimize the transitive dependencies that it introduces.  
The Java community has adopted many means of dealing with potential logging 
conflicts, so I'm requesting that we use SLF4J for logging.

I know that JBoss introduced its own logging system, and this made me a bit 
nervous about this suggestion, so I looked up strategies for switching their 
logger out with SLF4J:
http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many dependencies that might 
use commons-logging instead of SLF4J looks something like this:
http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of dependencies. 
 At this point the fix should be a permanent.  If someone has has a very 
intricate scenario that we have not yet seen, they could use (And probably 
should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole


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

Re: [Math] LeastSquaresOptimizer Design