[math] deprecation of DistributionFactory
I removed the use of the DistributionFactory and its dependency on commons-discovery. The approach I took was to add settable distribution fields where needed as a replacement for invoking the factory. These fields always default to our distribution implementations and can by altered via constructors as well as setters. Everything is checked in and critiques are welcome. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MATH-120) [math][patch] Pascal / Negative Binomial Distribution
[ https://issues.apache.org/jira/browse/MATH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-120. --- Resolution: Fixed - added comments about relation to negative binomail and the parameter usage and convention - add @since tags. - changed the distribution factory method to be concrete instead of abstract to preserve backwords binary compatability. - reviewed boundry cases and degen cases and they seem in order and well tested. [math][patch] Pascal / Negative Binomial Distribution - Key: MATH-120 URL: https://issues.apache.org/jira/browse/MATH-120 Project: Commons Math Issue Type: Improvement Environment: Operating System: All Platform: All Reporter: tparnell Priority: Minor Fix For: 1.2 Attachments: pascal.diff Implementation of the pascal distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[ https://issues.apache.org/jira/browse/MATH-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-153. --- Resolution: Fixed Fix Version/s: 1.2 SVN 525842: Corrected nextInt and nextLong to handle wide value ranges. RandomDataImpl nextInt(int, int) nextLong(long, long) - Key: MATH-153 URL: https://issues.apache.org/jira/browse/MATH-153 Project: Commons Math Issue Type: Bug Affects Versions: 1.1, Nightly Builds Reporter: Remi Arntzen Priority: Critical Fix For: 1.2 Attachments: diff.txt, Test.diff RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors. change return lower + (int) (rand.nextDouble() * (upper - lower + 1)); to return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1))); additional checks must be made for the nextlong(long, long) method. At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes. The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] towards a 1.2 release (was docs on doing maven2 releases)
On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Phil Steitz wrote: You were only in the Jira User group - I've added a committer role for Commons Math issues for you which should get you going for the time being as I'm not sure what groups/roles people should get - but I'll start a separate thread for that. Niall Luc In the meantime, I assigned the issue to you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-157) Add support for SVD.
[ https://issues.apache.org/jira/browse/MATH-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated MATH-157: -- Fix Version/s: 1.2 Add support for SVD. Key: MATH-157 URL: https://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Assigned To: Luc Maisonobe Fix For: 1.2 Attachments: svd.tar.gz, svd2.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-156) Brent solver is non-optimal, because it doesn't use the user's guess.
[ https://issues.apache.org/jira/browse/MATH-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated MATH-156: -- Fix Version/s: 1.2 Brent solver is non-optimal, because it doesn't use the user's guess. - Key: MATH-156 URL: https://issues.apache.org/jira/browse/MATH-156 Project: Commons Math Issue Type: Improvement Reporter: Tyler Ward Assigned To: Luc Maisonobe Fix For: 1.2 Hi guys, I noticed that your brent solver isn't using the initial guess given by the user. This can often radically improve the performance of the solver. In my tests, it improved it by roughly 30% or more, with a decent guess. Basically, we should try the guess first. If that's close enough, rreturn it. Otherwise, try one of the end points. If that's close enough, return it. Then if that brackets, go into the main loop. If that doesn't bracket, then we instead try the other endpoint. If that's close enough, return it. If that doesn't bracket, throw an exception. If it does bracket, go into the main loop with all three trial points available, allowing the quadratic interpolation to be used immediately. Worst case scenario, the initial guess doesn't bracket. In that case it is better than the default algorithm only if the user's initial guess is better than linear interpolation, which I imagine it almost always would be. If the user can't guess better than linear interpolation, presumably they wouldn't provide a guess at all, and then nothing would change. It's a small addition, less than 100 lines of code. I can't send it in due to legal at work, but from the above ideas, you should be able to put it in easily. One caveat. You may need to slightly modify the baisic solve(double, double) method to linearly interpolate a good beginning point and then break out a six double (solve(x0, y0, x1, y1, x2, y2)) method that both solve(min, max) and solve(min, max, initial) can use. If you don't do this, then solve(min, max) will bisect on its first iteration rather than intepolating, which could cost performance. If you do break it out like so, then this will always perform better than the current implementation. As a good case study, here's our situation from work. We are trying to compute a root, we know it falls in a VERY large interval (in this case -1.0 to 1.0), but more than 99% of the time it will be between (say) 1.04 and 1.07. We can guess with stunning accuracy, at least 90% of the time we can come to within 10^-4 for very little cost (a very nice cubic approximation of the more complicated function), but we really need it to within 10^-8 or better. In addition, that 1% of the time, it can fall in very strange areas (0.9, or -0.3 or so), and our guess isn't very good when that happens. So we can't tighten down the interval, because that would cause spurious errors, and at the same time your linear interpolation isn't going to be very good at all. It easily takes you 3 or 4 steps to get as close as our first guess. Using the first guess in this manner would cut the steps to convergence from about 8-10 to about 3-5. A speed up of around 100%, with no loss in accuracy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-120) [math][patch] Pascal / Negative Binomial Distribution
[ https://issues.apache.org/jira/browse/MATH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated MATH-120: -- Fix Version/s: 1.2 [math][patch] Pascal / Negative Binomial Distribution - Key: MATH-120 URL: https://issues.apache.org/jira/browse/MATH-120 Project: Commons Math Issue Type: Improvement Environment: Operating System: All Platform: All Reporter: tparnell Priority: Minor Fix For: 1.2 Attachments: pascal.diff Implementation of the pascal distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Luc Maisonobe as Jakarta Commons committer
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
[
http://issues.apache.org/jira/browse/MATH-154?page=comments#action_12426209 ]
Brent Worden commented on MATH-154:
---
Can we change it to subtractAndCheck?
Also, it might be useful to add two additional methods to just check for
operation safety and not throw an exception. This would be useful in the RNG
methods Remi proposed where all that was needed was whether or not an operation
was valid. This would avoid creating an expensive exception for simple case
logic.
MathUtils addAndCheck and subAndCheck for long values
-
Key: MATH-154
URL: http://issues.apache.org/jira/browse/MATH-154
Project: Commons Math
Issue Type: Improvement
Affects Versions: Nightly Builds, 1.1 Final
Reporter: Remi Arntzen
Fix For: 1.2 Final
public static long addAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
public static long subAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[ http://issues.apache.org/jira/browse/MATH-153?page=comments#action_12426210 ] Brent Worden commented on MATH-153: --- I think we can avoid the overflow conditions simply by distributing the multiplication of the random value. With this, the method body would become: double r = rand.nextDouble(); return (int)((r * upper) + ((1.0 - r) * lower) + r); RandomDataImpl nextInt(int, int) nextLong(long, long) - Key: MATH-153 URL: http://issues.apache.org/jira/browse/MATH-153 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds, 1.1 Final Reporter: Remi Arntzen Priority: Critical Fix For: 1.2 Final RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors. change return lower + (int) (rand.nextDouble() * (upper - lower + 1)); to return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1))); additional checks must be made for the nextlong(long, long) method. At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes. The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DONE] Re: Bugzilla-Jira migration
Can I get brentworden added to jakarta-developers? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RE-VOTE] Release Commons Math 1.1
+1 - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: [RE-VOTE] Release Commons Math 1.1 Date: Sun, 11 Dec 2005 22:08:05 -0700 The problems reported with math 1.1 RC4 have been fixed. I would like to call for another release vote, based on the release candidate available here: http://people.apache.org/~psteitz/commons-math/1-1-rc5 Release notes are here: http://people.apache.org/~psteitz/commons-math/1-1-rc5/RELEASE-NOTES.txt and apidocs: http://people.apache.org/~psteitz/commons-math/1-1-rc5/apidocs/ The RC5 jar (commons-math-1.1-RC5.jar) has also been deployed to the apache internal maven repository at cvs.apache.org/repository Votes, please. The vote will close in 72 hours. Thanks in advance! Phil --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- - 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: [VOTE] [restarted] Release Commons Math 1.1
All set. Changes made to the MATH_1_1 branch. - Original Message - From: Phil Steitz To: Jakarta Commons Developers List Subject: Re: [VOTE] [restarted] Release Commons Math 1.1 Date: Thu, 8 Sep 2005 09:11:55 -0700 Good catch. Pls make the change and this will be fixed in RC3. On 9/7/05, Brent Worden wrote: -0 I tried doing a Maven build from the archives, but it failed on the site:generate goal because the checkstyle.xml and license-header.txt files were not included in the distro. Are we supporting the full Maven build cycle in the releases or just compilation and jarring? I can modify our maven.xml if others think its necessary. Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 8:54 PM To: Jakarta Commons Developers List Subject: [VOTE] [restarted] Release Commons Math 1.1 Please download and test the (hopefully final) Commons Math 1.1 release candidate here: http://people.apache.org/~psteitz/commons-math/1-1-rc3/ /people.apache.org/%7Epsteitz/commons-math/1-1-rc2/ One bug, reported during the first [VOTE], has been fixed: * Fixed bin index overflow problem in EmpiricalDistributionImpl (BZ 36450). The line endings on .txt files in the zip archives have been changed to be CRLF. Release notes are available here: http://people.apache.org/~psteitz/commons-math/1-1-rc3/RELEASE -NOTES.txt rc2/RELEASE-NOTES.txt Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Math 1.1 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Math 1.1 Thanks! Phil - 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: [VOTE] [restarted] Release Commons Math 1.1
-0 I tried doing a Maven build from the archives, but it failed on the site:generate goal because the checkstyle.xml and license-header.txt files were not included in the distro. Are we supporting the full Maven build cycle in the releases or just compilation and jarring? I can modify our maven.xml if others think its necessary. Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 8:54 PM To: Jakarta Commons Developers List Subject: [VOTE] [restarted] Release Commons Math 1.1 Please download and test the (hopefully final) Commons Math 1.1 release candidate here: http://people.apache.org/~psteitz/commons-math/1-1-rc3/http:/ /people.apache.org/%7Epsteitz/commons-math/1-1-rc2/ One bug, reported during the first [VOTE], has been fixed: * Fixed bin index overflow problem in EmpiricalDistributionImpl (BZ 36450). The line endings on .txt files in the zip archives have been changed to be CRLF. Release notes are available here: http://people.apache.org/~psteitz/commons-math/1-1-rc3/RELEASE -NOTES.txthttp://people.apache.org/%7Epsteitz/commons-math/1-1- rc2/RELEASE-NOTES.txt Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Math 1.1 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Math 1.1 Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Commons Math 1.1
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 7:52 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Commons Math 1.1 b) text files, including the NOTICE and LICENSE use Unix line endings. This is a debated point, but I always prefer to see at least the zips use Windows line endings. Anyone know how to fix this? How about adding a call to Ant's fixcrlf task inside our dist:build-bin and dist:build-src pregoals? http://ant.apache.org/manual/CoreTasks/fixcrlf.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Update to developers guide - contributing
Here are some suggestions: Under getting started (or somewhere else), specify Maven as the build tool of choice. State where Maven can be downloaded. Also, mention to build with Maven the commons-build project will also have to be grabbed from SVN and placed locally at the same directory level as commons-math. Under the contributing section, contributing ideas and code, item 4, stress code attachments should be patches whenever possible. Under the documentation subsection, add a blurb about making changes to the user guide. Under the licensing and copyright subsection, last bullet item, enumerate any sources we presently restrict. Also mention that if one has any licensing or copyright questions about possible contributions, that they should be raised on the mailing list. Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, August 27, 2005 6:34 PM To: Jakarta Commons Developers List Subject: [math] Update to developers guide - contributing I have some suggested updates to the developer's guide recommending a set of steps to follow when submitting new code / ideas. The idea is to make it easier for both contributors and committers and to make sure we don't lose track of things. The new stuff is in the Contributing section under contributing ideas and code http://people.apache.org/~psteitz/developers.html Comments / better ideas are welcome. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Houskeeping - committers, contributors please read
- Original Message - From: Phil Steitz [EMAIL PROTECTED] Other than 36266, where the patch looks OK to me (with a doc comment saying how we handle the cut point 0), and 36232 where the patch also looks OK to me (I agree that with the short-circuit and underflow comments) is there anyting else blocking 1.1 at this time? I would like to go ahead and cut a final release candidate and get the release out. I'll commit the change in 36232. 36266 looks ok. J., you have this issue assigned to yourself. Are you going to commit the changes? As for anything else prior to releasing, I think we need to find a home for the 1.0 javadoc prior to updating the website. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] JDK version
We support 1.3 and higher. Brent Worden - Original Message - From: Zhang [EMAIL PROTECTED] To: Phil Steitz [EMAIL PROTECTED] Subject: [math] JDK version Date: Fri, 12 Aug 2005 18:12:15 -0700 (PDT) Do we have requirement or guidelines on JDK version? Functions such as Math.expm1() and Math.cosh() are available in jdk 1.5 but not in jdk 1.4.2. I'm now using jdk 1.4.2 for developing and testing. Xiaogang Zhang __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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]
[math] RE: DO NOT REPLY [Bug 36084] - [math] serialization tests did not delete temp files
Test bug was isolated in the test cases. Should an entry be added to changes.xml to inform users of this fix? Or should changes.xml be reserved for mods to the core classes? Brent Worden -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 11:08 PM To: commons-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 36084] - [math] serialization tests did not delete temp 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=36084. 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=36084 [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-13 06:08 --- Fixed. SVN revision 232415. Temp files were not being deleted because open file streams were not being closed properly. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Rounding implementation in MathUtils
All done. Brent Worden - Original Message - From: Brent Worden [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: Re: [math] Rounding implementation in MathUtils Date: Mon, 08 Aug 2005 13:53:28 -0600 I started working on this today. I've resorted to rolling our own rounding functions instead of relying on BigDecimal for conversions. I will keep all the rounding options supplied by BigDecimal. Hopefully, I can get this done today. Brent Worden - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: [math] Rounding implementation in MathUtils Date: Mon, 8 Aug 2005 07:22:17 -0700 Can someone else pls have a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=35904 This is holding up the 1.1 release. I like the support for all of the rounding modes that we get by using BigDecimal and - though I have not verified this - I would expect the results to be exact over a wider range of value, scale combinations than direct implementation would give. On the other hand, we have the string conversion and object creation overhead. I haven't done any microbenchmarks, but if someone else has the time, it might be good to look at direct impl of, say, ROUND_HALF_UP vs. the current impl. Opinions please... I am inclined to close this as FIXED (once more tests have been added). Note that this will commit us to supporting all of the rounding modes, even if we decide to replace the implemenation later. Some of these - e.g. ROUND_NOT_NECESSARY - may have funny semantics for some double / float values. Additional unit tests to document / demonstrate / validate exactly how all of these modes work will be needed in any case. Phil - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Rounding implementation in MathUtils
I started working on this today. I've resorted to rolling our own rounding functions instead of relying on BigDecimal for conversions. I will keep all the rounding options supplied by BigDecimal. Hopefully, I can get this done today. Brent Worden - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: [math] Rounding implementation in MathUtils Date: Mon, 8 Aug 2005 07:22:17 -0700 Can someone else pls have a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=35904 This is holding up the 1.1 release. I like the support for all of the rounding modes that we get by using BigDecimal and - though I have not verified this - I would expect the results to be exact over a wider range of value, scale combinations than direct implementation would give. On the other hand, we have the string conversion and object creation overhead. I haven't done any microbenchmarks, but if someone else has the time, it might be good to look at direct impl of, say, ROUND_HALF_UP vs. the current impl. Opinions please... I am inclined to close this as FIXED (once more tests have been added). Note that this will commit us to supporting all of the rounding modes, even if we decide to replace the implemenation later. Some of these - e.g. ROUND_NOT_NECESSARY - may have funny semantics for some double / float values. Additional unit tests to document / demonstrate / validate exactly how all of these modes work will be needed in any case. Phil - 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: [math] RE: svn commit: r201912 - /jakarta/commons/proper/math/trunk/release-notes.xsl
I've used it with good success. If you've seen any of the Maven plugin release announcements circulating on the mailing lists, then you've seen the plugin in action. You may need to upgrade to the lastest version, 1.3, as it provides the means to specify a custom JSL transform. Brent Worden - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: Re: [math] RE: svn commit: r201912 - /jakarta/commons/proper/math/trunk/release-notes.xsl Date: Sun, 26 Jun 2005 20:30:09 -0700 Poo it is, then :-) Much rather use something from maven. I was unaware that this existed. I Will rip this stuff out, assuming the plugin works OK. Thanks! Phil On 6/26/05, Brent Worden [EMAIL PROTECTED] wrote: Not to poo-poo on your work, but have you considered using the Maven Announcement plugin for generating release notes? It performs the same job of creating a text file based on the changes.xml items. Brent Worden -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, June 26, 2005 4:44 PM To: [EMAIL PROTECTED] Subject: svn commit: r201912 - /jakarta/commons/proper/math/trunk/release-notes.xsl Author: psteitz Date: Sun Jun 26 14:43:34 2005 New Revision: 201912 URL: http://svn.apache.org/viewcvs?rev=201912view=rev Log: Eliminated trailing spaces. Modified: jakarta/commons/proper/math/trunk/release-notes.xsl Modified: jakarta/commons/proper/math/trunk/release-notes.xsl URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trun k/release-notes.xsl?rev=201912r1=201911r2=201912view=diff == --- jakarta/commons/proper/math/trunk/release-notes.xsl (original) +++ jakarta/commons/proper/math/trunk/release-notes.xsl Sun Jun 26 +++ 14:43:34 2005 @@ -77,27 +77,27 @@ kludge to re-insert line feeds removed by parser. Assumes new lines all start with three or more leading spaces. -- -xsl:variable name=pad select=' '/ -xsl:template name=keep.breaks +xsl:variable name=pad select=' '/ +xsl:template name=keep.breaks xsl:param name=input/ - xsl:if test=string-length($input) 0 -xsl:choose - xsl:when test=contains($input,$pad) -xsl:variable name=init select=normalize-space(substring-before($input,$pad))/ -xsl:variable name=term select=substring-after($input,$pad)/ + xsl:if test=string-length($input) 0 +xsl:choose + xsl:when test=contains($input,$pad) +xsl:variable name=init select=normalize-space(substring-before($input,$pad))/ +xsl:variable name=term + select=substring-after($input,$pad)/ xsl:if test=string-length($init) 0 xsl:value-of select=$init/xsl:value-of select=$CRLF/ -/xsl:if +/xsl:if xsl:if test=string-length($term) 0 xsl:call-template name=keep.breaks xsl:with-param name=input select=$term/ /xsl:call-template -/xsl:if - /xsl:when - xsl:otherwise -xsl:value-of select=normalize-space($input)/ - /xsl:otherwise -/xsl:choose - /xsl:if +/xsl:if + /xsl:when + xsl:otherwise +xsl:value-of select=normalize-space($input)/ + /xsl:otherwise +/xsl:choose + /xsl:if /xsl:template /xsl:stylesheet - 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] - 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]
[math] RE: svn commit: r201912 - /jakarta/commons/proper/math/trunk/release-notes.xsl
Not to poo-poo on your work, but have you considered using the Maven Announcement plugin for generating release notes? It performs the same job of creating a text file based on the changes.xml items. Brent Worden -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, June 26, 2005 4:44 PM To: [EMAIL PROTECTED] Subject: svn commit: r201912 - /jakarta/commons/proper/math/trunk/release-notes.xsl Author: psteitz Date: Sun Jun 26 14:43:34 2005 New Revision: 201912 URL: http://svn.apache.org/viewcvs?rev=201912view=rev Log: Eliminated trailing spaces. Modified: jakarta/commons/proper/math/trunk/release-notes.xsl Modified: jakarta/commons/proper/math/trunk/release-notes.xsl URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trun k/release-notes.xsl?rev=201912r1=201911r2=201912view=diff == --- jakarta/commons/proper/math/trunk/release-notes.xsl (original) +++ jakarta/commons/proper/math/trunk/release-notes.xsl Sun Jun 26 +++ 14:43:34 2005 @@ -77,27 +77,27 @@ kludge to re-insert line feeds removed by parser. Assumes new lines all start with three or more leading spaces. -- -xsl:variable name=pad select=' '/ -xsl:template name=keep.breaks +xsl:variable name=pad select=' '/ +xsl:template name=keep.breaks xsl:param name=input/ - xsl:if test=string-length($input) gt; 0 -xsl:choose - xsl:when test=contains($input,$pad) -xsl:variable name=init select=normalize-space(substring-before($input,$pad))/ -xsl:variable name=term select=substring-after($input,$pad)/ + xsl:if test=string-length($input) gt; 0 +xsl:choose + xsl:when test=contains($input,$pad) +xsl:variable name=init select=normalize-space(substring-before($input,$pad))/ +xsl:variable name=term + select=substring-after($input,$pad)/ xsl:if test=string-length($init) gt; 0 xsl:value-of select=$init/xsl:value-of select=$CRLF/ -/xsl:if +/xsl:if xsl:if test=string-length($term) gt; 0 xsl:call-template name=keep.breaks xsl:with-param name=input select=$term/ /xsl:call-template -/xsl:if - /xsl:when - xsl:otherwise -xsl:value-of select=normalize-space($input)/ - /xsl:otherwise -/xsl:choose - /xsl:if +/xsl:if + /xsl:when + xsl:otherwise +xsl:value-of select=normalize-space($input)/ + /xsl:otherwise +/xsl:choose + /xsl:if /xsl:template /xsl:stylesheet - 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: [math][patch] 1.4 dependency in FractionFormat
You might want to add a couple of modifications better enforce an integer
constraint:
NumberFormat nf = NumberFormat.getNumberInstance(locale);
nf.setMaximumFractionDigits(0);
nf.setParseIntegerOnly(true);
Brent Worden
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 25, 2005 10:31 PM
To: Jakarta Commons Developers List
Subject: Re: [math][patch] 1.4 dependency in FractionFormat
Committed. Pls review this and the other Fraction changes.
Phil
On 6/12/05, Mark Diggory [EMAIL PROTECTED] wrote:
+1
Phil Steitz wrote:
When building with 1.3, I discovered that the FractionFormat class
introduced a 1.4 dependency. The change below removes the
dependency
and the tests pass. If there are no objections, I will
commit this,
which will fix the build on 1.3
---
src/java/org/apache/commons/math/fraction/FractionFormat.java
(revision
178359)
+++
src/java/org/apache/commons/math/fraction/FractionFormat.java
(working copy)
@@ -150,7 +150,7 @@
* @return the default number format specific to the
given locale.
*/
private static NumberFormat getDefaultNumberFormat(Locale
locale) {
-NumberFormat nf = NumberFormat.getIntegerInstance(locale);
+NumberFormat nf = NumberFormat.getNumberInstance(locale);
return nf;
}
Phil
-
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]
-
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: [lang] IoUtils...
commons-io has utility methods along those lines. Brent - Original Message - From: James Carman To: 'Jakarta Commons Developers List' Subject: [lang] IoUtils... Date: Thu, 16 Jun 2005 12:46:38 -0400 Do we have any plans on developing a class for generic IO utilities such as copying streams? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] javadoc for prior releases.
I'll hold off committing my changes in light of these previous discussions. What is the status for a javadoc archive location? Would it be unreasonable to place javadoc in the java-repository? Brent -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 31, 2005 10:53 PM To: Jakarta Commons Developers List Subject: Re: [math] javadoc for prior releases. Brent, I like the outcome that you are after and mentioned on the site-dev list that I had been toying with patching the maven site plugin to optionally do exactly what you are describing. Others - Hen, Brett - responded that while it is good to have versioned javadoc available on the site, having the site build pull and regenerate it each time is not the best approach, since it never changes. Hen suggested that we might be better off establishing an apache javadoc repo where we can publish these things *once* and then link to them definitively. Hen, Brett pls chime in if I have misrepresented anything. Can we agree on a definitive location on minotaur/www where we can place versioned javadoc? How about jakarta.apache.org/commons/javadoc/component/release? I am personally OK with committing your changes if you have this working (including the SCM plugin dependency, as long as it works on both Windoz and linux) and changing to use the repo once we have that sorted. Phil On 5/31/05, Brent Worden [EMAIL PROTECTED] wrote: I've been working on automating the the generation of javadoc for prior releases for inclusion on the website. The change involves adding a post goal to the javadoc report goal. The post goal performs a checkout from the repository for a tagged version of the project. Javadoc is then executed on the checked out source, placing the generated HTML in a directory at the same level as the default javadoc. One downside to this change is that it requires using version 1.5-beta-3 of the Maven SCM Plugin. This is needed because prior versions do not support Subversion. If there are no objections, I will commit these changes. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] javadoc for prior releases.
I'll hold off committing my changes in light of these previous discussions. What is the status for a javadoc archive location? Would it be unreasonable to place javadoc in the java-repository? Brent -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 31, 2005 10:53 PM To: Jakarta Commons Developers List Subject: Re: [math] javadoc for prior releases. Brent, I like the outcome that you are after and mentioned on the site-dev list that I had been toying with patching the maven site plugin to optionally do exactly what you are describing. Others - Hen, Brett - responded that while it is good to have versioned javadoc available on the site, having the site build pull and regenerate it each time is not the best approach, since it never changes. Hen suggested that we might be better off establishing an apache javadoc repo where we can publish these things *once* and then link to them definitively. Hen, Brett pls chime in if I have misrepresented anything. Can we agree on a definitive location on minotaur/www where we can place versioned javadoc? How about jakarta.apache.org/commons/javadoc/component/release? I am personally OK with committing your changes if you have this working (including the SCM plugin dependency, as long as it works on both Windoz and linux) and changing to use the repo once we have that sorted. Phil On 5/31/05, Brent Worden [EMAIL PROTECTED] wrote: I've been working on automating the the generation of javadoc for prior releases for inclusion on the website. The change involves adding a post goal to the javadoc report goal. The post goal performs a checkout from the repository for a tagged version of the project. Javadoc is then executed on the checked out source, placing the generated HTML in a directory at the same level as the default javadoc. One downside to this change is that it requires using version 1.5-beta-3 of the Maven SCM Plugin. This is needed because prior versions do not support Subversion. If there are no objections, I will commit these changes. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] FW: [interest in] SummerOfCode2005 commons-math project
One thing you should know is the algorithms implemented in Numerical Recipes are copyrighted under terms that are incompatible with the Apache license. As such, commons-math can not contain any code derived from these routines. The precedent we have established is to not allow any code developed using NR as a source and instead find alternate citations for the algorithms detailed in NR. I would suggest you change your focus from the PRNG routines laid out in NR and research some other routines. Two that come to my mind that have been released under public domain terms are George Marsaglia's The Mother of All Random Number Generators and the Mersenne Twister. Brent Worden -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 12:39 AM To: commons-dev@jakarta.apache.org Subject: Re: [math] FW: [interest in] SummerOfCode2005 commons-math project Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge
RE: [math] FW: [interest in] SummerOfCode2005 commons-math project
One thing you should know is the algorithms implemented in Numerical Recipes are copyrighted under terms that are incompatible with the Apache license. As such, commons-math can not contain any code derived from these routines. The precedent we have established is to not allow any code developed using NR as a source and instead find alternate citations for the algorithms detailed in NR. I would suggest you change your focus from the PRNG routines laid out in NR and research some other routines. Two that come to my mind that have been released under public domain terms are George Marsaglia's The Mother of All Random Number Generators and the Mersenne Twister. Brent Worden -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 12:39 AM To: commons-dev@jakarta.apache.org Subject: Re: [math] FW: [interest in] SummerOfCode2005 commons-math project Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge
Re: [math][patch] 1.4 dependency in FractionFormat
Good catch. One thing you might want to do is override the minimum decimal
digits by setting that property to zero.
Brent
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List commons-dev@jakarta.apache.org
Subject: [math][patch] 1.4 dependency in FractionFormat
Date: Sun, 12 Jun 2005 21:34:31 -0400
When building with 1.3, I discovered that the FractionFormat class
introduced a 1.4 dependency. The change below removes the dependency
and the tests pass. If there are no objections, I will commit this,
which will fix the build on 1.3
--- src/java/org/apache/commons/math/fraction/FractionFormat.java
(revision
178359)
+++ src/java/org/apache/commons/math/fraction/FractionFormat.java
(working
copy)
@@ -150,7 +150,7 @@
* @return the default number format specific to the given locale.
*/
private static NumberFormat getDefaultNumberFormat(Locale locale) {
-NumberFormat nf = NumberFormat.getIntegerInstance(locale);
+NumberFormat nf = NumberFormat.getNumberInstance(locale);
return nf;
}
Phil
-
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]
[math] javadoc for prior releases.
I've been working on automating the the generation of javadoc for prior releases for inclusion on the website. The change involves adding a post goal to the javadoc report goal. The post goal performs a checkout from the repository for a tagged version of the project. Javadoc is then executed on the checked out source, placing the generated HTML in a directory at the same level as the default javadoc. One downside to this change is that it requires using version 1.5-beta-3 of the Maven SCM Plugin. This is needed because prior versions do not support Subversion. If there are no objections, I will commit these changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Making PRNG pluggable in o.a.c.m.random classes
Adding a wrapper makes total sense. That way, any RandomGenerator (ours or someone elses) implementation can be used where Random objects are required. Likewise, a RandomGenerator that wraps a Random would be a good addition. Then any Random extension can be used inside commons-math. With those two wrappers we would have complete, bi-directional pluggability with the J2SE. Brent Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks, Brent. As I write up the docs, I am thinking about adding one more thing, which I would apprecate feedback on. I mentioned above that the RandomGenerator / AbstractRandomGenerator provided a generic facility for replacing java.util.random. Recompilation is still required, however, to use this. I am thinking now that it might be useful to add a class that *extends* java.util.Random to wrap a RandomGenerator to make it possible to do this in a binary compatible way. Does this make sense? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math][proposal] Release math 1.1
I looked over things and before you proceed with a RC, I would like to make a few changes to some doco. In particular: 1. Add @since directives to the new classes and methods. 2. Make some javadoc corrections in WeibullDistributionImpl. 3. Change the anchor names on the http://jakarta.apache.org/commons/math/userguide/overview.html page. We have specified our own names, but the commons-build.jsl script is using the section names instead. Also, are you planning on adding a random generator section to the user guide? Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 7:57 PM To: commons-dev@jakarta.apache.org Subject: [math][proposal] Release math 1.1 I propose that we cut a 1.1 release of commons-math. There have been a number of bug fixes and some significant enhancements since 1.0. Changes since 1.0 are here: http://jakarta.apache.org/commons/math/changes-report.html The only open bug is http://issues.apache.org/bugzilla/show_bug.cgi?id=32663, which I will fix by adding a TestUtils class with factory methods to instantiate t and chi-square tests. If there are no objections, must-haves for 1.1 or other forms of hand-wringing, I will roll an RC including the enhancement above and kick off a vote next week. Phil - 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: [math][proposal] Release math 1.1
I looked over things and before you proceed with a RC, I would like to make a few changes to some doco. In particular: 1. Add @since directives to the new classes and methods. 2. Make some javadoc corrections in WeibullDistributionImpl. 3. Change the anchor names on the http://jakarta.apache.org/commons/math/userguide/overview.html page. We have specified our own names, but the commons-build.jsl script is using the section names instead. Also, are you planning on adding a random generator section to the user guide? Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 7:57 PM To: commons-dev@jakarta.apache.org Subject: [math][proposal] Release math 1.1 I propose that we cut a 1.1 release of commons-math. There have been a number of bug fixes and some significant enhancements since 1.0. Changes since 1.0 are here: http://jakarta.apache.org/commons/math/changes-report.html The only open bug is http://issues.apache.org/bugzilla/show_bug.cgi?id=32663, which I will fix by adding a TestUtils class with factory methods to instantiate t and chi-square tests. If there are no objections, must-haves for 1.1 or other forms of hand-wringing, I will roll an RC including the enhancement above and kick off a vote next week. Phil - 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: [math] Making PRNG pluggable in o.a.c.m.random classes
The implementation looks good an a lot less heftier than what I was
anticipating.
Good work,
Brent Worden
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 15, 2005 1:39 PM
To: Jakarta Commons Developers List
Subject: Re: [math] Making PRNG pluggable in o.a.c.m.random classes
I committed the changes described above. Feedback welcome.
I tested adapting and integration a RngPack generator.
Adaptor for Mersenne Twister looks like this (base adaptor
for all RngPack generators would be similar):
/**
* AbstractRandomGenerator based on RngPack RanMT generator.
*/
public class TestRngPackGenerator extends AbstractRandomGenerator {
private RanMT random = new RanMT();
public void setSeed(long seed) {
random = new RanMT(seed);
}
public double nextDouble() {
return random.raw();
}
public double nextGaussian() {
return random.gaussian();
}
public int nextInt(int n) {
return random.choose(n);
}
public boolean nextBoolean() {
return random.coin();
}
}
I will update the user guide to include this and other
examples assuming all are OK with these changes.
Phil
-
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: [math] Making PRNG pluggable in o.a.c.m.random classes
The implementation looks good an a lot less heftier than what I was
anticipating.
Good work,
Brent Worden
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 15, 2005 1:39 PM
To: Jakarta Commons Developers List
Subject: Re: [math] Making PRNG pluggable in o.a.c.m.random classes
I committed the changes described above. Feedback welcome.
I tested adapting and integration a RngPack generator.
Adaptor for Mersenne Twister looks like this (base adaptor
for all RngPack generators would be similar):
/**
* AbstractRandomGenerator based on RngPack RanMT generator.
*/
public class TestRngPackGenerator extends AbstractRandomGenerator {
private RanMT random = new RanMT();
public void setSeed(long seed) {
random = new RanMT(seed);
}
public double nextDouble() {
return random.raw();
}
public double nextGaussian() {
return random.gaussian();
}
public int nextInt(int n) {
return random.choose(n);
}
public boolean nextBoolean() {
return random.coin();
}
}
I will update the user guide to include this and other
examples assuming all are OK with these changes.
Phil
-
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: [math][proposal] Release math 1.1
@since javadoc tags. I'm adding them to all the new types and methods in 1.1 Bad choice of terms on my part. Brent Worden -Original Message- From: Eric MacAdie [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 12:21 AM To: Jakarta Commons Developers List Subject: Re: [math][proposal] Release math 1.1 Maybe this is a dumb question, but: What are @since directives? EKMacAdie Brent Worden wrote: I looked over things and before you proceed with a RC, I would like to make a few changes to some doco. In particular: 1. Add @since directives to the new classes and methods. 2. Make some javadoc corrections in WeibullDistributionImpl. 3. Change the anchor names on the http://jakarta.apache.org/commons/math/userguide/overview.htm l page. We have specified our own names, but the commons-build.jsl script is using the section names instead. Also, are you planning on adding a random generator section to the user guide? Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 7:57 PM To: commons-dev@jakarta.apache.org Subject: [math][proposal] Release math 1.1 I propose that we cut a 1.1 release of commons-math. There have been a number of bug fixes and some significant enhancements since 1.0. Changes since 1.0 are here: http://jakarta.apache.org/commons/math/changes-report.html The only open bug is http://issues.apache.org/bugzilla/show_bug.cgi?id=32663, which I will fix by adding a TestUtils class with factory methods to instantiate t and chi-square tests. If there are no objections, must-haves for 1.1 or other forms of hand-wringing, I will roll an RC including the enhancement above and kick off a vote next week. Phil - 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: [math][proposal] Release math 1.1
@since javadoc tags. I'm adding them to all the new types and methods in 1.1 Bad choice of terms on my part. Brent Worden -Original Message- From: Eric MacAdie [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 12:21 AM To: Jakarta Commons Developers List Subject: Re: [math][proposal] Release math 1.1 Maybe this is a dumb question, but: What are @since directives? EKMacAdie Brent Worden wrote: I looked over things and before you proceed with a RC, I would like to make a few changes to some doco. In particular: 1. Add @since directives to the new classes and methods. 2. Make some javadoc corrections in WeibullDistributionImpl. 3. Change the anchor names on the http://jakarta.apache.org/commons/math/userguide/overview.htm l page. We have specified our own names, but the commons-build.jsl script is using the section names instead. Also, are you planning on adding a random generator section to the user guide? Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 7:57 PM To: commons-dev@jakarta.apache.org Subject: [math][proposal] Release math 1.1 I propose that we cut a 1.1 release of commons-math. There have been a number of bug fixes and some significant enhancements since 1.0. Changes since 1.0 are here: http://jakarta.apache.org/commons/math/changes-report.html The only open bug is http://issues.apache.org/bugzilla/show_bug.cgi?id=32663, which I will fix by adding a TestUtils class with factory methods to instantiate t and chi-square tests. If there are no objections, must-haves for 1.1 or other forms of hand-wringing, I will roll an RC including the enhancement above and kick off a vote next week. Phil - 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: [math] Making PRNG pluggable in o.a.c.m.random classes
1) Extract the interface from java.util.Random -- same names and contracts. Call this interface RandomGenerator. It will contain: setSeed(long seed) nextBytes(byte[] bytes) int nextInt() int nextInt(int n) long nextLong() boolean nextBoolean() double nextDouble() float nextFloat() double nextGaussian() I would prefer to separate out these generation methods into different types. IMO, the RandomGenerator interface should contain a sole generation method. One of: int next(int numberOfBits) // similar to the java.util.Random method int next() // discrete uniform over [0, Integer.MAX_VALUE] double next() // uniform over [0, 1) The remaining methods I would implement as specialized random variable generators that use a RandomGenerator instance as an engine. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Making PRNG pluggable in o.a.c.m.random classes
1) Extract the interface from java.util.Random -- same names and contracts. Call this interface RandomGenerator. It will contain: setSeed(long seed) nextBytes(byte[] bytes) int nextInt() int nextInt(int n) long nextLong() boolean nextBoolean() double nextDouble() float nextFloat() double nextGaussian() I would prefer to separate out these generation methods into different types. IMO, the RandomGenerator interface should contain a sole generation method. One of: int next(int numberOfBits) // similar to the java.util.Random method int next() // discrete uniform over [0, Integer.MAX_VALUE] double next() // uniform over [0, 1) The remaining methods I would implement as specialized random variable generators that use a RandomGenerator instance as an engine. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Ortwin Glück [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Mark, You mentioned the maven ant goal. I had never tried it before and I just gave it a spin. The result is not really usable though. The build.xml starts off with all kind of properties that contain local path names and there is no property file tag before those definitions! Checking in such a build.xml would not help anybody. Dennis mentioned a patch for the ant plugin. As long as it is not in the standard Maven distribution this is no option either. As of Maven 1.0, the plugins have releases independent of the Maven core. To patch the ant plugin, you simply need to update that plugin. This can easily be accomplished by executing the following maven command: maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.8.1 Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] fraction class
Phil, I knew my implementations were not the most performant so, feel free to make any improvements you deem worthy. Brent Worden Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Brent, Sorry for the latency. I like the API (and rational number vs. fraction definition), but the numerics (minimizing overflows, speed) could be improved by following the Knuth 4.5.1 algorithms for arithmetic operations and gcd as described in C. Scott Ananian's patch to the old [lang] implementation here: http://issues.apache.org/bugzilla/show_bug.cgi?id=29294, which I applied to the [lang] version. I will get to this prior to 1.1 if I hear no objections and no one beats me to it. Phil Brent Worden wrote: I just committed a fraction class based on the one found in commons-lang. Please provide any feedback regarding its correctness, completeness, etc. Thanks, Brent Worden - 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]
[math] fraction class
I just committed a fraction class based on the one found in commons-lang. Please provide any feedback regarding its correctness, completeness, etc. Thanks, Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Nagoya references
[math] is done. Brent Worden -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, December 31, 2004 12:45 PM To: Jakarta Commons Developers List Subject: Nagoya references http://www.apache.org/~noel/nagoya-references.txt Need to be moved to issues.apache.org for jira/bugzilla; mail-archives.apache.org for eyebrowse and wiki.apache.org/old for the old wiki links. 137 - latka 99 - math 74 - jelly 67 - httpclient 49 - master 27 - cli 26 - discovery 24 - el 24 - sandbox 22 - fileupload 20 - io 18 - betwixt 17 - primitives 16 - lang 8 - discover 6 - beanutils 5 - configuration 4 - logging 4 - validator 4 - codec 3 - dbcp 2 - modeler 2 - jexl.old 2 - net 2 - jxpath 1 - collections 1 - commons.html 1 - email 1 - resources 1 - pool 1 - digester 1 - dbutils 1 - releases 1 - jexl 1 - launcher 1 - directory.html 1 - attributes 1 - transaction - 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: [email] website
Have anyone else noticed the missing directory images in the left navigation area? I believe this is a result of using the custom commons-site.jsl stylesheet with the 1.0 release of Maven. Examples of this is the newly published resources and email sites: http://jakarta.apache.org/commons/resources http://jakarta.apache.org/commons/email I tried using the default stylesheet shipped with maven-xdoc-plugin-1.8 but the result weren't the most desirable. By using the command: maven -Dmaven.xdoc.jsl= -Dmaven.xdoc.theme=classic \ -Dmaven.xdoc.ui.banner.background=#fff xdoc I was able to generate a site with the same color schema as pre-release Maven sites but with a couple (if not more) glaring deficiencies. First, some of the menu items (the About Us section) are missing from the left navigation area. Second, resizing the browser window causes all kinds of layout problems with columns overlapping, odd text wrapping and the like. I uploaded a snapshot of math to display these quirks: http://www.apache.org/~brentworden/math/index.html Can someone in the know look into this and offer suggestions for a resolution? Brent Worden -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 12:23 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [email] website Thanks, resources is now updated. -Mark Martin Cooper wrote: Sorry about that. I've chmod'ed the files. Thanks! -- Martin Cooper On Sat, 27 Nov 2004 12:38:33 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: Martin, As well, I've done some minor changes to resources. The same permissions issue exists in the /www/jakarta.apache.org/commons/resources/.. under your name. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: Eric, I made some adjustments to the email site generation to correct some problems. You have all the permissions on /www/jakarta.apache.org/commons/email/.. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - -- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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: [vote][math] Release Math 1.0
+1 Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 10:32 AM To: Jakarta Commons Developers List Subject: [vote][math] Release Math 1.0 There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. -- Phil Steitz - 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: [math][vote] Release 1.0-RC2
+1 Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, November 07, 2004 7:07 PM To: Jakarta Commons Developers List Subject: [math][vote] Release 1.0-RC2 This vote is to approve the public release of commons math 1.0-RC2. This release candidate incorporates community feedback on RC1. Like RC1, this will be a publicly announced RC to enable full feedback for a final 1.0 release in about two weeks if all is well. A complete list of changes since RC1 is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/docs/chang es-report.html The release candidate distribution files are here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ The updated web site is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/docs/ Voting will last at least 72 hours. As always, it would be useful if others could check the md5 checksums and asc signatures. Thanks, Phil - 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: [math][vote] Release 1.0-RC2
I'll update the user guide section of the site with the Poisson addition. Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, November 07, 2004 7:07 PM To: Jakarta Commons Developers List Subject: [math][vote] Release 1.0-RC2 This vote is to approve the public release of commons math 1.0-RC2. This release candidate incorporates community feedback on RC1. Like RC1, this will be a publicly announced RC to enable full feedback for a final 1.0 release in about two weeks if all is well. A complete list of changes since RC1 is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/docs/chang es-report.html The release candidate distribution files are here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ The updated web site is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/docs/ Voting will last at least 72 hours. As always, it would be useful if others could check the md5 checksums and asc signatures. Thanks, Phil - 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: [math] Questions regarding probability distributions
Here's my basis for the exponential, chi-squared, and gamma distribution design (forgive me for reiterating some points made by others): Exponential is separate because both the CDF and inverse CDF have closed form computations. This provides better performance and higher accuracy than the iterative method approximation. Both exponential and chi-squared are separate from gamma to provide access only to the parameters specific to each distribution. In chi-squared case, extension could have easily been use but this would have exposed the alpha and beta properties in chi-squared. This would allow users to modify the properties in an uncontrolled fashion, possibly resulting in a disfunctional distribution. Thus, encapsulation was used to hide the gamma properties and only expose the relavent chi-squared properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Do we need to support Ant based builds?
Are we all sure that absolute paths are no longer inserted into Maven generated build.xml files? As long as your using the latest 1.0 release. Unfortunately, there are still some cases (including [math]) where absolute paths get inserted. -Phil Using Maven 1.0 isn't sufficient. I believe version 1.8.1 of the ant plugin is needed to fully fix the absolute path issue. It must be downloaded seperately which can be done via maven's plugin:download goal. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [MATH] Matrix indices
Ok, I tally (pre-apologies if I misrepresent anyone): Four votes for 0-based indexing (Andrew, Kim, Mark, and Stephen). Three votes for 1-based indexing (Al, Phil, and myself). Should we go ahead with the 0-based change and put this to rest? Or do we still need some debate? I, for one, want to move on. Brent Worden -Original Message- From: Gray, Andrew (ITDA) [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 2:44 AM To: 'Jakarta Commons Developers List' Subject: RE: [MATH] Matrix indices ditto below - +1 for Zero based indices. Principle of Least Astonishment and all that.. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: 02 September 2004 08:42 To: Jakarta Commons Developers List Subject: Re: [MATH] Matrix indices From: Al Chou [EMAIL PROTECTED] 1) Change the RealMatrix getEntry, getRow, getColumn methods to use 0-based indexing. FWIW, if I were using this class, I would expect it to be 0-based. I can't comment on the other points as I don't hav the maths background. (If I needed one, I would probably search for it or ask, thus the name is less interesting to me) Sorry for the late input. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Department for Environment, Food and Rural Affairs (Defra) This email and any attachments is intended for the named recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and inform the sender. Whilst this email and associated attachments will have been checked for known viruses whilst within Defra systems we can accept no responsibility once it has left our systems. Communications on Defra's computer systems may be monitored and/or recorded to secure the effective operation of the system and for other lawful purposes. - 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: [MATH] Summary proposed changes
1) Change the RealMatrix getEntry, getRow, getColumn methods to use 0-based indexing. Looking at the implementation, I believe the current indexing is satisfactory and I can't think of where using it with native arrays would be overly burdensome or confusing. As for letting the language dictate the indexing, I think this is a bad practice for developing an API. APIs are supposed to be language agnostic and should exhibit the same behavior no matter the implementing language. If we allow the language to dictate the behavior of an API method, its possible the behavior will be different for other languages. I feel these situations should be avoided so the API is portable to a wide array of languages, which I feel is a long-term goal of some of our developers. 2) Change the name of BivariateRegression to UnivariateRegression (or something else) If we're bothering to change its name to make it less confusing, let's call it what it is, SimpleLeastSquaresRegression. If that is too long, then SimpleRegression as least squares is the inferred method when one mentions regression. 3) Change Variance to be configurable to generate the population statistic. Since population variance and sample variance are different statistics, they should be different classes as that is the design we have chosen. As for the static methods on the variance and standard deviation classes, the javadoc should be changed to better explain the source of the mean argument. The comments should indicate the mean is pre-computed using the same values that are going to be used to compute the variation estimate. Any other mean passed in will result in the variation computation to be unreliable. 4) Combine the univariate and multivariate packages, since it is confusing to separate statistics that focus on one variable and sometimes the word univariate is used in the context of multivariate techniques (e.g. Univariate Anova). Regression is used to study relationships between measurable variables. [Weisberg, 1985] Regression analysis is a statistical tool that utilizes the relations between two or more quantitative variables... [Neter, et al., 1985] Both these statements indicate regression is a technique that involves more than one variable. Therefore, regression in general is a multivariate technique. The case where there is only one predictor is immaterial as there are two variable quantities. Would one call a model with one predictor variable and two response variables a univariate technique? I wouldn't and I doubt if anyone else would. The path we have chosen, by placing procedures dealing with one variable in the univariate package and all other procedures dealing with more than one variable is satisfactory and makes for a good discriminant. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] [vote] Release 1.0-RC1
[X] +1 Go ahead and release 1.0-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 1.0-RC1, because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Only sample variances?
Any objection to tracking these and future feature requests using the wiki? A wish list, if you will. -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, August 15, 2004 1:06 PM To: Jakarta Commons Developers List Subject: Re: [math] Only sample variances? Kim van der Linde wrote: Hi, I just looked through the variance class, and saw that it only supports sample vasriance (N-1) but not population variances (N). Any reason for this, and can it be added? It would probably be better to add this to one of the aggregates or StatUtils or to add a new statistic altother. This is because a UnivariateStatistic can only report one value. The most commonly used (at least in statistical applications) value for Variance and Standard Deviation is the sample statistic, which is why that is what the statistics named StandardDeviation and Variance report. From a user's perspective, its not too hard to convert; but I agree that it would be convenient to add these. Probably best to make new statistics in the moment subpackage called PopulationXxx. Patches welcome ;-) Phil Cheers, Kim __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] RC1 available for review
Any objections to using the maven-changes-plugin to provide release notes? If not, I can start working on it. Brent Worden -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, August 15, 2004 5:29 PM To: Jakarta Commons Developers List Subject: Re: [math] RC1 available for review 1) No NOTICE.txt files in ZIPs or JARs - Critical!! 2) Experimental .java files included in src ZIP 3) I couldn't find the javadoc on the main website (try adding a link in the left menu) Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] I have put a first cut at RC1 for review here: http://jakarta.apache.org/~psteitz/commons-math-1.0-RC1 Pls have a look and let me know what is missing / incorrect, other than MD5 and KEYS. Assuming the content is good, I will generate these, do the CVS tagging and kick off an RC1 [VOTE]. Pointing out any javadoc or user guide errors / typos would also be much appreciated. These are both up to date on the web site: http://jakarta.apache.org/commons/math/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] RC1 available for review
Phil Steitz wrote: Brent Worden wrote: Any objections to using the maven-changes-plugin to provide release notes? If not, I can start working on it. I certainly have no objection to that, but based on other 1.0 releases, I did not think we needed release notes. What will the changes plugin generate? I assumed we did while reading the Release Notes section of http://jakarta.apache.org/commons/releases/prepare.html. Anyway, here's Maven's as an example: http://maven.apache.org/changes-report.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] RC1 available for review
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, August 15, 2004 7:25 PM To: Jakarta Commons Developers List Subject: Re: [math] RC1 available for review *since the last release*. If we were to include release notes, I would think that the right thing to include would be a single statement to the effect that 1.0 is the initial release of commons-math. Ok. I'll refrain from adding the report 'til after the release. No need to hold it up any longer. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Math] Getter methods in Frequency when there is no data
I agree with returning zero for the absolute frequencies. For the relative frequencies, I would argue for returning NaN as is done in BivariateRegression when there is insufficient data. Brent Worden -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 3:45 PM To: Jakarta Commons Users List Subject: RE: [Math] Getter methods in Frequency when there is no data Thanks for reporting this. I agree that getCumFreq should return 0, but the pct and cumPct are more problematic. One could argue that an IllegalStateException would be more appropriate for these. If there have been no values added, percentages don't really make sense. Thoughts? Phil -Original Message- From: Shing Hing Man [mailto:[EMAIL PROTECTED] Sent: Wed 8/11/2004 7:41 AM To: commonMath Cc: Subject: [Math] Getter methods in Frequency when there is no data Hi, I have tested all the getter methods of org.apache.commons.math.stat.univariate.Frequency when no data has been added. (If anyone is interested, the JUnit test file is attached.) Here is a summary of the result. Method Result getCount returns 0 (as expected) getCumFreq java.util.NoSuchElementException getCumPct java.util.NoSuchElementException getPct returns NaN f.getSumFreq return 0 (as expected) Is it reasonable to expect all the getter methods to return 0, when there is no data ? My version of org.apache.commons.math is dated 10th August, 2004. regards, Shing = Home page : http://uk.geocities.com/matmsh/index.html ___ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/math build.xml
FYI, this problem still exists in RC3 of Maven (version 1.7 of the ant
plugin). So, I modified the jelly script to create paths relative to
${basedir}. I sent my changes to the Maven team and they recently got
incorporated into the development stream of the ant plugin.
So, prior to the next release of the ant plugin, I would recommend getting
the latest jelly script before attempting to generate build.xml.
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 24, 2004 8:55 AM
To: Jakarta Commons Developers List
Subject: Re: cvs commit: jakarta-commons/math build.xml
Yes, this still was an issue with RC1. So we need to be carefull.
matthew.hawthorne wrote:
Phil Steitz wrote:
Ouch! Once again, maven is generating local path references. Does
anyone know how to stop this???
I had hand-edited the previous version to correct this.
I had heard it was fixed back around rc1, but was never able to
confirm it. I think it's the ${basedir} references that screw it up,
and I'm never quite sure if I need ${basedir} in there, especially if
I'm doing
multiproject builds.
-
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: [math] ArrayUtils.isAscending, isDescending
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 9:15 PM To: Jakarta Commons Developers List Subject: Re: [lang] ArrayUtils.isAscending, isDescending Any ideas where this should go in [math]? The application is in testing that the knot points passed to SplineInterpolator.interpolate(-,-) and to PolynomialSplineFunction constructor form a partition. Sorting to fix would be a bad idea, since you would have to parallel sort the y values or polynomial function arrays, resp. Phil I have no problem with it going into MathUtils. Or we could create our own ArrayUtils that supplements the one found in [lang]. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 27243] - [math] T-Distribution causing a StackOverflowError
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 5:12 PM To: Jakarta Commons Developers List Subject: Re: DO NOT REPLY [Bug 27243] - [math] T-Distribution causing a StackOverflowError The nightly build does indeed build the sandbox version of commons-math instead of the commons proper version. That will be fixed as of tonight's (20040304) version. Sorry for not catching this when math graduated out of the sandbox. Craig Thanks Craig Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Nightly build not using correct source tree.
I believe the nightly builds are being built using the sandbox sources. Who would I talk to about changing this or where should I go to get this remedied? Brent Worden http://www.brent.worden.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 11:39 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 27243] - [math] T-Distribution causing a StackOverflowError --- Additional Comments From [EMAIL PROTECTED] 2004-03-03 05:38 --- I took a look at the nightly build jars and they are most definately out of date. I believe that the nightly build process is going after the sandbox CVS module and not commons proper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:28 PM To: 'Jakarta Commons Developers List' Subject: RE: Web Presence for ALL Jakarta Commons components No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 11:22 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: Web Presence for ALL Jakarta Commons components When I find a few minutes, I'll try to put up a page on the wiki to help us organise this effort, with a list of tasks that need to happen to get us where we want to be. (Unless, of course, someone beats me to it! ;) I put a little page together trying to summarize what's been discussed already: http://nagoya.apache.org/wiki/apachewiki.cgi?CreatingStandardWebPresence Feel free to make and changes. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] re: move to Apache Commons
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 12:53 AM To: [EMAIL PROTECTED] Subject: [math] re: move to Apache Commons I have always maintained that the simple lang-like extension stuff fits in Jakarta Commons, while the math/stat framework stuff does not. I partially disagree with the framework comment. Mainly, because a precedent has been set with commons-logging for allowing such a framework as envisioned by the [math] members. Quoting the [logging] home page: The Logging package is an ultra-thin bridge between different logging libraries. Commons components may use the Logging API to remove compile-time and run-time dependencies on any particular logging package, and contributors may write Log implementations for the library of their choice. I foresee the proposed [math] API as providing the same purpose; providing a mathematical API where contributors may write implementations for the library of their choice. I think that it is to accommodate the framework and non-Java development ideas that Robert is recommending the move to Apache Commons. I agree with him. Any non-Java work definitely does not belong in Jakarta, Commons or elsewhere. I would recommend, however, that the proposal be rewritten to reflect the broader scope. No problem with that. I will concede, that the [math] group is, IMO, trying to take on too many endeavors at once and maybe a reality check is in order. In the near-term for [math], this is what I would like to see: 1) a 1.0 release 2) expand on the 1.0 features for the next release (i.e. add more distributions, hypothesis tests, root finders, etc.). 3) add ONE new math vertical/discipline for the next release. For instance, we could chose to add a FFT implementation which some people have expressed a desire to have. 4) make another release. For the long-term, I would just keep repeating that cycle. I think this would keep the [math] contributors primarily focused on the things you care about, the mathUtils portion, and with some attention allotted to broadening [math] into the package of our dreams (or nightmares depending on your point of view). Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] remove derivative methods from distribution annonymous class
--- Additional Comments From [EMAIL PROTECTED] 2003-11-11 15:08 --- Hey Brent, have you gotten your commit rights yet? I've signed and faxed the CLA and I sent a email to [EMAIL PROTECTED] with my requested login info. I have yet to here anything back. I'll double check the committer FAQ and make sure I followed the proper procedure. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Numerical Derivative pattern q.
Will a Differentiator/Factory be solving for the derivative? In which case, as the algorithms used are really already implemented in the solvers, wouldn't we just expand them with methods that allow us to solve for the derivatives? For Example: UnivariateRealSolver bs = new BisectionSolver(...); double d = bs.solveFirstDerivative(min,max); and double d = bs.solveSecondDerivative(min,max); -Mark I'm not too keen to the explicit method calls because it seems so limiting. How about using decorators much like commons-collections? We could apply a DerivativeFunctionDecorator which alters the Function.evaluate method to return the derivate evaluation using center differences or something similar. Then the decorated function could be used in the solvers or any other place a Function object is accepted. If someone wanted to solve for the second derivate, apply the decorator to the original function twice. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Complex implementation
FYI, I wrote some unit tests for ComplexMath and found some bugs in my implementation. I have a patch containing the tests and bug fixes ready to submit. However, I noticed commons doesn't have a math component listed yet, so I was going to hold off on submitting the patch. If anyone is interested in seeing the changes, the patch file is available at http://www.brent.worden.org/complex-tests.txt. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Isn't it about time?
Pietschman, I like your Decomposer API idea too. I think this is something we can consider as having commonalities with what I've been in discussion with Paul about equation solvers for integration etc. I think there's some room for common api's in both these cases. Do you? The decomposition API looks quite solid and well thought out. -Mark p.s. I still think we will want to make decisions concerning see this stuff in this release vs the next release. I'm sure there are pros and cons to going in either direction. But, I think it important we try to get a release up of what we've accomplished so far, before moving too far forward. I am of the opinion that everything we've been discussing should be held over to the next release. The functionality currently implemented by commons-math goes far beyond what was envisioned in the project proposal. Before going to much further, I would like to receive some user opinions about the current API to help drive us for future functionality and enhancements. Also, since I'm not known to be humble, it would be nice to be rewarded with a release after all of our hard work. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [primitives] Package layout strategy
So the battle has become: o.a.c.primitives.boolean o.a.c.primitives.byte o.a.c.primitives.short o.a.c.primitives.int o.a.c.primitives.long o.a.c.primitives.float o.a.c.primitives.double vs. o.a.c.primitives.collection o.a.c.primitives.list o.a.c.primitives.iterator o.a.c.primitives.map Any other opinions? To my knowledge, the type based packaging as presented is not possible. boolean, byte, short, et al are Java keywords and can not be used as parts of a package name. So, if a type based approach is to be employed, convoluted names for primitive types would need to be used instead of their conventional names. With that, I would say, the collection based approach is clearly the better alternative. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Exceptions again...
Hi, I found that [math] still wont compile on JDK 1.3 due to the super(throwable) constructors in MathException. Should we just write off 1.3 users, now that a reasonable 1.4 is available on basically all platforms which run Java at all? Unless I'm mistaken, Brent's patch contained some corrections for this problem. Yes. I should be the one Mark just applied. It's using o.a.c.lang.NestedException like James mentioned. Further, there still wasn't a conclusion on what to do with analysis.ConvergenceException, which is used in util.ContinuedFraction only, and also is a RuntimeException instead of a checked Exception. Point one: given the current code, it seems to be misplaced. Point two: Falling out of the loops in the root finders actually indicates a convergence problem (either too stringent accuracy settings, ill conditioned functions causing oscillations or a bug in the algorithm) I'd like to use a ConvergenceException for this condition too, however, throwing a mix of checked and unchecked exceptions for conditions of comparable complexity is something I'd rather avoid. Possible solutions: 1. abolish ConvergenceException completely and replace it in ContinuedFraction by a (checked) MathException. This will cause adding a throws MathException in a heck of a lot of places, including on gamma and beta functions and everywhere they are used. The discussion whether the kind of functions should throw a checked exception wans't conclusive yet. 2. derive ConvergenceException from MathException (and palce it in [math] root), further see above. 3. make MathException a runtime exception and replace ConvergenceException with a MathException. 4. make MathException a runtime exception and derive ConvergenceException from MathException. 5. Leave as is but move ConvergenceExcpetion to [math] root 6. as 5 but move to [math]/util Any ideas/recomendations/votes? J.Pietschmann I'm for 2 with the addendum that the beta and gamma functions catch it and return NaN much like the functions in java.lang.Math. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] A bug in org.apache.commons.math.stat.univariate.rank.Percentile, ver 1.5?
I just submitted a patch that fixes this bug.
Brent Worden
http://www.brent.worden.org
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 11:02 AM
To: Jakarta Commons Developers List
Subject: Re: [math] A bug in
org.apache.commons.math.stat.univariate.rank.Percentile, ver 1.5?
Thanks Sherwin, I'm a little buisy today, but this is an easy fix and
test to do. I'll try to look at it this evening.
-Mark
Sherwin Wang wrote:
Hi,
Using this code, we can see the problem.
double[] d = new double[]{1, 2, 3};
Percentile p = new Percentile(75);
p.evaluate(d);
The fix seems to replace line 148 from
if (pos n) {
to
if (pos = n) {
Please let me know after the bug is fixed or how I can change the code.
Best regards,
Sherwin Wang
212-454-2751
Insight Project Development, Deutsche Bank
23rd West, 280 Park Av. NYC, NY 10017
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Project Maturity?
-Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 11:42 AM To: Jakarta Commons Developers List Subject: [math] Project Maturity? I think we should discuss what really needs to get completed for the 1.0 release of math. I think there are three points of interest. A.) If it isn't a major refactoring, it probably stands that we can provide a feature in a later minor release, for example, adding confidence intervals, extending distributions with discrete capabilities. Agreed. With the hypergeometric patch, all the distributions promised for the first release have been delivered. B.) Many tasks are ongoing and are never really finished, ie accuracy testing, checkstyle and javadoc. Again I agree. With my latest javadoc patch, checkstyle violations were down to under 20 and javadoc warnings under 50. This I believe is acceptable since other commons projects have checkstyle errors numbering in the thousands. C.) Many aspects of the project already out-perform even that which is in commons proper. Documentation and JUnit testing is fairly thorough. The only thing I would like to see (but it doesn't have to happen before a release) is the expanding of the user guide. So I wonder, would it be logical to request a vote from the community proper to consider that maturity of the math project and if its ready to release a version? There will always be discovered issues. But we do need to get to the point where we have actual users to discover those issues. -Mark Diggory I have no problem with having a vote. Here's a list of the tasks from the current task list: 1.) Develop user's guide following the package structure. Provide any comments on this task here. This would be the only thing, at this time, I think we should work on prior to a vote. However, since the javadoc is quit complete, not having this done should not impact any vote outcome by much. 2.) Performance and accuracy testing. If anyone is interested in helping out here, what we could really use is a wider selection of test cases for the core numerical functions and validation against either other packages (e.g. R for the statistical stuff), verified datasets, or experiments comparing implement ions using floats to doubles. 3.) Test Coverage. Clover tests show gaps in test path coverage. Get all tests to 100% coverage. Also improve test data and boundary conditions coverage. FYI, 100% coverage is impossible with our design decisions. There are private, default constructors that never get called and are not intended to get called. As such, the methods can never be covered during test execution. With my test-coverage patch, I got just over 90% coverage. There were a couple of classes with individual coverage of 50% which, if test were written, could boost the coverage closer to 95%. In short, I think our unit test are more than adequate and we should change the 100% notion on the site to something realistic like 90% or 95%. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Project Maturity?
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 1:39 PM To: Jakarta Commons Developers List Subject: Re: [math] Project Maturity? I just discovered a bunch of printStackTrace() in BeanTransformer. Any ideas how this should be handled in a better way? Throwing a MathException? One of my patches replaced these with logging calls. I know this doesn't answer your questions; I just wanted to remove those statements without changing the current behavior. I'm more than open to a debate. Additions: - Find a way to make [math] compile and run under JDK 1.3 again. This mainly consists of deriving the exceptions from [lang] NestableException and adding a GUMP/Maven dependency on [lang]. This is in one of my patches. - Make the default root finder run time configurable again. Well, if necessary. This is in one of my patches. In now uses commons-discovery. DiscoveryClass uses, among other things, a system property to determine the real solver factory. - Possibly get rid of RootFinding in favor of moving the functionality to UnivariateRealSolverUtil? Dunno. This is in one of my patches. RootFinding is now no more. - Rename UnivariateRealSolverUtil to UnivariateRealSolverUtils? This is in one of my patches. - Rename UnivariateRealSolverImpl to UnivariateRealSolverSPI? Since this in an abstract class. I would prefer AbstractUnivariateRealSolver. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] JLink for Mathematica and Generic API's
I know this is actually outside of the scope of development for commons math. But, I think its interesting to see where all these projects are going in terms of Java development, cross language interaction and the exposure of their api's. One interest to me is defining a subset of functionality across all these applications that can also applies to commons math. I'm interested in the possibility of a specification/api that can be used to define statistical/mathematical evaluations in java. A generic api that one could write an evaluation in which could be executed against any provider, similar in nature to JAXP or JNDI. -Mark If you're talking about creating a Service Provider Interface, I whole-heartedly agree. I envision we would follow the existing JAR service provider mechanism (http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html#Service%20Provider) and use commons-discovery to enable it. The library, as it stands, wouldn't be too hard to morph into two separate JARs, one for the API and one for the default implementation. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] MutableNumbers: if you have an idea, please share it.
Here's some mutable number types I've had laying around for about 5 years. Feel free to use them in lang (or disregard them) as you see fit. Brent Worden http://www.brent.worden.org -Original Message- From: _matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2003 4:17 PM To: [EMAIL PROTECTED] Subject: [lang] MutableNumbers: if you have an idea, please share it. I have started some initial work on the concept of MutableNumbers, that I mentioned a few months ago. Before I begin anything major, I want to get some feedback. Any comments and suggestions are appreciated, especially with regard to class design, and usefulness. Initial design MutableNumber // Internal value double value; // java.lang.Number overrides byte byteValue() short shortValue() int intValue() long longValue() float floatValue() double doubleValue() // Mutator methods setByteValue(byte) setShortValue(short) setIntValue(int) setLongValue(long) setFloatValue(float) setDoubleValue(double) Two sample extensions would be: MutableInteger MutableInteger(int) MutableFloat MutableFloat(float) Questions 1) Would MutableNumbers be useful? A typical usage could be: Thing.setId(new Integer(1)) Thing.setId(new Integer(2)) Thing.setId(new MutableInteger(1)) Thing.getId().setIntValue(2) But, in looking at this, it doesn't seem to make much of a difference. Are there any other uses? 2) Is double an acceptable internal type for all numbers? It seemed simplest to choose the largest type, and upcast all other types. 3) Where should the following methods go? Byte byteObject() Short shortObject() Integer intObject() Long longObject() Float floatObject() Double doubleObject() The could all easily be placed in the MutableNumber class itself, but this would almost eliminate the need for subclasses entirely. If MutableNumber is not abstract, it becomes: MutableNumber num = new MutableNumber() num.setIntValue(5) num.intObject() vs. MutableInteger mutInt = new MutableInteger(5) mutInt.intObject() 4) Would the following be good additions also? boolean booleanValue() setBooleanValue(boolean) Boolean booleanObject() This may duplicate some current commons functionality (in BooleanUtils I believe), but I think this addition would be consistent with the other methods. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mutable.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Recent commits to stat, util packages
. And if you were a user, with the currently implementation, there is nothing you could do about it but pray it'll be added in the next release of commons-math. However, with the object approach, you'd create a simple statistic object that can be used with univariate and all your troubles go away. for example b) add to the ExtendedUnivariate interface c) extend an existing Univariate implementation to add the new statistic or d) create a new Univariate including the new statistic or computational strategy. U Again, you yourself labeled c and d as ridiculous when you labeled Mark's idea of adding a class for each statistic as such. The current univariates have encapsulated way too much responsibility instead of delegating it to other objects. This makes the code very unstable as it will need to change frequently. As I see it, the univariate types are responsible for two things: maintaining a window of data and computing summary statistics I would suggest separating each of these responsibilities into separate objects. I would make a window policy object that knows if/when data values should be removed when others are added and if individual data values are accessible. I would make a statistics strategy object that knows what statistics to compute and how to compute them based on the window policy. The univariate would act as a mediator between the two objects. I like Mark's approach, but I think I would take it a little further in terms of abstraction by making univariate independent of the statistics its calculating. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Recent commits to stat, util packages
Then we're back to dependency issues where now theres another interface that is restrictive and difficult to expand upon easily, it will be hard to add things to the library because everyone will be arguing about what should/shouldn't be in interface, uughh. :-( I am becoming more and more against having these generic Univariate interfaces where a particular statistic is embodied in a method. every time someone comes up with a new method there will be debate about should it be in the interface or not. Instead of just being an additional class that can be added to the package. This is the benefit of a framework over monolithic interfaces. Preach on brother Mark. I too would argue that the Univariate interfaces need to change and take on more of the look and feel provided by Mark and his statistic objects. One reason for this is flexibility. By forcing Univariate to determine the statistics it can compute we limit users as to when they can use Univariate's features of window and storageless computation. That is to say, a user only gets the benefit of those features iff the statistics they need computed are defined by the interface. Granted, we've taken some effort to include the most commonly used statistics in the interface, but others remain that the user might have a need for but can't leverage Univariate to compute them. By using statistic objects, like those supplied by Mark, and some way to supply those object data via the Univariate objects we can eliminate that limitation of the current design. Another reason for this is performance. The storageless Univariate implementation is a compute all or nothing design. Because of this, every time a new statistic is added to the interface, the extra computation needed to compute the new statistic slows down the computation of the existing statistics. With the current design, if a new statistic is added, all current users of Univariate in adversely effected, in terms of performance, by the change even though they don't rely on the new statistic. For instance, add Mark's auto-correlation coefficients and all of a sudden all existing test statistics using Univariate have gotten slower. That is a clear sign of bad design. Still another reason is maintenance. With every new statistic added to Univariate, besides the method added to support the statistic, numerous other methods need to change to support the computation, most notably addValue. Each addition of a statistic will make that method more complex which in turn makes it harder to debug, harder to change, and harder to understand. Also, with changing existing, working code, one runs the risk of introducing errors where none previously existed. It would royally bite, once we added auto-correlation coefficients again and then have variance no longer work. In comparison, it's impossible to break existing code by adding new code that isn't dependent on anything else, such as the case with Marks statistic objects. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
I've been playing around with the Functor library a little and I reworked
the bisection routine to be functorfied. With the addition of functors, the
algorithm has become totally agnostic to its input allowing it to be used in
an endless number of settings. The code goes as follows:
//=== BEGIN BisectionSolver.java ===
package org.apache.commons.math.analysis;
import org.apache.commons.functor.BinaryFunction;
import org.apache.commons.functor.BinaryPredicate;
import org.apache.commons.functor.UnaryFunction;
/**
* This solver applies the bisection root finding method to the given
* functor input.
* @author Brent Worden
*/
public class BisectionSolver {
/** function used to evaluate potential roots. */
private UnaryFunction function;
/** function used to compute the midpoint of two potential roots. */
private BinaryFunction midpoint;
/** predicate used to determine if two potential roots are equal.
stopping condition. */
private BinaryPredicate areEqual;
/** predicate used to determine if two potential roots bracket the
actual root. */
private BinaryPredicate equalSign;
/**
*
*/
public BisectionSolver(UnaryFunction function, BinaryFunction midpoint,
BinaryPredicate areEqual, BinaryPredicate equalSign) {
super();
this.function = function;
this.midpoint = midpoint;
this.areEqual = areEqual;
this.equalSign = equalSign;
}
/**
*
*/
public Object solve(Object a, Object b) {
Object m;
Object fm;
Object fa;
fa = function.evaluate(a);
while (!areEqual.test(a, b)) {
m = midpoint.evaluate(a, b);
fm = function.evaluate(m);
if (equalSign.test(fm, fa)) {
// b and m bracket the root.
a = m;
fa = fm;
} else {
// a and m bracket the root.
b = m;
}
}
return midpoint.evaluate(a, b);
}
}
//=== END BisectionSolver.java ===
//=== BEGIN UnivariateRealSolverFactory .java
===
package org.apache.commons.math.analysis;
import java.lang.reflect.InvocationTargetException;
import org.apache.commons.functor.BinaryFunction;
import org.apache.commons.functor.BinaryPredicate;
import org.apache.commons.functor.UnaryFunction;
import org.apache.commons.math.MathConfigurationException;
import org.apache.commons.math.MathException;
/**
*
*/
public class UnivariateRealSolverFactory {
protected UnivariateRealSolverFactory() {
}
/**
* create a bisection solver for the given function. If we envision
allowing different inputs,
* such as Tim's bean driven approach, construction of the solver could
be contained in another
* factory method.
*/
public static BisectionSolver newBisectionSolver(final
UnivariateRealFunction f){
UnaryFunction function = new UnaryFunction() {
public Object evaluate(Object x) {
try {
return new Double(f.value(((Number)x).doubleValue()));
} catch(MathException ex) {
return new Double(Double.NaN);
}
}
};
BinaryFunction midpoint = new BinaryFunction() {
public Object evaluate(Object a, Object b) {
double x = ((Number)a).doubleValue();
double y = ((Number)b).doubleValue();
return new Double(x + ((y - x) * .5));
}
};
BinaryPredicate areEqual = new BinaryPredicate() {
public boolean test(Object a, Object b) {
double x = ((Number)a).doubleValue();
double y = ((Number)b).doubleValue();
return Math.abs(x - y) = 10e-9;
}
};
BinaryPredicate equalSign = new BinaryPredicate() {
public boolean test(Object a, Object b) {
double x = ((Number)a).doubleValue();
double y = ((Number)b).doubleValue();
return x * y = 0.0;
}
};
return new BisectionSolver(function, midpoint, areEqual, equalSign);
}
/**
* Convenience method to apply the bisection method to a function.
* This is synonymous with the textbook application of the bisection
method.
* Again, if we envision allowing different inputs, more convenience
methods could be added.
*/
public static double solveUsingBisection(UnivariateRealFunction f,
double x0, double x1) {
BisectionSolver solver = newBisectionSolver(f);
return ((Number)solver.solve(new Double(x0), new
Double(x1))).doubleValue();
}
}
//=== END UnivariateRealSolverFactory .java
===
//=== BEGIN RealSolverTest.java ===
package org.apache.commons.math.analysis
Re: [math][functor] More Design Concerns
My point in (b.) is to discuss what amount to Facades approached in
classes/interfaces like (Store)Univariate and RealMatrix, and the idea
that there are decisions being made concerning how the Facades are
backed by various implementation strategies, not to suggest that the
Facades themselves should go away. Right now we have some design
evolution thats going on in the math.stat package, over the last few
weeks we've experimented with Abstract Implementations, Inherited
Delegation and Static Delegation strategies, currently finding
satisfaction and dissatisfaction in various aspects of each approach.
Some cases the inheritance hierarchy got complicated (UnivariateImpl
extending AbstractStoreUnivariate), some cases the extensibility of the
implementations becomes a concern (StatUtils being static). This
discussion attempts to draw the problem space we are encountering here
and clarify it, Functional approaches are but one means of possibly
dealing with this problem space.
In my utopia I would like to see these classes move away from primitives and
embrace objects. The reason for this is they can not fully leverage other
commons projects such as Collections and Functor because they are built to
work with objects. This limits our ability to use more of the advance
features found in those packages.
If we moved to objects, I think the class hierarchy for univariates would be
simplified tremendously. I foresee two implementations, one stored the
other non-stored. For computing the statistics, I would like to see a
functor type object used to compute each metric. These metric objects would
be specific to the type of values it dealt with. The univariate could be
decorated with these metric objects to add computational functionality.
This allows the problem/user to dictate the statistics to be calculated so
there is no more computing values that are never accessed. On the
maintenance front, it removes the need for an ever increasing univariate
interface but still allows for ever increasing functionality.
An example of when this would be used is the t-test. A t-test could be use
a unvariate that is decorated with three metric objects: one each for sample
size, mean, and variance. The caller would add the values to the univariate
and then access the statistics from the metric object instead of the
univariate.
We could take it a step further by allowing the functors to compute more
than one metric and have them be adaptable into individual metric objects.
Going back to the t-test, one functor could be used to compute all three
values, possibly making use of some computational efficiencies. When the
caller wants each metric, the functor could morph into the needed metric.
For ease of use and the novice user, all this complexity could be hidden
behind the utility methods. For the more advanced user, a set of predefined
java.lang.Number metric objects could be supplied that they attach to
univariates. For the power user, new metric object can be developed and
attached to univariates. The last approach would be necessary when a custom
data type is used that the library doesn't support.
Here's a sample of what I mean:
//= BEGIN UtopiaUnivariate.java =
package org.apache.commons.math.stat;
import java.math.BigDecimal;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import org.apache.commons.collections.Closure;
import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.collections.iterators.ArrayIterator;
/**
* @author Brent Worden
*/
public class UtopiaUnivariate {
/** */
private Map metrics = new HashMap();
/**
*
*/
public UtopiaUnivariate(){
super();
}
/**
* Add a value to this univariate. The univariate adds the value to
each metric.
*/
public void addValue(final Object value) {
Closure c = new Closure() {
public void execute(Object source) {
((Metric)source).addValue(value);
}
};
CollectionUtils.forAllDo(metrics.values(), c);
}
/**
* Adds a metric to this univariate. Each metric is notified of added
values.
*/
public void addMetric(final Metric metric){
Closure c = new Closure() {
public void execute(Object source) {
metrics.put(source, metric);
}
};
CollectionUtils.forAllDo(metric.getMetrics(), c);
}
/**
* Gets the metric value for the given type.
*/
public Object getMetric(Class type){
Object ret = null;
Metric metric = (Metric)metrics.get(type);
if(metric != null) {
ret = metric.getMetric(type);
}
return ret;
}
/**
* Novice users are isolated from the metric complexity via the
convenience methods.
*/
public static double
RE: [math][functor] More Design Concerns
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 2:43 PM To: Jakarta Commons Developers List Subject: Re: [math][functor] More Design Concerns [EMAIL PROTECTED] wrote: I would steer away for primative as much as possible. Keep in mind that excessive object creation can and usually is a significant performance drain, both because it is slow in itself despite all kinds of optimization as well as causing more GC. J.Pietschmann Maybe this was a concern a few years ago but with the improvements to HotSpot and GC, these arguments against Java object creation have diminished in power. One of the biggest gains in GC performance has been with short-lived objects (the type of objects that commons-math would be creating and using) and effectively and efficiently allocating them in memory and releasing them. And with HotSpot, frequently executed pieces of code will actually start to increase in performance as a application runs longer, and in many occasions eclipse C or C++ performance. Here are a few interesting links about Java performance: http://java.sun.com/j2se/1.4/performance.guide.html http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/p dfs/2583.pdf http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.visi.com/~khuber/java/JavaC.pdf Here's one article that's hard to fathom: http://www.javaperformancetuning.com/news/qotm028.shtml Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math][functor] More Design Concerns
Sorry for my non-response on any part of this thread. I've been away on vacation. -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 7:20 PM To: Jakarta Commons Developers List Subject: Re: [math][functor] More Design Concerns J.Pietschmann wrote: Mark R. Diggory wrote: Further comments: 1 Now there are two root finding frameworks in place. I think this should be unified. I agree. My preference would be to eliminate the original RootFinding.java and refactor the distribution inversion methods to use the new framework. Before taking that step, however, I would like to hear Brent's opinion on what might be improved in the new framework. The only issues I have are with the UnivariateRealSolverFactory class. I feel there should be a separation of the factory method and the solve methods. I don't think the solve method belong on a factory. They are more appropriately placed (do I dare say) in a SolverUtils utility type class. Also, for the factory to provide its intended flexibility, I would reimplement it using the abstract factory design pattern. This allows the factory to be swapped in and out at the user's leisure. As it stands the factory can only create one product even though there are several products that could be created. If a user wants/needs to create a specific solver, they must circumvent the factory and use the constructor. This defeats the whole purpose of the factory which is to control product creation. I would suggest adding factory methods that enable the creation of the other products. 2 Either derive ConvergenceException from MathException and use it in BrentSolver and SecantSolver too for indicating convergence problems, or replace it in or somewhere near Gamma.java with a MathException. I agree. My vote would be to leave MathException in math and derive ConvergenceException in analysis from it. That makes sense. I would suggest moving ConvergenceException out of org.apache.commons.math.analysis because I think we'll eventually have a cyclical package dependency with org.apache.commons.math.util as ContinuedFraction depends on ConvergenceException. 6 Factorials and binominal coefficients are classical classroom examples, but I never saw them in any real world implementation of a numerical algorithm. Well, with the possible exception of number theory related stuff. In fact, encountering these is usually an indication that the algorithm could be sped up by at least an order of magnitude. Interesting perspective. The uses that I had in mind were for discrete probability distributions (and yes, maybe some number-theoretic or purely combinatorial stuff). I have from time to time needed to compute binomial coefficients and/or probabilities in testing or simulation applications. Now that we have the Gamma function, binomial probablilities don't really need binomial coefficients. If others agree that these will have limited practical application, I would be OK with dropping them. 1) limited practical application implies some practical application. 2) They are already coded, tested, and working. Therefore, I would suggest leaving them in. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] @throws IllegalArgumentException
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, June 14, 2003 4:21 PM To: Jakarta Commons Developers List Subject: [math] @throws IllegalArgumentException I am dutifully cleaning up the CheckStyle warnings in my code and I am hesitating to remove @throws IllegalArgumentException, which CheckStyle currently complains about. I am a little ambivalent about this. There is a property (checkstyle.javadoc.checkUnusedThrows) that we can set to make it ignore these. I notice that [lang] has this set to false. I actually prefer to leave these unused throws tags in. Any strong opinions on this? Phil I have no problem with it. A better alternative might be to explicitly add runtime exceptions to the throws clause of methods. This doesn't effect callers as they're still not required to add try-catch blocks. Plus, we could then leave the check enable to catch any actual violations. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] matters of copyright
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 4:00 PM To: Jakarta Commons Developers List Subject: Re: [math] matters of copyright The site http://yacas.sourceforge.net/Algomanual.html may be interesting in this context, in particular http://yacas.sourceforge.net/Algochapter6.html The software is GPL but maybe they'll even agree to lifting some code from them... J.Pietschmann Also, here's a public domain library containing some matrix routines: http://math.nist.gov/javanumerics/jama/ We might want to borrow a linear systems solver from here. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Static Utils and Methods
-Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Brent Worden wrote: On the discussion of MathUtils, StatUtils and the placement of the average(double, double) method, if the method name was changed to midpoint, would people prefer it be place in MathUtils, StatUtils, or up my keester. Please, limit your replies to two emails. :-) Brent Worden http://www.brent.worden.org I would say, up your keester! ;-) Brent, this is all grounds for establishing the organization of the packages and the overall design process of the project, its all a very excellent discussion. :-) thanks... I think midpoint is somewhat vague too. Ok, maybe we can get a little deeper into this using your case as an example. (1) What are your requirements/needs for an average(double, double) style static method? This is more of looking to the future need than anything else. If we want to incorporate non-parametric inference to the library, the average of two numbers is needed a lot. (2) What are your (or others) needs for this to be present outside your class (or even static)? Are there others who need this method too? I think only bisection would use it as of now. [my thought]: If its strictly just for (d1 + d2) / 2.0, I doubt you would want the cost of instantiating an entire Univariate implementation behind it. Especially when its called from within an iteration of some recursive convergence algorithm. Which brings us to the following. I envisioned it solely as a simple, one-line, utility method. (3) We have a couple cases tangled together here. (a) the case of providing static functionality to (non-static) implementations of our algorithms. (b) the case of providing static utilities to commonly used simple math functions (factorial, sign, etc). (b) is what I see XXXUtils being. Simply put, just because we wrote a powerful descriptive stats class, doesn't make it the most appropriate solution to put behind a static interface for something as simplified as (d1 + d2) / 2.0. Its like shooting a rabbit with a cannon, cannons are more expensive, take up more space and harder to move around than shotguns. I think it would be wise to separate the static methods using above two concepts when placing methods/functionality into the static interfaces. I think it would also be wise if we had some protocol for the election of a method into the MathUtils interface. Warranted, this may be a bit anal, but wouldn't it be wise to outline the appropriate requirements for when an method is added to MathUtils? This way it doesn't turn into thrift store of methods, some of which shouldn't have been there, some which never get used more than once. Fine by me. This makes sense to me. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] proposed ordering for task list, scope of initial release
-Original Message- From: Al Chou [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 2:14 PM To: Jakarta Commons Developers List Subject: Re: [math] proposed ordering for task list, scope of initial release --- Phil Steitz [EMAIL PROTECTED] wrote: Brent Worden wrote: I've used a default error constant several places. It would be nice to come up with a central location for such values. I get the first 3, but what exactly do you mean by the default error constant? I read that to mean the accuracy requested (aka allowable error) of a given algorithm invocation. That's right. Certain routines perform their iterative computations until a desired accuracy is achieved. If the user doesn't explicitly state this accuracy, what should it be? A default error/accuracy constant would answer that and provide uniform level of accuracy throughout the library. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] proposed ordering for task list, scope of initial release
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 3:04 PM To: Jakarta Commons Developers List Subject: Re: [math] proposed ordering for task list, scope of initial release Phil Steitz wrote: My philosophy on this is that whatever exceptions we define should be close to the components that throw them -- e.g. ConvergenceException. I do not like the idea of a generic MathException. As much as possible, I think that we should rely on the built-ins (including the extensions recently added to lang). Regarding ConvergenceException, I am on the fence for inclusion in the initial release, though I see something like this as eventually inevitable. Correct me if I am wrong, but the only place that this is used now is in the dist package and we could either just throw a RuntimeException directly there or return NaN. I do see the semantic value of ConvergenceException, however. There are several approaches to design a concept for exceptions, all of which have pros and cons. I personally would suggest to avoid returning NaNs and throwing RuntimeExceptions whereever possible and use a package specific hierarchy of declared exceptions instead. J.Pietschmann I would agree whole-heartedly. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] proposed ordering for task list, scope of initial release
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 3:06 PM To: Jakarta Commons Developers List Subject: Re: [math] proposed ordering for task list, scope of initial release Al Chou wrote: Finally, having used the Pietschmann root finder framework, I think it needs some modification to make it more user-friendly. As a lay user, I would have been much happier dealing with Brent W.'s interface than Herr Pietschmann's, which was kind of cumbersome. I think, though, with a little slimming down, it would be quite workable. I'm interested in hearung a few more details: what makes the framework cumbersome? Admittedly I didn't have time yet to look at Brent's framework. J.Pietschmann For clarification, I never meant for the bisection method to be the end-all for root finding. I just needed something to facilitate the distribution implementations. I would prefer using J's object approach to the static method any day, if for no reason then because of the inflexibility of static methods. They can't be overriden, they can't hold on to any state (a nice feature in J's work), they can't be subclassed, ... That being said, any design can be approved on (sorry J, even yours), but the flavor of the object approach is, IMO, more agreeable than the static method approach. It also is inline with the direction most of the library is beginning to take; complex algorithms encapsulated in strategy type objects which are interchangeable through a common interface. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] proposed ordering for task list, scope of initial release
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] There are several approaches to design a concept for exceptions, all of which have pros and cons. I personally would suggest to avoid returning NaNs and throwing RuntimeExceptions whereever possible and use a package specific hierarchy of declared exceptions instead. J.Pietschmann I would agree whole-heartedly. That's where I started, but then Tim and others convinced me that it was actually better/more convenient for users for us to behave more like java.Math and java's own arithmetic functions -- which use NaN all over the place. Here's a saying I've used in the past when debating colleagues: Just because someone else does something, that doesn't make it right. :) Also, from a usage standpoint, if we use checked exceptions everywhere, this is a bit inconvenient for users. We need to find the right balance. I am one the fence on this whole issue. I am interested in hearing more about what others may have in mind. The big problem I have with returning NaN is the caller has little knowledge why NaN is being returned. If an exception is thrown, preferably a specialized exception like ConvergenceException, the caller knows precisely the reason for failure and can take appropriate recovery action. Phil Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] proposed ordering for task list, scope of initial release
to the package. We should also be thinking about other things to add to MathUtils -- religiously adhering to th guiding principles, of course. Al's sign() is an excellent example of the kind of thing that we should be adding, IMHO. Things that might be added: Average of two numbers comes up a lot. Something similar to JUnit's assertEquals(double expected, double actual, double epsilon). Simple methods like isPositive, isNegative, etc. can be used to make boolean expressions more human readable. Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc. I've used a default error constant several places. It would be nice to come up with a central location for such values. In addition to the above, has any thought gone into a set of application exceptions that will be thrown. Are we going to rely on Java core exceptions or are we going to create some application specific exceptions? As I recall J uses a MathException in the solver routines and I added a ConvergenceException. Should we expand that list or fold it into one generic application exception or do away with application exceptions all together? Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] matters of copyright
Gamma.java specifically mentioned that is was based on Numerical Recipes in C which is not available under a license compatible with the ASL. What is specifically mentioned was is based on the formulas and descriptions found in NR and it clearly states in http://www.nr.com/com/info-copyright.html that Of course, the mathematical algorithms that underly the programs are not copyrightable... 1) logGamma is derived using (6.1.3) and (6.1.5) from NR and the Paul Godfrey's paper on Lanczos coefficients found at http://my.fit.edu/~gabdo/gamma.txt. 2) regularizedGammaP is derived using (6.2.1) and (6.2.5) from NR. I also have hand-written notes on how I derived the implementation from those formulas that I would be happy to provide for your viewing. 3) ChiSquaredDistribution and GammaDistribution are based on (6.2.1) and (6.2.18) from NR and the fact that ChiSquared(v) ~ Gamma(v/2, 2) which can be found in Casella and Berger. The t-distribution patch has several modifications to the comments of all the mentioned classes with links to all the cited material. Also, the t patch makes use of other mathematical algorithms found in NR. A) The continued fraction class is based on (5.2.1) and the modified Lentz algorithm defined in that same section and accredited to Thompson and Barnett. B) logGamma uses the cf class and (6.2.7) from NR to provide better convergence than the series. C) logBeta uses (6.1.9) from NR. D) regularizedBeta is derived using the cf class and (6.4.1), (6.4.5) and (6.4.6) from NR. E) TDistribution is based on (6.4.9) from NR. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
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 implementation. What exactly do you mean by only inverse quadratic interpolation? Brent's method requires a bracketed root as a start. The primary method for shrinking the bracket is inverse quadratic interpolation. This means you get three points x0,y0 x1,y1 x2,y2 x0x2x1 and interpolate a parabola x=a*y^2+b*y+c and because your goal is to find the x for y=0, your next estimate for the root is c (set y=0). The convergence is of the order 1.8, which is better than the secant method (~1.4 if non bracketing, 1..1.2 on average if bracketing). The full Brent algorithm measures how well the interval shrinks, and resorts to bisection if progress is too slow. I didn't implement this because I forgot to take the book with me and had only a hazy memory of the control parameters. All in all the algorithm combines near-guaranteed convergence (occasionally problems might falsely detected as ill-conditioned) with near Newton-speed. What do you have in mind re: plausibility? If the interval to search is (x0,x1), then absAccuracy should be of the order of max(abs(x0),abs(x1))*relAccuracy. Achievable relative accuracy depends on underlying hardware, although nowadays basically everyone uses IEEE 754 (means, uh, 52 bit for double? Damn, have to look it up!). Both relative and absolute accuracy of function evaluation are also important, which is the reason to let the user override defaults. This means if relAcc is given then reject absAcc if max(abs(x0),abs(x1))*relAcc+c*absAcc == max(abs(x0),abs(x1))*relAcc for some predermined constant c in 0.2..1. I guess I like your rootfinding framework better than Brent's (Here I mean Brent Worden, the famous commons-math contributor, not the numerical analyst). I suggest that we agree to use your interfaces and UnivariateRealSolverImpl base,include Brent's bisection implementation strategy and modify his CDF inversion to use the new rootfinding framework. No argument against :-) I took special care for the JavaDocs, which seems to pay off... 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 user needs the n-th derivate, they just call the getDerivate() method n times, once on the original function and once on each of the returned functions. That way, common-math supports creating whatever degree derivate a method might need without ever having to change the framework. We provide the maximum amout of derivate creation support to the user while providing us with the minimual amount of maintenance. I do have a few small questions/comments on the framework: 1. Having solve() *require* brackets makes it impossible (or at least, un-natural) to add Newton's method or any other method that just starts with one initial value. Why? Start with -400,+40 or so. The algorithm is not *required* to start with a bracket, just with an interval. Individual solver implementations should document whether they require a bracket. Apart from this, there is always the possiblity to add another method. Why not allow the user to supply any number of initial values and design the solvers to compensate as best they can when not enough values are provided. Each algorithm has criteria about the initial values that must be met before root finding can be attempted. If the user provided initial values do not satisfy the criteria, the solver should first attempt to morph the initial values into a set of values that do satisfy the criteria. If this can not be accomplish, then the solver would raise an exception. This would take away some of the user's responsibility of knowing how these algorithms actually work and place it on us to create more robust components. 2. I am curious as to why the result property is there. How exactly do we expect clients to make use of this? The client can ask for the last result as long as no further attempt to solve for another root was made. I found this handy. I don't insist on keeping it. 3. What were you thinking about putting into the base solve() implementation as diagnostics? Do you mean things like checking to make sure the bracket is good?\ No, just adding a message indicating that an unimplemented method was called. Some frameworks don't display the type of the exception to the user and rely on the message. 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
Re: [math] Priority
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 with what Phil suggested and let the committer get caught up with all the patches, create the patch for your stuff and commit it then. thanks, Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Priority
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 implementation (which is trivial) and submit it. I would appreciate input on what a nice Java interface would look like for rootfinding, initally assuming that the function has a derivative, but ideally extensible to support strategies that do not require differentiability. 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. The relevant types are org.apache.jakarta.commons.math.RootFinding and org.apache.jakarta.commons.math.Function and there it's utilized in org.apache.jakarta.commons.math.stat.distribution.AbstractContinuousDistribu tion. Let me know what you think. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
