[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: [all] Math needs a user email list.
Has anyone given any thought about using resources outside Apache for these mathematical discussions? There are well established communities that discuss math, stats, numerical analysis and the like via USENET newsgroups. As a start, would it be beneficial for the [math] committers and contributors to spend time on those lists discussing issues, promoting [math], and building a user base? Just a thought. Mark mentioned we have a couple people posting on the users list. Has anyone asked them how difficult it is to use and filter the mailing list? Do they see the multi-topic list as a burden? I would suggest that your argument is more for Apache Math than for a new mailing list. (Note Apache Math, not Jakarta Math) I was originally opposed to something like this, but I do see some benefit to establishing a TLP for math. I still would like to get a stake in the ground with a release before making such a move. For me, [math] goes beyond the role of a simple library of common code. Instead it presents a wealth of detailed mathematical code. The user of the library needs some mathematical knowledge to get the best from the library. Related to this is that the developers and advisors will be drawn from a different (less java/programmer centric position). Agreed. That's why I brought up the newsgroups. On those there are already a host of great minds that we could collaborate with. No need to 'recruit' people to join our community. 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: [math] Ready for 1.0 RC?
On Mon, 26 Jul 2004 10:09:26 -0400, [EMAIL PROTECTED] wrote: Quoting Phil Steitz [EMAIL PROTECTED]: I am tempted to make one more API change; but am ambivalent about it: Currently the API for (non-paired) TTests uses a boolean flag to indicate whether or not the test is being performed under the hypothesis of equal subpopulation variances (homoscedastic test). Recently, [lang] added a development guideline to avoid boolean flags in APIs. I thought about splitting the homoscedastic tests out (as I did the paired tests); but decided not to (partly because of the long name and proliferation of methods). Does anyone feel strongly that this should be changed? Why avoid returning boolean flags? They are as much part of the Java API as anything else? I whish I had my usuall mail application, I'd search and review the discussion. Can you post briefly why [lang] decided this? I'm not convinced yet that its a necessity, the API can be changed in future versions. -Mark Returning booleans is not the issue. It's the passing of boolean arguments to handle control flow inside methods. [lang] decided against boolean arguments in favor of two methods. One for each of the control paths. I for one, would prefer this same approach of dropping the boolean argument and replace it with sepearate methods. Do I feel strongly about this, as Phils asks? No, as Marks suggests, these methods could be added later. Brent Worden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][Resources] build file is broken
There was a bug in the ant plugin and the fix was checked in a few days ago. The latest jelly script used to generate the build file can be found at http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin-resources/templates/build.jelly?rev=1.17view=auto On Thu, 8 Jul 2004 07:04:15 -0400, James Mitchell wrote: I noticed that as it was committed yesterday. Craig, did you mean to check that in as is? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 08, 2004 6:37 AM Subject: [GUMP][Resources] build file is broken Hi, the generated build file contains absolute paths pointing to Craig's home dir somewhere. Could anybody please fix it? This is the second time that a Maven generated build file looked wrong in a week. Is the plugin broken that generates them in the latest Maven or are people using an older and broken version? Stefan - 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] ComplexFormat changes
On Fri, 28 May 2004 10:43:39 -0400 (EDT), Tim O'Brien wrote: I'm sorry for the delayed response (I'm on the road this week), I looked at the patch and I agree with your implementation. +1 I had looked at this but had thrown my hands in the air in resignaion, thanks for stepping up to the plate. - Tim O'Brien [EMAIL PROTECTED] (847) 863-7045 Thanks. I'll go ahead then and commit my changes along with updating the user's guide and closing the issue. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] ComplexFormat changes
Has anyone read my latest comment regarding the ComplexFormat issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29000? I never saw a message come across the mailing list. Anyway, I was waiting for some feedback before I proceeded. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] request for comments on refactoring
[2004-05-19 11:30] Emmanuel Bourg said: | Brent Verner wrote: | | After looking at [vfs], I'm not sure which parts of it would be | Yes the idea is to use [vfs] to retrieve the configuration file, not to | parse it. right on. forthcoming implementation will use vfs as the default when no other specific handler is available. brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] request for comments on refactoring
[2004-05-18 12:35] Emmanuel Bourg said: | Brent Verner wrote: | | org.apache.commons.configuration.event | ConfigurationChangedListener - receives notification when a | Configuration has changed | ConfigurationChangedEvent - sent by a ConfigurationProvider | when its Configuration (or storage) has been modified. | In my config system, I have a FileModificationMonitor | subsystem (probaby to be renamed to ResourceModificationMonitor | and contributed to a suitable jakarta project) that checks | files for modification and sends a FileModifiedEvent to | a listener. RE: naming of non-std properties file: Yes. The .properties name implies adherence to the format used by the j.u.Properties class. Maybe .xprop(ertie)s would be best for the custom-parsed properties files. | There is a patch in Bugzilla to add support for reloadable | configurations (see | http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25661) but no work has | been done on notification yet. How far should we go for notifications ? | Should we just tell the configuration has changed, or should we | enumerate the modified keys ? Maybe there is a way to leverage the | [event] component here. Good to see the reloadable configuration is on the horizon. heh. I started started with a PersistentConfiguration class, too :-), but I drifted away as I refactored further... the CURL class (and the delegated Handler and ConfigurationProvider classes) made it look rather redundant in my approach considering that the configuration having a (symbolic) location implied some external storage. I wasn't aware of the sandbox-event bits. I may have found a home (or a replacement) for my FileModificationMonitor :-) I've not found need to know about individual modified keys, but then my whole configuration system has always been file-based (and only modified via the actual file, not the application code). In my view of things, the ConfigurationChangedEvent could be made smart enough to accomodate either behaviour, and allow the Listener(s) to respond as needed. Having said that our event classes might (need to) be too specific to use much of what is in what I'd assume to be the generic code in sandbox-event. One thing I have learned the hard way :-\, is that a transactional reload() method is required to prevent breakage when the modified config file is unparseable (i.e., a busted xml document). Instead of changing any of the active configuration when an attempt is made to reload an unparseable configuration file, I've found it best to fire the ConfigurationChangedEvent with a payload that lets the app react to the failed reload (most often logging a message, but in some cases I've actually had it send an email...) Thanks for your comments. I'll be more than glad to help in getting the reload bits done if you need it in hopes that it will make it easier to merge my config system into commons-config. cheers. brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Accessing from EL script
[2004-05-18 08:43] Mark R. Diggory said:
| To extend the subject of refactoring. I want to be able to access
| Configuration objects from EL references in JSP 2.0.
|
| ${sessionScope.config.foo.bar}
I do something similar _with_ properties configuration. The syntax
I use is
${sessionScope.config['some.config.key']}
after doing
session.setAttribute(config,someMap);
I'm not sure it is worth the effort to work around the ['...']
syntax requirement/limitation, since the key/value configuration
would have to be copied into something that EL can address
directly (most simply a Map of Map [[of Map ] ...])
cheers.
brent
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Accessing from EL script
[2004-05-18 09:20] Mark R. Diggory said:
| Brent Verner wrote:
|
| [2004-05-18 08:43] Mark R. Diggory said:
| | To extend the subject of refactoring. I want to be able to access
| | Configuration objects from EL references in JSP 2.0.
| |
| | ${sessionScope.config.foo.bar}
|
| I do something similar _with_ properties configuration. The syntax
| I use is
|
| ${sessionScope.config['some.config.key']}
|
| after doing
|
| session.setAttribute(config,someMap);
|
| I'm not sure it is worth the effort to work around the ['...']
| syntax requirement/limitation, since the key/value configuration
| would have to be copied into something that EL can address
| directly (most simply a Map of Map [[of Map ] ...])
|
| cheers.
| brent
|
|
| Yes, but maintaining a generic Map interface on the objects in the
| configuration hierarchy would probably be very beneficial anywhere that
| this similar approach of automation/reflection occurs. Would it not? It
| probably would make for a simple backwards compatible refactoring.
Yeah, that makes sense. Here goes a sample impl. that looks like
it'd do what you want.
cheers
b
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
import java.util.StringTokenizer;
public class x {
public void insert(Map m, String key, String value){
// XXX: will not account for non-separator '.' such as a key that looks like
some.key.adn[something.that.ya.don't.want.nested].whatever.else
Map rv = null;
int dp = key.indexOf(.);
String rest = null;
String first = key;
if( dp 0 ){
first = key.substring(0,dp);
rest = key.substring(dp + 1);
}
rv = (Map)m.get(first);
if( rv == null ){
rv = new HashMap();
m.put(first,rv);
}
if( rest != null ){
insert(rv,rest,value);
}
else{
rv.put(first,value);
}
}
public Map blowItOut(Map m){
Map rv = new HashMap();
for( Iterator it = m.keySet().iterator(); it.hasNext(); ){
String k = (String)it.next();
String v = (String)m.get(k);
insert(rv,k,v);
}
return rv;
}
public void go(){
Map x = new HashMap();
Map top = null;
x.put(a.b.c.d,abcd);
x.put(e.f.g,efgh);
x.put(h.i.j.k.l.m.n.o.p,hijklmnop);
x.put(q.r.s,qrs);
x.put(t.u.v,tuv);
x.put(w.x.y.and.z,wxyandz);
top = blowItOut(x);
System.out.println(x);
System.out.println(top);
}
public static void main(String[] args) throws Exception {
x y = new x();
y.go();
}
}
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] request for comments on refactoring
[2004-05-18 17:23] Emmanuel Bourg said:
| Brent Verner wrote:
|
| CURL - entry point for loading configurations. basically,
| a CURL is a primitive URL-like object takes a
| Configuration URL, i.e.,
| file:/path/to/file.${EXTENSION}
| res:/path/to/file.${EXTENSION}
| jdbc:${JDBC_URL} [1]
| jndi:${JNDI_URL} [1]
| and instantiates w handler to actually manage the
| requested configuration. I _think_ I'd like for
| UndefinedHandlerException - thrown when CURL handler is not found
| ??? [other bits from commons-configuration that should be here]
|
| And what about delegating the configuration access job to [vfs] instead
| ? [configuration] + [vfs] looks like a powerful combination.
After looking at [vfs], I'm not sure which parts of it would be
used to implement the key/value nature of a Configuration; maybe
only the setAttribute/getAttribute bits?
In any case, I'm gonna finish my originally planned refactoring
and then we can discuss what else should be refactored before
calling this round of refactoring complete. We can always decide
to refactor the ConfigurationProvider impls to use [vfs] at a later
date if there appears to be a positive return on the effort.
b
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[math] license issue
I believe we should discuss what might be a copyright infringement issue with the two normal cdf algorithms. NormalCDFPreciseAlgorithm cites a couple sources for its implementation: 1. R which is protected by GPL 2. TOMS 715 which is protected by ACM's CALGO license, http://www.acm.org/calgo/copyright.htm NormalCDFFastAlgorithm cites Applied Statistics as its source. AS is copyrighted by The Royal Statistical Society and the only thing I could find about its licensing is a little blurb at http://lib.stat.cmu.edu/apstat/ stating The Royal Statistical Society holds the copyright to these routines, but has given its permission for their distribution provided that no fee is charged. I ask that everyone concerned to familiarize themselves with these two implementations and citations. Then, we should decide on a course of action regarding these two classes. Prior to that, some more investigation might be necessary for the RSS license terms as the above quoted, statement is a little open ended. Brent Worden http://www.brent.worden.org/ - 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: [math] Some changes to Polynomial
On Tue, 30 Mar 2004 21:29:42 -0700, Phil Steitz wrote:
0. To help debug the SplineInterpolater (PR #28019 et al), I need to
expose the coefficients in o.a.c.m.analysis.Polynomial as a
read-only
property (returning an array copy). Any objections to adding this?
1. Add protected static double evaluate(double[] coefficients,
double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
+1
2. Add protected static double[] differentiate(double[] coefficients)
to
return the coefficients of the derivative of the polynomial with
coefficients equal to the actual parameter. Then change
firstDerivative(x) to just return
evaluate(differentiate(coefficients), x). Similar for
secondDerivative.
I could adapt Horner for the derivatives, but that seems messy to me
and
the slight memory cost to create the temp arrays seems worth it.
+1 on the differntiate method.
Are the firstDerivate and secondDerivative methods needed anymore with
the addition of your derivative method below? I would favor removing
the prior two methods if possible.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
Counter thoughts?
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: [math] cummulative vs cumulative
On Tue, 17 Feb 2004 22:22:23 +, robert burrell donkin wrote: math has over a hundred places where the word 'cummulative'. the OED spelling is cumulative. (thanks to Scott Duchin for highlighting this.) - robert Since I caused the problem, I'll fix this within a day or two. Thanks all, Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] commons-build directory now created (was Re: [vote] Separate Directory for Commons Project files)
On Tue, 10 Feb 2004 15:46:21 -0500, Mark R. Diggory wrote:
I'm having some difficulty with this in
/jakarta-commons/commons-build/maven.xml
specifically, I can seem to change the relative location of the
*/project.xml files from the base to ../*/project.xml. Any tips
here
would be great.
For example:
goal name=build
reactor:execute
basedir=${basedir}
includes=../*/project.xml
excludes=../commons-build/project.xml
goals=clean,jar:install
banner=Building
ignoreFailures=true
/
Try changing to:
reactor:execute
basedir=${basedir}/..
includes=*/project.xml
excludes=commons-build/project.xml
goals=clean,jar:install
banner=Building
ignoreFailures=true
/
Brent Worden
http://www.brent.worden.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Project consistency (was Re: [math] Re: Getting started questions)
On Feb 3, 2004, at 9:43 AM, Mark R. Diggory wrote: Brent Redeker wrote: On Feb 3, 2004, at 6:54 AM, Mark R. Diggory wrote: Here,here! I recommend using the maven generated, ant build.xml over the maven project.xml for developer building and testing. This then requires no dependencies on parent project.xml and it runs independently in just about any IDE. I reserve my own usage of Maven more for building site/releases, in which case you do need the dependency on the parent project.xml. I think this is a good suggestion. While I was setting myself up to be able to read/compile the sources, I really had little need to use Maven - build.xml is enough to compile and test the math project (and I assume Maven uses this as part of the process in creating a jar). Still, from what I can see, Maven might have uses for things other than just creating the web site and release builds. It downloads correct versions of all dependency jars, saving a little bit of work. Also, I imagine that if somebody makes documentation changes, they would need to do a 'maven site:generate' to see what the changes actually will look like. Yes, this is correct, But, at least in the math xdocs, I've provided an xsl stylesheet that mimics the xdoc transform so that you can loosely see what the contents will look like when generated (or at least verify that the xml file is valid. Try looking at any of the math/xdocs in Mozilla or I.E. you should see what I mean then. Hmmm... learn something new every day, I guess. I hadn't tried looking at the xdocs in a browser yet. The build.xml file in math is actually generated by calling maven ant which creates the build.xml (with the same dependencies as would ahve been resolved by maven itself. Maven doesn't actually use this build.xml file after this point though. So Mavne and build.xml will both generate approvximately the same jar contents, but any customization to the maven jar goals (via pre/postGoals in the maven.xml) will result in contents being different in the long run. In light of this, would it be useful for developers to be using Maven as well - in case an updated project.xml generates a changed build.xml? Or is the build.xml file always updated in CVS if the project.xml file is? (In other words, would a developer ever _need_ to run Maven to have the latest Ant build file, or is the latest build.xml in CVS always current with project.xml?) But for people who want to use Maven (for some reason or other), there could be instructions that say exactly which files/directories need to be checked out from jakarta-commons in addition to the jakarta-commons/math module. Yes, sensible. Ultimately I wish that the gloabal project contents were not housed in the jakarta-commons root directory, but in another subproject directory, then the two projects could be checked out in the same directory (eclipse workspace for instance) and easily built without having to get all the other commons projects. This would be something to bring up to everyone on the developers list. Then all project.xml would do something like extend../site/project.xml/extend All that wold be required to checkout and build any project would be: cvs checkout site cvs checkout math This would also keep all the site dependencies well organized would it not? That's a great idea; it makes complete sense to me. This would still preserve consistency among Commons projects, while making the necessary steps to check out a single sub-project a little more concise. Probably a much better idea in the long run than just maintaining a special project.xml file without the parent directory dependencies. Brent Redeker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Getting started questions
Hi,
Yesterday, I had contacted the mailing lists saying I was interested in
helping out with the Commons Math project. I received a helpful
response from Mark Diggory. However, I now have some quick questions.
(Please forgive me if the answer is already somewhere obvious.)
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors -
all related to package declarations or finding classes. Does anybody
know how to turn off these errors? Or better yet, does anybody know how
to get Eclipse to not assume that the src/{ experimental | java |
test}/ directories should be part of the package?
Also, how does one set up a project to build with Maven? I have Maven
installed, but I only checked out the Commons Math code from CVS. The
project.xml file appears to want a project.xml file in the parent
directory, so I am assuming that file is part of Jakarta Commons in
general. So what additional modules should I be checking out? All of
Commons? Is there a way to just check out the general stuff and the
Commons Math stuff, without checking out all of the other projects? (I
am kind of new to CVS as well, so maybe this is an ignorant
question...)
Thanks for any help you guys can provide!
Brent Redeker
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting started questions
Thank you very much for that answer, Michael. I hadn't tried that,
because I didn't know if that would mess anything else up
I also realized I forgot the [math] prefix on my original email - sorry
about that, everyone.
On Jan 31, 2004, at 12:56 PM, Michael Gloegl wrote:
Hi,
I love Eclipse, which also seems to be the preferred IDE for the
project. I already figured out how to check out the CVS HEAD as a new
Eclipse project. I also disabled the project's standard build
configuration, and switched to using the Math build.xml file with Ant
inside Eclipse. However, Eclipse still flags many things as errors -
all related to package declarations or finding classes. Does anybody
know how to turn off these errors? Or better yet, does anybody know
how to get Eclipse to not assume that the src/{ experimental | java |
test}/ directories should be part of the package?
You can configure this directories as source directory by
rightclicking on your project and going to Properties-Build
Path-Source-Add Folder and then add all the folders containing
project sources.
-
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: Getting started questions
On Jan 31, 2004, at 2:43 PM, Phil Steitz wrote: Brent Redeker wrote: Hi, Yesterday, I had contacted the mailing lists saying I was interested in helping out with the Commons Math project. I received a helpful response from Mark Diggory. However, I now have some quick questions. (Please forgive me if the answer is already somewhere obvious.) I love Eclipse, which also seems to be the preferred IDE for the project. There is no dependency on Eclipse. You are correct - but I already use it and it seems to be what several others are using. So it just seemed to be a logical choice. I already figured out how to check out the CVS HEAD as a new Eclipse project. I also disabled the project's standard build configuration, and switched to using the Math build.xml file with Ant inside Eclipse. However, Eclipse still flags many things as errors - all related to package declarations or finding classes. Does anybody know how to turn off these errors? Most likely what Eclipse is complaining about is missing external dependencies. I am not an Eclipse expert (actually just switched over from NetBeans a few weeks ago), but what I do is use Project Properties - Java Build Path - Libraries - Add External Jars to add the jars including the missing class definitions. I symlink the .maven/repository so the Eclipse directory browser can see the jars and just link directly to the jars in the local maven repo (once you get the maven build working, they will be there). The dependencies are enumerated in project.xml. I don't know if this is the best way to do it but it works4me. Actually, my problem was that I was using a default Eclipse project, and the source directory was just set to the project directory. But inside that was the src/ directory, then java/ (or experimental or test), and THEN the actual Java package directory hierarchy. This made Eclipse think the declared packages were at odds with the actual directory structure. Michael Gloegl answered this in an earlier reply (when I mistakenly omitted the [math] from my subject line) - I just had to explicitly define the source directories for Eclipse. As to your suggestion of the Add External Jars, so far I had not run into problems, since Ant was automatically fetching the necessary jars for me. However, it sounds like I'm best off getting Maven working; then I'll just try your system. Also, how does one set up a project to build with Maven? I have Maven installed, but I only checked out the Commons Math code from CVS. The project.xml file appears to want a project.xml file in the parent directory, so I am assuming that file is part of Jakarta Commons in general. So what additional modules should I be checking out? All of Commons? Is there a way to just check out the general stuff and the Commons Math stuff, without checking out all of the other projects? (I am kind of new to CVS as well, so maybe this is an ignorant question...) You are correct, for math's maven build to work, you need to have jakarta-commons/project.xml and you need your math checkout to be inside the jakarta-commons directory. If you don't want to co the entire jakarta-commons module, you can just co jakarta-commons/project.xml (see the full command here: http://jakarta.apache.org/site/cvsindex.html), then cd to jakarta-commons and co math from there, or you could even just create the jakarta-commons directory manually and grab the file from http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/ project.xml. You will also need jakarta-commons/xdocs to build the web site. Ah ha! I kind of suspected I'd have to something like that. I just wasn't sure exactly what stuff I'd all actually need. Thanks for the heads-up on needing jakarta-commons/xdocs, too. I don't know how to get Eclipse to do all of this. I just use the command line and point Eclipse at the directories. Hope this helps. Phil It sure did help, Phil, thanks a lot for your time. Hope my newbie-ness isn't too exasperating. Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Straw man release plan
Hello everybody, My name is Brent Redeker, and I've had some interest in the Commons Math project since I heard of it about a month ago. I've been meaning to offer any help I can give to the project, and perhaps I can be of some assistance in preparing for a 1.0 release. If the project could use my help, and if somebody could get me started, I'd be glad to do what I can. (Unfortunately, I'll probably need some hand-holding at first, as I am unfamiliar with how Apache contributors work.) I'm actually kind of interested in the Commons Math linear package, as that seems like it needs some work yet. Although I haven't finished my degree yet, I've had a number of mathematics courses, including Linear Algebra and Numerical Analysis, so I'm sure I know enough to be of some use. Brent Redeker On Jan 30, 2004, at 8:58 AM, Phil Steitz wrote: After reviewing http://jakarta.apache.org/site/versioning.html I agree with Mark that we should be aiming for a 1.0 release of [math]. Here is a straw man plan, with lots of detail missing. 1. Complete the following code / doco tasks a. Finish the User Guide b. Finalize and execute RealMatrix solve() strategy c. Finalize and execute spline changes d. Extend certified data tests with tests against R or other sources (need to finalize what is included here) e. Fix broken links and other errors in javadoc f. Improve path and boundary value test coverage g. Finalize and implement BeanList stats 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) 3. Depending on feedback from B1, proceed either to B2... or RC1... then 1.0 final. Am I missing anything? Are there other things that we think really *must* get into 1.0? Are there things that we should omit? Mark, do you want to play the Release Manager role? If not, I am willing to do it. 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: - Multiple Linear Regression
Here's a little snippet on linear regression: http://www.mathworks.com/access/helpdesk/help/toolbox/stats/linear20.shtml#49537 The first equation is the common form (in matrix terms) of a linear model. It also defines residuals and other important points regarding multiple regression. The nice thing about linear models, is not only are they used for regression analysis, but they are the basis for ANOVA as well. So, I for one, would like to see a pure matrix based implementation for linear regression as it more likely reuseable for ANOVA. Also, we can add a facade to the matrix implementation for those whole just want to deal with double[] and double[][] structures. Much like we've done with the summary stats. Take note of the hat matrix. Some more advanced analysis like measuring the effect of an observation can be easily accomplished using the hat matrix. So, it might be worth while to incorporate caching of the hat matrix in any implementation. On Wed, 28 Jan 2004 12:46:32 -0500, Inger, Matthew wrote: by model are you referring to the LinearRegressionResults class I had mentioned? I'm also no statistical guru. I can get around where i need to, but i'm not sure what the score method and residuals method is. I'm guessing you might be referring to some of the linear regression statistics. A little clearer explantion would help. I could submit what i have, and whomever can do the commit might want to take these things into account, and possibly refactor things a bit. I'm mainly concerened (for my project) with the coefficient matrix and predictions, but decided to go the extra step of computing all the statistics that go along with it (figuring the community would have use for them). 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 24962] - [math] MathUtils.sign(NaN) returns -1 instead of NaN
In conclusion I think we came to the following public double sign(double d); +1 : d 0 0 : d = 0 -1 : d 0 public double indicator(double d); +1 : d = 0 -1 : d 0 -Mark I think I misstated the properties of an indicator function in the original thread. An indicator function returns 0 or 1, not -1 or 1. I don't know if this should impact our choice of method names or not. Maybe just good documentation is needed to prevent any confusion. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] proposal for activationStatement and passivationStatement in PoolableConnectionFactory
[2003-12-21 21:36] Dirk Verbeeck said:
| Yes this would be a nice feature, a couple of days ago there was
| somebody else requesting a similar thing on commons-user.
| A patch is very welcome.
patch attached. While cleaning this up, I realized that
activation/passivation was executed each time a pooled
connection was borrowed. This is not at all what I'd
originally intended...blush / As such, I've moved the
statement execution calls into makeObject() and destroyObject()
where the do what I want (only once :-)).
| One remark, I would stop the normal processing when an exception is
| thrown. If needed you can always handle error in a PL/SQL block or
| stored procedure.
Ok. An SQLException is thrown on error.
cheers.
Brent
P.S. I'll be slow to reply to email over the next couple of
weeks... happy holidays!
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
Index: src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java
===
RCS file:
/home/cvspublic/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java,v
retrieving revision 1.17
diff -u -r1.17 PoolableConnectionFactory.java
--- src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java 30 Nov 2003
19:01:33 - 1.17
+++ src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java 22 Dec 2003
11:33:19 -
@@ -295,9 +295,35 @@
public void setDefaultCatalog(String defaultCatalog) {
_defaultCatalog = defaultCatalog;
}
+
+/**
+ * Defines a statement to be executed immediately after Connection is created
+ * in [EMAIL PROTECTED] #makeObject}.
+ *
+ * Useful for performing additional Conection configuration such as
+ * ALTER SESSION-type statements.
+ *
+ * @param initializationStatement statement to be executed during Connection
activation
+ */
+synchronized public void setInitializationStatement(String
initializationStatement){
+_initializationStatement = initializationStatement;
+}
+
+/**
+ * Defines a statement to be executed immediately before Connection is closed
+ * in [EMAIL PROTECTED] #destroyObject}.
+ *
+ * @param destructionStatement statement to be executed during Connection
activation
+ */
+synchronized public void setDestructionStatement(String destructionStatement){
+_destructionStatement = destructionStatement;
+}
synchronized public Object makeObject() throws Exception {
Connection conn = _connFactory.createConnection();
+if( _initializationStatement != null ){
+executeStatement(conn, initializationStatement,
_initializationStatement);
+}
if(null != _stmtPoolFactory) {
KeyedObjectPool stmtpool = _stmtPoolFactory.createPool();
conn = new PoolingConnection(conn,stmtpool);
@@ -308,10 +334,28 @@
public void destroyObject(Object obj) throws Exception {
if(obj instanceof PoolableConnection) {
+if( _destructionStatement != null ){
+executeStatement((Connection)obj, destructionStatement,
_destructionStatement);
+}
((PoolableConnection)obj).reallyClose();
}
}
+protected void executeStatement(Connection conn, String type, String sql)
+throws SQLException {
+ Statement st = conn.createStatement();
+ try {
+ st.execute(sql);
+ }
+ catch( SQLException ex ){
+ throw new SQLException(type + [ + sql + ] failed: + ex.getMessage());
+ }
+ finally {
+ try { st.close(); }
+ catch( Exception ex ){ }
+ }
+}
+
public boolean validateObject(Object obj) {
if(obj instanceof Connection) {
try {
@@ -394,6 +438,8 @@
protected boolean _defaultAutoCommit = true;
protected int _defaultTransactionIsolation = UNKNOWN_TRANSACTIONISOLATION;
protected String _defaultCatalog;
+protected String _initializationStatement;
+protected String _destructionStatement;
/**
* @deprecated AbandonedConfig is now deprecated.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] proposal for activationStatement and passivationStatement in PoolableConnectionFactory
[2003-12-22 15:01] Dirk Verbeeck said: | Good start, but it will be really usefull when the new feature is | available through the BasicDataSource. (and tested with JUnit test of | course) right on. I'll update the patch to enable use via BasicDataSource. I'm not well-versed in junit testing, so I might come back requesting help/suggestions... | I have created a bugzilla issue to track this item: | http://issues.apache.org/bugzilla/show_bug.cgi?id=25696 thanks. Should I use bugzilla and/or the mailing list when sending updated patches? cheers. Brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman - 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: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003 14:22:16 -0500, Noel J. Bergman wrote: Mark, If everything were mavenized couldn't we use the multiproject plugin to ... That is a means. I don't care about the means. I only care that it exists. If someone wants to mavenize everything, fine. If people object because they want everything to require only Ant, fine. I just don't want to see one issue held hostage to the other. :-) You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) --- Noel I too would favor Maven and could definately help with the transition. 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: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003 23:26:31 -0500, Mark R. Diggory wrote: There are about 16 commits that I made after move, it shouldn't be difficult to redo these. I'll make an announcement to the group. -Mark You might try grabing the current code from commons proper and creating a patch againt the sandbox. I've never tried this; it's just a thought. 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
Different projects are going to want to update sites at different frequencies. I think we should make an attempt to achieve consistency throughout the J-C sites before attempting to create a system generate and publish every single J-C project. Different projects change at different frequencies, and we should leave the process of publishing the site to each component. +1. The good idea is to Mavenize - everything I do think it a good idea to generate the Jakarta Commons site using Maven - we would continue to use the same xdoc. +1. However, I think the issue of insuring all subprojects are listed on the main site's menu should be tackled promptly. Along with the uniformity issue, the problem of not finding all existing subprojects was a big concern. 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] interface for UnivariateRealFunction (differentiability)
The CubicSplineFunction is the only place, that I'm aware of, that truly implements these methods. Also, these method are never called anywhere in the code, save the unit tests. This includes calls through either the interface or the concrete classes. As I see it we have three choices: 1) let it as is 2) add a differentiable interface per Mike's suggestion. 3) remove the derivative methods from the interface and keep them only on CubicSplineFunction. In order of preference, I choose 2, 1, 3. On Fri, 07 Nov 2003 15:02:46 -0500, Mark R. Diggory wrote: [EMAIL PROTECTED] wrote: What is the purpose for having the firstDerivative() and secondDerivative() methods on a UnivariateRealFunction ? One of the interpolating routines use the first and second derivatives. It is a little troubling to me to have at this level (perhaps if needed a subclass such as UnivariateDifferentiableRealFunction ). This might be a good idea. When I used the solvers to evaluate the inverse cumulative distribution functions, I found the UnivariateRealFunction interface a bit cumbersome for my needs. Some methods do not neccessarily need to be exposed via an interface if they are used internally. While some UnivariateRealFunction implementations may require this capability, is it required to be in the interface? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party librarie
commons-logging: A little more investigation revels, commons-beanutils depends on commons-logging. Hence, the only way to remove commons-math's dependency on commons-logging, is to remove commons-math's dependency on commons-beanutils. So, as long as commons-math is dependent on commons-beanutils, nothing is gained, in terms of bloat, by removing the commons-logging dependency. My stance is to use commons-logging. commons-discovery: Since I added the discovery stuff I will be its advocate. One of the visions for commons-math is to create a kind of service provider API for math routines and break commons-math into two logical parts: the SPI and the default implementation. Then, commons-math would either invite other service providers (Mathematica, MatLab, S-Plus, ...) to create adaptors or we would develop them. The route we have chosen to enable the SPI is via the abstract factories. To instantiate concrete factory instances, I decided to use the features provided by commons-discovery. Prior to its injection, the concrete factories used system properties for instantiation. This is limiting in the sense only one service provider can be used per JVM and in a app server type deployment, there may be a need to have utilize many different service provides for different applications. With commons-discovery, the system property approach is still supported along with properties files and the Jar SPI specification. The later two would enable the possibility of have multiple service providers under one JVM. Thus, using commons-disovery nothing is lost over the original implementation and some nice flexibility is gained. My stance is to use commons-discovery. commons-collections: commons-lang: commons-beanutils: No one seems to be objecting to these much so won't bother defending our reasons for using them. Here's a thought. One thing we might do to limit the proliferation of jars is to create a jar containing commons-math as all of its dependencies. Maven has an uberjar plugin that might be the ticket to creating such a jar. There ares risk with deploying such a jar as there might be version conflicts if other versions of the dependencies are deployed separately. I'm not a big advocate of this strategy (I've had to many struggles working with products that came bundled with old version of xerces) but it might be to quell some of the dependency backlash. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Release Commons Primitives 1.0
Great! another dependency for commons-math. :) On Wed, 5 Nov 2003 15:10:16 -0800 (PST), Rodney Waldhoff wrote: With 4 binding +1s and no binding -1s, this vote has passed. I'll initiate the release process. binding +1s: Rod, Matthew, Stephen, Phil binding +0s: Greg, Yoav binding -0s: none binding -1s: none - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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]
