Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
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.5)/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
On 8/15/05, J.Pietschmann [EMAIL PROTECTED] 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.5)/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
On 8/13/05, J.Pietschmann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
