Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003 20:14:23 +0200, "J.Pietschmann" wrote:
Brent Worden wrote:
I agree. The this looks like a very solid framework. One
suggestion I
would like to make, is instead of a both a firstDirevative and
secondDerivate method to evaluate the
[EMAIL PROTECTED] wrote:
Just because we the creators of the framework see no need for higher
order derivates, the end users, whose needs no one can fully
enumerate, may have a quite reasonable use for them.
Well, I designed the interface as a helper for a variety of
numerical algorithms, not for g
--- [EMAIL PROTECTED] wrote:
> On Fri, 30 May 2003 20:14:23 +0200, "J.Pietschmann" wrote:
> > Brent Worden wrote:
> > > I agree. The this looks like a very solid framework. One
> > suggestion I
> > > would like to make, is instead of a both a firstDirevative and
> > > secondDerivate method to eva
Brent Worden wrote:
I agree. The this looks like a very solid framework. One suggestion I
would like to make, is instead of a both a firstDirevative and
secondDerivate method to evaluate the derivates. Create a single
getDerivate() method that returns a UnivariateRealFunction. That way if a
use
Brent Worden wrote:
"J.Pietschmann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Phil Steitz wrote:
Can you provide a math reference desribing this?
H.M.Antia: Num. Methods for Scientists and Engineers.
I have been referring
to Atkinson and I am having a hard time following the im
In general, code will be applied if it is submitted as a patch and we
can all agree on an approach. Sending a tarball to the list with some
proposed code is not helpful - I'm not scolding anyone for doing that, I
just want to make it clear that patches are always preferred.
Also, just a reminder
> Brent,
>
> I think I have a few improvements that came to mind while I was coding a
> Ridders' method implementation. Should I send you a diff file privately?
>
>
> Al
>
> =
> Albert Davidson Chou
Al,
Sorry I didn't get back to you. I got bogged down doing other things. I
would agree wit
"J.Pietschmann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Phil Steitz wrote:
> > Can you provide a math reference desribing this?
>
> H.M.Antia: Num. Methods for Scientists and Engineers.
>
> > I have been referring
> > to Atkinson and I am having a hard time following the imp
Phil Steitz wrote:
Can you provide a math reference desribing this?
H.M.Antia: Num. Methods for Scientists and Engineers.
I have been referring
to Atkinson and I am having a hard time following the implementation.
What exactly do you mean by "only inverse quadratic interpolation"?
Brent's metho
Al Chou wrote:
--- "Shapira, Yoav" <[EMAIL PROTECTED]> wrote:
Howdy,
4. Thinking of the developers who will use this stuff, I feel like we
need a way to insulate them from having to think about rootfinding
strategy choice. As Al has pointed out, we are not (at least yet ;-))
in the AI business,
--- "Shapira, Yoav" <[EMAIL PROTECTED]> wrote:
> Howdy,
>
> >4. Thinking of the developers who will use this stuff, I feel like we
> >need a way to insulate them from having to think about rootfinding
> >strategy choice. As Al has pointed out, we are not (at least yet ;-))
> >in the AI business,
Howdy,
>4. Thinking of the developers who will use this stuff, I feel like we
>need a way to insulate them from having to think about rootfinding
>strategy choice. As Al has pointed out, we are not (at least yet ;-))
>in the AI business, so we can't automagically make the best choice for
>them;
J.Pietschmann wrote:
Brent Worden wrote:
In the chi-square patch, I created a root finding utility class. I
used the
bisection method to provide a default mechanism for computing inverse
CDFs.
It's driven by a simple Function interface. Check it out and see if it's
something you can use or imp
Brent Worden wrote:
In the chi-square patch, I created a root finding utility class. I used the
bisection method to provide a default mechanism for computing inverse CDFs.
It's driven by a simple Function interface. Check it out and see if it's
something you can use or improve.
Here's my take on
--- Brent Worden <[EMAIL PROTECTED]> wrote:
> > and unit tests. While things like rootfinding for
> > non-differentiable functions
> > may eventually have a place and may benefit from algorithms that
> > someone can
> > claim copyright ownership of, if no one else does it before I get
> > to it, I
Brent Worden wrote:
and unit tests. While things like rootfinding for
non-differentiable functions
may eventually have a place and may benefit from algorithms that
someone can
claim copyright ownership of, if no one else does it before I get
to it, I will
translate my simple newton's method implem
> and unit tests. While things like rootfinding for
> non-differentiable functions
> may eventually have a place and may benefit from algorithms that
> someone can
> claim copyright ownership of, if no one else does it before I get
> to it, I will
> translate my simple newton's method implementati
Tim O'Brien wrote:
On Tue, 2003-05-27 at 11:00, Mark R. Diggory wrote:
Basically what this is saying is "talk to us". ACM is suggesting
involvement and acknowledgment of their efforts in organizing and
archiving these algorithms..Open Source
Apache project and the legal bindings they wou
On Tue, 2003-05-27 at 11:00, Mark R. Diggory wrote:
> Basically what this is saying is "talk to us". ACM is suggesting
> involvement and acknowledgment of their efforts in organizing and
> archiving these algorithms..Open Source
> Apache project and the legal bindings they would want in such
19 matches
Mail list logo
