Re: [all] apologies

[Thomas Neidhart]

On Mon, Feb 8, 2016 at 9:13 PM, Phil Steitz  wrote:

> I am sorry for the bad tone of my recent posts here.  Not the nicest
> way to leave and I am sorry for that.
>

Hi Phil,

nothing that you have written is worth an apology, although I can
understand your disappointment about the way (or motive) you are leaving.

In fact, as Niall pointed out, we as community have failed as we have
accepted unhealthy behavior for too long a time resulting in people just
being frustrated up to the point where they break and leave.
Sometimes it does not take a flame war but this constant little nagging
about every little thing to make people feel uncomfortable and dissapointed.

For me you have been a role model how to handle conflicts and it makes me
really sad to see to leave because of one.

Thomas

Re: [dbcp] digging for deps

[sebb]

I would find it annoying if the bin zip included dependencies that I
already have, and don't need to download again.
Or the bin zip was created a while ago and I already have more recent
versions of some of the dependencies, so I have to tidy up the
download.

We should only provide a compiled version of the released source in
the standard binary archives.

However, if there were a separate zip with all the dependencies
(assuming they can be distributed by the ASF) that would be OK by me,
so long as it was clear what the bundle contained.

On 9 February 2016 at 04:14, Gary Gregory  wrote:
> Hi All:
>
> Am I the only one who finds that the fact that the bin zip does not include
> all the jars you need annoying as heck?
>
> Gary
>
> --
> 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

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

Re: [Math] Counters in "LeastSquaresProblem" (Was: [...] ConvergenceChecker)

[sebb]

On 8 February 2016 at 23:11, Gilles  wrote:
> Hi.
>
> On Mon, 8 Feb 2016 15:18:37 -0600, Ole Ersoy wrote:
>>
>> [...]
>>
 Also could you please look at this:

  public static LeastSquaresProblem countEvaluations(final
 LeastSquaresProblem problem,
 final
 Incrementor counter) {
  return new LeastSquaresAdapter(problem) {

  /** {@inheritDoc} */
  @Override
  public Evaluation evaluate(final RealVector point) {
  counter.incrementCount();
  return super.evaluate(point);
  }

  // Delegate the rest.
  };
  }

 Should this exist?
>>>
>>> Looks useful for counting evaluations, but I think all of the LS
>>> optimizers already do this. Anyone have a use case for countEvaluations?
>>
>> I think you are right.  I think it's code that was accidentally left
>> in...Anyone...?
>
>
> No it was not accidentally left in, it was added on purpose with the
> new design.
> Now, I seem to recall that it was an example of how information could
> be passed from the optimization algorithm to the user, by wrapping the
> "basic" context ("LeastSquaresProblem") within an extended one (here an
> evaluation counter context).
>
> The "maxEvaluations" and "maxEvaluations" settings are currently passed
> at construction of the "LocalLeastSquaresProblem"; maybe it is that which
> was supposed to go in the new design: "LevenbergMarquardtOptimizer"
> increments the counters but otherwise does not use them (for loop
> control, that is).
>
> Was it something that waited for the refactoring of the rest of the
> optimizers?  Indeed, the "LeastSquareProblem interface" extends
> "OptimizationProblem" that defines "getEvaluationCounter()",
> "getIterationCounter()" and ... "getConvergenceChecker()".
>
> So the wrapper/adapter provides external control of what happens (e.g.
> raising an exception) when the counter is exhausted.
> IOW, the counter(s) are not part of the standard algorithm, and the
> new design is able to make that clear.

However clearly the purpose of the method(s) is not immediately
obvious from the source code.
Perhaps it was in the commit message or mailing list discussions?
Such external documentation is rarely sufficient, so if would be very
helpful if the code could be updated with the rationale as explained
above.

>
> Regards,
> Gilles
>
>> 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