You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2005/08/06 20:13:56 UTC
DO NOT REPLY [Bug 36060] New: -
[math][patch] Integration Source Files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36060>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36060
Summary: [math][patch] Integration Source Files
Product: Commons
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: Math
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: zxg_32@yahoo.com
Add TrapezoidIntegrator.java
Add TrapezoidIntegratorTest.java
Update UnivariateRealIntegrator.java
Update UnivariateRealIntegratorImpl.java
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
Posted by Phil Steitz <ph...@gmail.com>.
On 8/15/05, J.Pietschmann <j3...@yahoo.de> wrote:
> Phil Steitz wrote:
> > Great!! I created a release branch for 1.1 and updated the POM in
> > trunk to 1.2, so there will be no contention with the release. I also
> > committed the sources in what I think is the latest version to trunk.
> > Pls check out and make any changes you see fit.
> >
> Now that's convenient! Thank you!
>
> BTW I'd rather created a new "Integration" or "SoC" entry in
> bugzilla and declared the existing bugs as blockers rather
> than mark them as duplicate. This way, reports from others
> could be easily tracked too without mixing them with Zhang's
> contribution. New, exiting bugzilla feature.
> (Another BTW: also a neat way to track release blocking bugs
> and feature requests).
>
> > I think one could argue for including both kinds of things, similiar
> > to other places in [math]. Provide users with the choice to select an
> > algorithm or use a default or "adaptive" selection.
>
> The problem is that making a reasonable choice about which
> algorithm to use requires months, if not years of education
> and experience. I'd say if we require this, a lot of people
> will be dissapointed. As I said, the holy grail is an algorithm
> which is consistently performance-wise within a factor of two
> (or five) of a carefully picked, perhaps customized algorithm,
> and either gives the correct answer or bails out for 99.99% of
> the cases anybody wants to throw at it. Including functions like
> 1/(x^3), x*sin(1/x) or 1E+6*exp(-((x-0.55555)/1E-6)^100).
> Unfortunately, unpleasant things like singularities in the
> integration interval are uncomfortably common in real world
> problems.
Which is precisely why we should give users a choice. As I said, I am
perfectly OK with adding an adaptive algorithm if someone is willing
to step up and code it. This is exactly the same issue that we faced
before with the solvers. Hopefully someone will step up to implenment
the factory pattern like we have for the solvers and a reasonalble
default.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source
Files
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Phil Steitz wrote:
> Great!! I created a release branch for 1.1 and updated the POM in
> trunk to 1.2, so there will be no contention with the release. I also
> committed the sources in what I think is the latest version to trunk.
> Pls check out and make any changes you see fit.
>
Now that's convenient! Thank you!
BTW I'd rather created a new "Integration" or "SoC" entry in
bugzilla and declared the existing bugs as blockers rather
than mark them as duplicate. This way, reports from others
could be easily tracked too without mixing them with Zhang's
contribution. New, exiting bugzilla feature.
(Another BTW: also a neat way to track release blocking bugs
and feature requests).
> I think one could argue for including both kinds of things, similiar
> to other places in [math]. Provide users with the choice to select an
> algorithm or use a default or "adaptive" selection.
The problem is that making a reasonable choice about which
algorithm to use requires months, if not years of education
and experience. I'd say if we require this, a lot of people
will be dissapointed. As I said, the holy grail is an algorithm
which is consistently performance-wise within a factor of two
(or five) of a carefully picked, perhaps customized algorithm,
and either gives the correct answer or bails out for 99.99% of
the cases anybody wants to throw at it. Including functions like
1/(x^3), x*sin(1/x) or 1E+6*exp(-((x-0.55555)/1E-6)^100).
Unfortunately, unpleasant things like singularities in the
integration interval are uncomfortably common in real world
problems.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
Posted by Phil Steitz <ph...@gmail.com>.
On 8/13/05, J.Pietschmann <j3...@yahoo.de> wrote:
> bugzilla@apache.org wrote:
> > Add TrapezoidIntegrator.java
> > Add TrapezoidIntegratorTest.java
> > Update UnivariateRealIntegrator.java
> > Update UnivariateRealIntegratorImpl.java
>
> Ok, I had a look at the files. It looks good, except
> that some style issues which look like being copied
> from C source should be fixed.
>
> Phil, Brent, Al: I've been inactive for a while now
> but I can take care of integgrating the integration
> files. I'll create a branch if this interferes with
> releasing 1.1
Great!! I created a release branch for 1.1 and updated the POM in
trunk to 1.2, so there will be no contention with the release. I also
committed the sources in what I think is the latest version to trunk.
Pls check out and make any changes you see fit.
>
> Zhang: you don't have to create a new bugzilla entry
> for every update, you can just create new attachments
> to an existing entry. I'd also prefer an attachment
> for each source file rather than a zip archive.
>
> All: What's the opinion about piling up implementations
> of text book integration algorithms? The holy grail is
> completely automatic intgration, so that the user doesn't
> have to know anything about the integrated function. Last
> time I checked adaptive higher order Gauss integration was
> en vogue for this purpose.
I think one could argue for including both kinds of things, similiar
to other places in [math]. Provide users with the choice to select an
algorithm or use a default or "adaptive" selection. I think the basic
interface setup that Xiaogang has is sound - though I am open to
alternatives - and we could (and should) easily add factory support.
>
> J.Pietschmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration
Source Files
Posted by "J.Pietschmann" <j3...@yahoo.de>.
bugzilla@apache.org wrote:
> Add TrapezoidIntegrator.java
> Add TrapezoidIntegratorTest.java
> Update UnivariateRealIntegrator.java
> Update UnivariateRealIntegratorImpl.java
Ok, I had a look at the files. It looks good, except
that some style issues which look like being copied
from C source should be fixed.
Phil, Brent, Al: I've been inactive for a while now
but I can take care of integgrating the integration
files. I'll create a branch if this interferes with
releasing 1.1
Zhang: you don't have to create a new bugzilla entry
for every update, you can just create new attachments
to an existing entry. I'd also prefer an attachment
for each source file rather than a zip archive.
All: What's the opinion about piling up implementations
of text book integration algorithms? The holy grail is
completely automatic intgration, so that the user doesn't
have to know anything about the integrated function. Last
time I checked adaptive higher order Gauss integration was
en vogue for this purpose.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org