On Sat, 20 Jul 2013 16:41:00 -0700, Ajo Fod wrote:
Ok let's approach this one step at a time starting with improper
integration because tests for AQ depend on it.
What are the modifications to the class Infinite in Math-995 that
are:
1: necessary
2: desirable
for acceptance to commons?
what b
Ok let's approach this one step at a time starting with improper
integration because tests for AQ depend on it.
What are the modifications to the class Infinite in Math-995 that are:
1: necessary
2: desirable
for acceptance to commons?
what bits of code can be reused from existing ones in commons
On Sat, 20 Jul 2013 06:45:10 -0700, Ajo Fod wrote:
[...]
If you want to pose what I and the community see as a respectable
objection
to including a commit, it needs to be in the form of :
1. alternative code that demonstrates a superior way of doing
improper
integration. With unit tests that
Without AQ, you have the achilles heel with high frequency functions that
Gilles acknowledged in his comments. So, how do you propose to do AQ with
Gauss-Hermite?
I guess I don't know what you mean by "numerical analysis".
Cheers,
Ajo.
On Sat, Jul 20, 2013 at 9:38 AM, Phil Steitz wrote:
>
On 7/20/13 8:54 AM, Ajo Fod wrote:
> 1. Konstantin just showed with a link that other packages use the change of
> variables method.
>
> 2 The theoretical argument for the change of variables method is documented
> on Wikipedia. It is such a standard way that it is on wikipedia. I did
> another sea
1. Konstantin just showed with a link that other packages use the change of
variables method.
2 The theoretical argument for the change of variables method is documented
on Wikipedia. It is such a standard way that it is on wikipedia. I did
another search on google. Here is another wikipedia link:
> his code, so I can't comment about it specifically.
>>
>
> There was no outright rejection.
>
... only painful fillibustering with objections that were tangential to the
CM user experience.
>
> My strong impression is that the source of the problem is the
> misconception that Commons Math is r
On 7/20/13 6:45 AM, Ajo Fod wrote:
> Phil,
>
> I feel that you are blocking/delaying the use of improper integration to
> commons users with your objection that you don't understand all the
> alternatives.
>
> If you want to pose what I and the community see as a respectable objection
> to includin
Phil,
I feel that you are blocking/delaying the use of improper integration to
commons users with your objection that you don't understand all the
alternatives.
If you want to pose what I and the community see as a respectable objection
to including a commit, it needs to be in the form of :
1. al
Hello Jared.
I have only contributed a few patches, and I see that there is
argument about whether this thread should even be about anything
other
than technical issues, but I figured I would at least chime in.
I found the submission process to be more difficult than I expected,
but I also th
On 7/19/13 2:36 PM, Konstantin Berlin wrote:
> The question is how correctly to do AQ and how to correctly handle
>
>> improper integrals. What I would appreciate is some real numerical
>> analysis or pointers to where we can do the research to support what
>> Ajo is asking us to commit. Just run
The question is how correctly to do AQ and how to correctly handle
> improper integrals. What I would appreciate is some real numerical
> analysis or pointers to where we can do the research to support what
> Ajo is asking us to commit. Just running tests on one problem
> instance demonstrates n
>From: Ted Dunning [mailto:ted.dunn...@gmail.com]
>Sent: Friday, July 19, 2013 2:21 PM
>To: Commons Developers List
>Subject: Re: [Math] Cleaning up the curve fitters. .
>The discussion about how to get something into commons when it is (a) well
>documented and (b) demonst
On 7/19/13 12:38 PM, Ted Dunning wrote:
> On Fri, Jul 19, 2013 at 12:27 PM, Phil Steitz wrote:
>
>>> It still seems to me that it would serve CM well to pay more attention to
>>> Ajo's comments and suggestions. Simply saying that we should focus on
>>> technical discussion when CM's list is fille
On Fri, Jul 19, 2013 at 12:27 PM, Phil Steitz wrote:
> > It still seems to me that it would serve CM well to pay more attention to
> > Ajo's comments and suggestions. Simply saying that we should focus on
> > technical discussion when CM's list is filled with esthetic arguments
> > really just s
he API, then by all means edit
>> the
>>>>> patch, but if you go about rejecting things that work, there won't be
>> as
>>>>> many contributors to CM.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
n outsider listening to these discussions, it seems like:
> >>>> a) *IF* there are problems with the current arrangement of packages,
> >> APIs,
> >>>> or whatever, then a constructive approach would be for the one who
> sees
> >>>> such problem
ch with these changes, along with quantitative
>>>> justification, benchmarks, test cases, etc. It is quite easy to
>> criticize,
>>>> from the sidelines, the one who is actually doing the work, but quite
>>>> another matter to roll up your sleeves and join in t
correctly implementing the algorithm. Maybe the
> >> algorithm is simply not the right one to use for the problem.
> >> c) Comments that imply (or state outright) that someone who has
> (clearly)
> >> done a lot of work has done it "...without much thinking..." a
On 07/18/2013 10:48 PM, Ajo Fod wrote:
> Hello folks,
>
> There is a lot of work in API design. However, Konstantin's point is that
> it takes a lot of effort to convince Gilles of any alternatives. API design
> issues should really be second to functionality. This idea seems to be lost
> in conve
ents that imply (or state outright) that someone who has (clearly)
>> done a lot of work has done it "...without much thinking..." are clearly
>> out of line. In my experience, the only reason to resort to name calling
>> and character assassination is because one has no
worthy arguments to put
> forward.
> d) Kudos to the Commons committers who have been doing the work ...
>
> My 2 cents...
>
> ~Roger Whitcomb
> Apache Pivot PMC Chair
>
> -Original Message-----
> From: Gilles [mailto:gil...@harfang.homelinux.org]
> Sent: Thursda
ger Whitcomb
Apache Pivot PMC Chair
-Original Message-
From: Gilles [mailto:gil...@harfang.homelinux.org]
Sent: Thursday, July 18, 2013 9:35 AM
To: dev@commons.apache.org
Subject: Re: [Math] Cleaning up the curve fitters
On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> I apprec
On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
I appreciate the comment. I would like to help, but currently my
schedule is full. Maybe towards the end of the year.
I think the first approach should be do no harm. The optimization
package keeps getting refactored every few months w
My vote was not directed toward the technical merits of the optimization
package. I am not an expert on optimization and I trust you in this regard.
My vote was a comment on the usability of the API. I find it to be
increasing difficult to use.
Maybe I have missed some refactoring, but why all
I appreciate the comment. I would like to help, but currently my schedule is
full. Maybe towards the end of the year.
I think the first approach should be do no harm. The optimization package keeps
getting refactored every few months without much thinking involved. We had the
discuss previously
You have done a pretty good job in making the optimization package
non-sensical to user.
+1
Check your facts ("svn log", JIRA, this ML), please: All modifications
were done in plain sight, and responded to identified problems which
I cared to solve.
I do not deny that it could have raised iss
On 7/18/13 7:12 AM, Patrick Meyer wrote:
>> You have done a pretty good job in making the optimization package
> non-sensical to user.
>
> +1
We have definitely struggled with the design of the optimization
package. It would be great if we could get to a stable API for 4.0
onwards. If you guys a
>You have done a pretty good job in making the optimization package
non-sensical to user.
+1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi,
Bringing up points with you never leads anywhere since you refuse accept that
your proposal might have issues, and as a last result you always bring out the
"Examples Benchmarks" red herring, since it has nothing to do with the logical
problems of your proposal. Since you work on commons pr
On Thu, 18 Jul 2013 09:16:46 -0400, Konstantin Berlin wrote:
Hi,
I have two points on this
1) See issue MATH-1009
This is not directly related to my question (about cleanup of
_existing_ code); it should thus be discussed in another thread.
2) If LM was always better there would be no Guass
Hi,
I have two points on this
1) See issue MATH-1009
2) If LM was always better there would be no GuassNewton. Clearly this is not
the case.
LM is a mixture between GN and steepest descent, so it is only faster for
"tougher" functions. In case of strictly convex function GN should be a good
am
Hi,
Am I missing something? Why is a linear least squares problem (fitting
constants of basis functions) being solved using a non-linear least squares
solver in the first place?
On Jul 17, 2013, at 11:16 AM, Gilles wrote:
> Hello.
>
> Constructors of classes in the "o.a.c.m.fitting" are inst
33 matches
Mail list logo
