On 08/27/2013 12:35 PM, Konstantin Berlin wrote:
> Sorry, I think there was a misunderstanding. I was suggesting, like
> you are pointing out, that you make a newton step function explicit
> inside the optimizer. I think it is a good idea that this function is
> explicit in all optimizers, so it c
Sorry, I think there was a misunderstanding. I was suggesting, like
you are pointing out, that you make a newton step function explicit
inside the optimizer. I think it is a good idea that this function is
explicit in all optimizers, so it can later be overwritten.At the
least, it should be propaga
On 08/27/2013 08:44 AM, Evan Ward wrote:
> On 08/27/2013 07:27 AM, Gilles wrote:
>> Hi.
>>
>> Sorry but the _main_ question of my previous post was...
>>
>> On Mon, 26 Aug 2013 16:35:51 -0400, Evan Ward wrote:
>>> On 08/26/2013 03:33 PM, Gilles wrote:
On Mon, 26 Aug 2013 13:59:32 -0400, Evan
On 08/26/2013 03:11 PM, Konstantin Berlin wrote:
> I looked only at the GuassNewton class as a general guide to how
> things work. I like it a lot! I only wish all of the optimizations
> were rewritten in this way.
>
> Several comments
>
> 1) I believe this code can now be simplified
>
> // build
On 08/27/2013 07:27 AM, Gilles wrote:
> Hi.
>
> Sorry but the _main_ question of my previous post was...
>
> On Mon, 26 Aug 2013 16:35:51 -0400, Evan Ward wrote:
>> On 08/26/2013 03:33 PM, Gilles wrote:
>>> On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
Hi again,
I rearranged
Hi.
Sorry but the _main_ question of my previous post was...
On Mon, 26 Aug 2013 16:35:51 -0400, Evan Ward wrote:
On 08/26/2013 03:33 PM, Gilles wrote:
On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
Hi again,
I rearranged the least squares package and I've posted the
results.[1]
I've
In regards to your first comments. I do not understand your point. You
are implementing large API changes, but refuse to take the final step
that would tie everything together and make it robust for future
changes.
In regards to second comments, you can make it whatever interface
hierarchy that yo
On 08/26/2013 03:33 PM, Gilles wrote:
> On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
>> Hi again,
>>
>> I rearranged the least squares package and I've posted the results.[1]
>> I've also created a pull request[2] and an associated issue.[3]
>>
>> [1] https://github.com/wardev/commons-math
On Mon, 26 Aug 2013 15:11:22 -0400, Konstantin Berlin wrote:
I looked only at the GuassNewton class as a general guide to how
things work. I like it a lot! I only wish all of the optimizations
were rewritten in this way.
Several comments
1) I believe this code can now be simplified
// build th
On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
Hi again,
I rearranged the least squares package and I've posted the
results.[1]
I've also created a pull request[2] and an associated issue.[3]
[1] https://github.com/wardev/commons-math/tree/sepOpt
[2] https://github.com/apache/commons-ma
I looked only at the GuassNewton class as a general guide to how
things work. I like it a lot! I only wish all of the optimizations
were rewritten in this way.
Several comments
1) I believe this code can now be simplified
// build the linear problem
final double[] b = new double[nC];
Hi again,
I rearranged the least squares package and I've posted the results.[1]
I've also created a pull request[2] and an associated issue.[3]
[1] https://github.com/wardev/commons-math/tree/sepOpt
[2] https://github.com/apache/commons-math/pull/1
[3] https://issues.apache.org/jira/browse/MATH-
On Tue, 20 Aug 2013 10:38:02 -0400, Konstantin Berlin wrote:
We already discussed that some time ago.
Let's not mix different issues. Removing the handling of weights can
dealt
with later.
I disagree, please address my points in regards to this, rather than
saying a generalizing statement.
On Tue, Aug 20, 2013 at 8:54 AM, Evan Ward wrote:
> Hi all,
>
> Sorry for the delay. I'll try switching all of the least squares package
> to the new/seperable API and post the results to github. From there we
> can review, discuss and then decide if it makes sense to switch the rest
> of the opti
> We already discussed that some time ago.
> Let's not mix different issues. Removing the handling of weights can dealt
> with later.
>
>
I disagree, please address my points in regards to this, rather than
saying a generalizing statement.
Having weights be included makes it harder to implement a
On Tue, 20 Aug 2013 08:54:59 -0400, Evan Ward wrote:
Hi all,
Sorry for the delay. I'll try switching all of the least squares
package
to the new/seperable API and post the results to github. From there
we
can review, discuss and then decide if it makes sense to switch the
rest
of the optimiz
Hi all,
Sorry for the delay. I'll try switching all of the least squares package
to the new/seperable API and post the results to github. From there we
can review, discuss and then decide if it makes sense to switch the rest
of the optimizers.
On 08/15/2013 09:12 AM, Konstantin Berlin wrote:
> H
I like the immutability idea. I wonder if there are any guidelines on when
the performance hit because of immutability is high enough to want mutable
objects and synchronization?
-Ajo
On Thu, Aug 15, 2013 at 10:27 AM, Gilles wrote:
> On Thu, 15 Aug 2013 11:07:20 -0500, Phil Steitz wrote:
>
>> O
On Thu, 15 Aug 2013 11:07:20 -0500, Phil Steitz wrote:
On Aug 15, 2013, at 7:31 AM, Gilles
wrote:
On Wed, 14 Aug 2013 23:40:58 +0100, sebb wrote:
On 14 August 2013 23:34, Gilles
wrote:
At this point, I'd tend to think that creating a copy of trunk in
the
Commons's "sandbox" part of the r
On Aug 15, 2013, at 7:31 AM, Gilles wrote:
> On Wed, 14 Aug 2013 23:40:58 +0100, sebb wrote:
>> On 14 August 2013 23:34, Gilles wrote:
>>>
>>> At this point, I'd tend to think that creating a copy of trunk in the
>>> Commons's "sandbox" part of the repository will be more productive.
>>
>> W
Hi,
As a quick first pass, I will comment on Evans code only for now. Most
of my comments have to do with numerical aspects and associated
design, rather than threading.
I like the idea of the optimize function taking in a Problem class. I
think it can add a lot of flexibility going forward.
Fir
On Wed, 14 Aug 2013 23:40:58 +0100, sebb wrote:
On 14 August 2013 23:34, Gilles wrote:
At this point, I'd tend to think that creating a copy of trunk in
the
Commons's "sandbox" part of the repository will be more productive.
Why sandbox? Just use a temporary branch in the existing math rep
On 14 August 2013 23:34, Gilles wrote:
>
> At this point, I'd tend to think that creating a copy of trunk in the
> Commons's "sandbox" part of the repository will be more productive.
Why sandbox? Just use a temporary branch in the existing math repo.
> There, we can both directly modify the code
Hi.
> [...]
Since the iteration counter was incremented explicitly I thought it
made
sense to increment the evaluation counter explicitly.
It's indeed cleaner to have the two counters handled in a similar
fashion. Actually, the iteration counter was an afterthought: Driven
by my current usa
Hi,
On 08/14/2013 12:23 PM, Konstantin Berlin wrote:
> Since I have no idea what you guys are describing, could you guys please
> do something like this? Or at least put rough outlines of the interfaces
> and classes somewhere, so other people can evaluate?
The *rough* interfaces and classes of m
On 08/14/2013 11:30 AM, Gilles wrote:
> On Tue, 13 Aug 2013 17:47:18 -0400, Evan Ward wrote:
>> On 08/13/2013 08:17 AM, Gilles wrote:
(I.e. GN would
not need 5 superclasses and fields for storing upper and lower
bounds.)
>>>
>>> Be careful: "GaussNewtonOptimizer" does _not_ support
Could we create an "o.a.c.m.experimental" sub-package, and put
> "competing" designs inside it: e.g.
> o.a.c.m.experimental.evan
> o.a.c.m.experimental.gilles
> for people to test with 3.3, and postpone a decision until we can see
> better the differences? Maybe this would allow to pick all the
On Tue, 13 Aug 2013 17:47:18 -0400, Evan Ward wrote:
On 08/13/2013 08:17 AM, Gilles wrote:
(I.e. GN would
not need 5 superclasses and fields for storing upper and lower
bounds.)
Be careful: "GaussNewtonOptimizer" does _not_ support bounds!
That is my point! Because of it's complex inheritan
Hello.
[...]
Looking on the web about fluent API, most design/usage/examples do
not
provide immutability: the primary purpose of "fluent" is to chain
on-the-fly modifications of an object's properties. [This is the
complete
opposite of immutability!]
Well, as the fluent API return an ob
On 08/13/2013 08:17 AM, Gilles wrote:
>> (I.e. GN would
>> not need 5 superclasses and fields for storing upper and lower bounds.)
>
> Be careful: "GaussNewtonOptimizer" does _not_ support bounds!
That is my point! Because of it's complex inheritance every instance
includes fields for storing bou
Hi Gilles,
Le 13/08/2013 18:46, Gilles a écrit :
> Hello Luc.
>
>> Hi Gilles,
>>
>>>
> [...]
[...]
Historically, we did not care about thread-safety at all
in [math], assuming the standard use case was *always* going to be
one instance per thread. The statistics agg
Hello Luc.
Hi Gilles,
> [...]
[...]
Historically, we did not care about thread-safety at all
in [math], assuming the standard use case was *always* going to be
one instance per thread. The statistics aggregators are an example
where multithreaded access makes sense, but this is much more t
Le 13/08/2013 13:50, Gilles a écrit :
> Hi.
Hi Gilles,
>
>> > [...]
>> [...]
>>
>> Historically, we did not care about thread-safety at all
>> in [math], assuming the standard use case was *always* going to be
>> one instance per thread. The statistics aggregators are an example
>> where multit
[...] I have class that has to solve different NLLS problems
concurrently. The problems share the same convergence criteria, but
use
different model functions. With the current implementation that
means I
need one optimizer per thread.
How bad is that, actually? That is what I am not getting.
Hi.
> [...]
[...]
Historically, we did not care about thread-safety at all
in [math], assuming the standard use case was *always* going to be
one instance per thread. The statistics aggregators are an example
where multithreaded access makes sense, but this is much more the
exception than the
On 8/12/13 10:55 AM, Evan Ward wrote:
> On 08/12/2013 12:19 PM, Phil Steitz wrote:
>> On 8/12/13 9:04 AM, Evan Ward wrote:
>>> On 08/09/2013 06:55 PM, Gilles wrote:
>> [...]
>>
>>> This does make it important to decide on a well written and
>>> complete API before releasing it.
On 08/12/2013 12:19 PM, Phil Steitz wrote:
> On 8/12/13 9:04 AM, Evan Ward wrote:
>> On 08/09/2013 06:55 PM, Gilles wrote:
> [...]
>
>> This does make it important to decide on a well written and
>> complete API before releasing it.
> When the scope of the software is well circ
On 8/12/13 9:04 AM, Evan Ward wrote:
>
> On 08/09/2013 06:55 PM, Gilles wrote:
[...]
> This does make it important to decide on a well written and
> complete API before releasing it.
When the scope of the software is well circumscribed, that would be
possible. With the w
On 08/09/2013 06:55 PM, Gilles wrote:
>>> [...]
>>>
This does make it important to decide on a well written and
complete API before releasing it.
>>>
>>> When the scope of the software is well circumscribed, that would be
>>> possible. With the whole of [Math]ematics, much less so. :-}
On 8/8/13 10:56 AM, Evan Ward wrote:
> Gilles wrote:
>>> To address a few concerns I saw,
>>>
>>> Gilles wrote:
In this way, it does not; what I inferred from the partial code
above was
that there would only be _one_ "create" method. But:
1. All "create" methods must be overridd
[...]
This does make it important to decide on a well written and
complete API before releasing it.
When the scope of the software is well circumscribed, that would be
possible. With the whole of [Math]ematics, much less so. :-}
And state-of-the-art in Java is a moving target, aimed at by
cha
Gilles wrote:
>> To address a few concerns I saw,
>>
>> Gilles wrote:
>>> In this way, it does not; what I inferred from the partial code
>>> above was
>>> that there would only be _one_ "create" method. But:
>>> 1. All "create" methods must be overridden at the next level of the
>>> class
>>> hie
Hello.
Sorry for the confusion my code sample caused; it made sense in my
mind.
:) I was speaking from the perspective that an abstract class is a
skeletal implementation of an interface, created so that implementing
the interface is easier. For the non-linear least squares (NLLS)
package
I
Hi again,
Sorry for the confusion my code sample caused; it made sense in my mind.
:) I was speaking from the perspective that an abstract class is a
skeletal implementation of an interface, created so that implementing
the interface is easier. For the non-linear least squares (NLLS) package
I was
Hi.
On Thu, 08 Aug 2013 10:03:36 +0200, Luc Maisonobe wrote:
Le 08/08/2013 01:13, Gilles a écrit :
On Wed, 7 Aug 2013 18:04:39 -0400, Evan Ward wrote:
Hi,
As a grateful user of the library, I would prefer the Fluent API
and
immutability. I have implemented this pattern in some of my own
pro
Le 08/08/2013 01:13, Gilles a écrit :
> On Wed, 7 Aug 2013 18:04:39 -0400, Evan Ward wrote:
>> Hi,
>>
>> As a grateful user of the library, I would prefer the Fluent API and
>> immutability. I have implemented this pattern in some of my own projects
>> and it makes the API very easy to use.
>>
>> M
On Wed, 7 Aug 2013 18:04:39 -0400, Evan Ward wrote:
Hi,
As a grateful user of the library, I would prefer the Fluent API and
immutability. I have implemented this pattern in some of my own
projects
and it makes the API very easy to use.
Most of the time, when the interface is small, inheritan
On Wed, 7 Aug 2013 13:39:41 -0700, Ted Dunning wrote:
This is often dealt with by using builder classes and not putting all
the
fluent methods on the objects being constructed.
Builders seem fine when no inheritance is involved: all fields are
duplicated (and mutable) in the builder, then an i
Hi,
As a grateful user of the library, I would prefer the Fluent API and
immutability. I have implemented this pattern in some of my own projects
and it makes the API very easy to use.
Most of the time, when the interface is small, inheritance isn't really
necessary and I just implement the withX
This is often dealt with by using builder classes and not putting all the
fluent methods on the objects being constructed.
The other way to deal with this is to use a covariant return type. For
instance, there is no guarantee that Pattern.compile returns any particular
class other than that it re
Hi.
It seems that each two of those concepts are at odds with
the third one.
E.g. you can have a fluent API and immutability, but this
then prevents you from defining fluent API methods in a base
class because immutability requires creating a new object
(but the base class cannot know how to "bu
51 matches
Mail list logo
