cvs commit: jakarta-commons/docs components.html
mbecke 2003/06/03 05:51:08 Modified:docs components.html Log: Updated for HttpClient 2.0 Beta 1 Revision ChangesPath 1.107 +1 -1 jakarta-commons/docs/components.html Index: components.html === RCS file: /home/cvs/jakarta-commons/docs/components.html,v retrieving revision 1.106 retrieving revision 1.107 diff -u -r1.106 -r1.107 --- components.html 29 May 2003 21:56:41 - 1.106 +++ components.html 3 Jun 2003 12:51:06 - 1.107 @@ -481,7 +481,7 @@ br / Releases: ul - lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0/;Release 2.0 Alpha 1/a - 5 October 2001/li + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0/;Release 2.0 Beta 1/a - 25 May 2003/li /ul /dd !-- /HttpClient -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Re: [Docs] Component Lists
I made the changes and updated the site for HttpClient. I left out the jxpath changes but would be happy to add them if others would like. Mike On Tuesday, June 3, 2003, at 05:23 AM, Tetsuya Kitahata wrote: On Sun, 1 Jun 2003 12:45:19 -0400 (Subject: Re: [Docs] Component Lists) Michael Becke [EMAIL PROTECTED] wrote: As a commons committer do I have access to jakarta-commons/components.html? If so I will change this now. I am not sure whether you have right to access to jakarta-commons/xdocs/components.xml ... But, I made a patch for it and attached in zip format. (components.xml.zip// contains components.xml.txt) This patch is for the notice of the release of HttpClient beta1 and JXPath1.1 Also, I think (different from the commons-httpclient's site, it seems automatically be publishing by maven) if you change to *.xml, then you have to build and create new *.html and apply to both, as Martin Cooper said .. I guess. Sincerely, Mike On Sunday, June 1, 2003, at 12:34 PM, Tetsuya Kitahata wrote: Thanks for the information, Mike. I've forgotten to subscribe the httpclient mailing list. It had been separated from this mailing list!! When are you (or anyone) planning to announce in jakarta-site (index,news) and commons-components-list (jakarta-commons/components.html)?? -- On Sun, 1 Jun 2003 11:19:23 -0400 Michael Becke [EMAIL PROTECTED] wrote: HttpClient is now at 2.0 Beta 1. An announcement has not gone out yet, but the distribution has been uploaded. Mike -- P.S. Me Jakarta Commons (as of 31th May, 2003) Sorry, $AsOfDate =~ s/th/st/ ;-) - Tetsuya Kitahata -- Terra-International, Inc. 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] - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ components.xml.zip--- -- 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] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
Phil Steitz wrote: Phil Steitz wrote: [EMAIL PROTECTED] wrote: Phil Steitz wrote: Since xbar = sum/n, the change has no impact on the which sums are computed or squared. Instead of (sum/n)*(sum/n)*n your change just computes sum**2/n. The difference is that you are a) eliminating one division by n and one multiplication by n (no doubt a good thing) and b) replacing direct multiplication with pow(-,2). The second of these used to be discouraged, but I doubt it makes any difference with modern compilers. I would suggest collapsing the denominators and doing just one cast -- i.e., use (1) variance = sumsq - sum * (sum/(double) (n * (n - 1))) If (2) variance = sumsq - (sum * sum)/(double) (n * (n - 1))) or (3) variance = sumsq - Math.pow(sum,2)/(double) (n * (n - 1))) give better accuracy, use one of them; but I would favor (1) since it will be able to handle larger positive sums. I would also recommend forcing getVariance() to return 0 if the result is negative (which can happen in the right circumstances for any of these formulas). Phil collapsing is definitely good, but I'm not sure about these equations, from my experience, approaching (2) would look something more like variance = (((double)n)*sumsq - (sum * sum)) / (double) (n * (n - 1)); see (5) in http://mathworld.wolfram.com/k-Statistic.html That formula is the formula for the 2nd k-statistic, which is *not* the same as the sample variance. The standard formula for the sample variance is presented in equation (3) here: http://mathworld.wolfram.com/SampleVariance.html or in any elementary statistics text. Formulas (1)-(3) above (and the current implementation) are all equivalent to the standard defintion. What you have above is not. The relation between the variance and the second k-statistic is presented in (9) on http://mathworld.wolfram.com/k-Statistic.html I just realized that I misread Wolfram's definitions. What he is defining as the 2nd k-statistic is the correct formula for the sample variance. I am also missing some parenthesis above. Your formula is correct. Sorry. Phil No problem, I just wanted to make sure we're all on the same page, there are always many times I am wrong too. Thanks for double checking, -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
--- [EMAIL PROTECTED] wrote: Phil Steitz wrote: Phil Steitz wrote: [EMAIL PROTECTED] wrote: Phil Steitz wrote: Since xbar = sum/n, the change has no impact on the which sums are computed or squared. Instead of (sum/n)*(sum/n)*n your change just computes sum**2/n. The difference is that you are a) eliminating one division by n and one multiplication by n (no doubt a good thing) and b) replacing direct multiplication with pow(-,2). The second of these used to be discouraged, but I doubt it makes any difference with modern compilers. I would suggest collapsing the denominators and doing just one cast -- i.e., use (1) variance = sumsq - sum * (sum/(double) (n * (n - 1))) If (2) variance = sumsq - (sum * sum)/(double) (n * (n - 1))) or (3) variance = sumsq - Math.pow(sum,2)/(double) (n * (n - 1))) give better accuracy, use one of them; but I would favor (1) since it will be able to handle larger positive sums. I would also recommend forcing getVariance() to return 0 if the result is negative (which can happen in the right circumstances for any of these formulas). Phil collapsing is definitely good, but I'm not sure about these equations, from my experience, approaching (2) would look something more like variance = (((double)n)*sumsq - (sum * sum)) / (double) (n * (n - 1)); see (5) in http://mathworld.wolfram.com/k-Statistic.html That formula is the formula for the 2nd k-statistic, which is *not* the same as the sample variance. The standard formula for the sample variance is presented in equation (3) here: http://mathworld.wolfram.com/SampleVariance.html or in any elementary statistics text. Formulas (1)-(3) above (and the current implementation) are all equivalent to the standard defintion. What you have above is not. The relation between the variance and the second k-statistic is presented in (9) on http://mathworld.wolfram.com/k-Statistic.html I just realized that I misread Wolfram's definitions. What he is defining as the 2nd k-statistic is the correct formula for the sample variance. I am also missing some parenthesis above. Your formula is correct. Sorry. Phil No problem, I just wanted to make sure we're all on the same page, there are always many times I am wrong too. Thanks for double checking, -Mark Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. Al Date: Mon, 26 May 2003 18:28:45 -0700 (PDT) From: Al Chou [EMAIL PROTECTED] Subject: [math] rolling formulas for statistics (was RE: Greetings from a newcomer (b --- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: --- Phil Steitz [EMAIL PROTECTED] wrote: Brent Worden wrote: Mark R. Diggory wrote: There are easy formulas for skewness and kurtosis based on the central moments which could be used for the stored, univariate implementations: http://mathworld.wolfram.com/Skewness.html http://mathworld.wolfram.com/Kurtosis.html As for the rolling implementations, there might be some more research involved before using this method because of their memoryless property. But for starters, the sum and sumsq can easily be replaced with there central moment counterparts, mean and variance. There are formulas that update those metrics when a new value is added. Weisberg's Applied Linear Regression outlines two such updating formulas for mean and sum of squares which are numerically superior to direct computation and the raw moment methods. Why exactly, are these numerically superior? For what class of examples? Looks like lots more operations to me, especially in the UnivariateImpl case where the mean, variance are computed only when demanded -- i.e., there is no requirement to generate mean[0], mean[1],...etc. I understand that adding (or better, swapping) operations can sometimes add precision, but I am having a hard time seeing exactly where the benefit is in this case, especially given the amount of additional computation required. _Numerical Recipes in C_, 2nd ed. p. 613 (http://lib-www.lanl.gov/numerical/bookcpdf/c14-1.pdf) explains: Many textbooks use the binomial theorem to expand out the definitions [of statistical quantities] into sums of various powers of the data, ...[,] but this can magnify the roundoff error by a large factor... . A clever way to minimize roundoff error, especially for large samples, is to use the corrected two-pass algorithm [1]: First calculate x[bar, the mean of x], then calculate [formula for variance in terms of x - xbar.] ... [1] Algorithms for Computing the Sample Variance: Analysis and Recommendations, Chan, T.F., Golub, G.H., and LeVeque, R.J. 1983, American Statistician, vol. 37, pp. 242?247. Thany you, Al! I am convinced by this for that at least for the variance and higher
cvs commit: jakarta-commons-sandbox/configuration project.xml
epugh 2003/06/03 07:15:23 Modified:configuration project.xml Log: Pointed out that marking a release 1.0 for a sandbox component was premature. Cutting a new version for ibiblio based on prior version numbers. Revision ChangesPath 1.25 +2 -2 jakarta-commons-sandbox/configuration/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- project.xml 2 Jun 2003 17:27:37 - 1.24 +++ project.xml 3 Jun 2003 14:15:23 - 1.25 @@ -10,7 +10,7 @@ pomVersion3/pomVersion namecommons-configuration/name idcommons-configuration/id - currentVersion1.0/currentVersion + currentVersion1.0-dev-3.20030603.101200/currentVersion organization nameApache Software Foundation/name urlhttp://jakarta.apache.org//url - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
Al Chou wrote: --- [EMAIL PROTECTED] wrote: Phil Steitz wrote: Phil Steitz wrote: [EMAIL PROTECTED] wrote: Phil Steitz wrote: Since xbar = sum/n, the change has no impact on the which sums are computed or squared. Instead of (sum/n)*(sum/n)*n your change just computes sum**2/n. The difference is that you are a) eliminating one division by n and one multiplication by n (no doubt a good thing) and b) replacing direct multiplication with pow(-,2). The second of these used to be discouraged, but I doubt it makes any difference with modern compilers. I would suggest collapsing the denominators and doing just one cast -- i.e., use (1) variance = sumsq - sum * (sum/(double) (n * (n - 1))) If (2) variance = sumsq - (sum * sum)/(double) (n * (n - 1))) or (3) variance = sumsq - Math.pow(sum,2)/(double) (n * (n - 1))) give better accuracy, use one of them; but I would favor (1) since it will be able to handle larger positive sums. I would also recommend forcing getVariance() to return 0 if the result is negative (which can happen in the right circumstances for any of these formulas). Phil collapsing is definitely good, but I'm not sure about these equations, from my experience, approaching (2) would look something more like variance = (((double)n)*sumsq - (sum * sum)) / (double) (n * (n - 1)); see (5) in http://mathworld.wolfram.com/k-Statistic.html That formula is the formula for the 2nd k-statistic, which is *not* the same as the sample variance. The standard formula for the sample variance is presented in equation (3) here: http://mathworld.wolfram.com/SampleVariance.html or in any elementary statistics text. Formulas (1)-(3) above (and the current implementation) are all equivalent to the standard defintion. What you have above is not. The relation between the variance and the second k-statistic is presented in (9) on http://mathworld.wolfram.com/k-Statistic.html I just realized that I misread Wolfram's definitions. What he is defining as the 2nd k-statistic is the correct formula for the sample variance. I am also missing some parenthesis above. Your formula is correct. Sorry. Phil No problem, I just wanted to make sure we're all on the same page, there are always many times I am wrong too. Thanks for double checking, -Mark Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. I was going to mention that. The discussion above regards the non-stored vector approach (UnivariateImpl). I submitted some patches to the stored classes (StoredUnivariate,AbstractStoreUnivariate) last weekend (adding percentiles -- http://issues.apache.org/bugzilla/show_bug.cgi?id=20377) and I was waiting for them to get committed before suggesting this change/submitting the patch. Given our recent NR entanglements, we need to make sure that if and when we apply that patch we document using the original source of the formula. Thanks for the remider. What is relevant to the UnivariateImpl computations is Brent's suggestion re: making running error corrections. Have you investigated this further? Al Date: Mon, 26 May 2003 18:28:45 -0700 (PDT) From: Al Chou [EMAIL PROTECTED] Subject: [math] rolling formulas for statistics (was RE: Greetings from a newcomer (b --- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: --- Phil Steitz [EMAIL PROTECTED] wrote: Brent Worden wrote: Mark R. Diggory wrote: There are easy formulas for skewness and kurtosis based on the central moments which could be used for the stored, univariate implementations: http://mathworld.wolfram.com/Skewness.html http://mathworld.wolfram.com/Kurtosis.html As for the rolling implementations, there might be some more research involved before using this method because of their memoryless property. But for starters, the sum and sumsq can easily be replaced with there central moment counterparts, mean and variance. There are formulas that update those metrics when a new value is added. Weisberg's Applied Linear Regression outlines two such updating formulas for mean and sum of squares which are numerically superior to direct computation and the raw moment methods. Why exactly, are these numerically superior? For what class of examples? Looks like lots more operations to me, especially in the UnivariateImpl case where the mean, variance are computed only when demanded -- i.e., there is no requirement to generate mean[0], mean[1],...etc. I understand that adding (or better, swapping) operations can sometimes add precision, but I am having a hard time seeing exactly where the benefit is in this case, especially given the amount of additional computation required. _Numerical Recipes in C_, 2nd ed. p. 613 (http://lib-www.lanl.gov/numerical/bookcpdf/c14-1.pdf) explains: Many textbooks use the binomial theorem to expand out the definitions [of statistical quantities] into sums of various powers of
DO NOT REPLY [Bug 20449] New: - Define flag for validating current page only in multipage form
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20449.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20449
Define flag for validating current page only in multipage form
Summary: Define flag for validating current page only in
multipage form
Product: Commons
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In our current application, we have about 60 jsps. The pages are set up in a
wizard-like interface. Depending on the data entered, a different path through
the pages will be taken. All data is captured in a single ActionForm, so we
are using multipage validation.
Each page is numbered, but the pages are not numbered sequentially. Depending
on the data entered, a user on page 10 may be taken to page 8 or page 12. In
the current way that the multipage validation works, if there is a required
field on page 8, but the user has been taken to page 12, it will generate an
error requiring the field on page 8.
It would be nice if there were a flag that could be set that would allow the
validate method to only validate the current page, rather than all pages less
than or equal to the current page. This would then need to be integrated into
struts to set the flag.
Here is an example of how it could be done:
public ValidatorResults validate() throws ValidatorException {
ValidatorResults results = new ValidatorResults();
Locale locale = null;
if (hResources.containsKey(LOCALE_KEY)) {
locale = (Locale) hResources.get(LOCALE_KEY);
}
hResources.put(VALIDATOR_KEY, this);
if (locale == null) {
locale = Locale.getDefault();
}
if (resources == null) {
throw new ValidatorException(Resources not defined for Validator);
}
Form form = resources.get(locale, formName);
if (form != null) {
for (Iterator i = form.getFields().iterator(); i.hasNext();) {
Field field = (Field) i.next();
/***
Check for the flag here
/
if (validateCurrentPageOnly) {
if ((field.getPage() == page)
(field.getDepends() != null)) {
validateField(field, results);
}
} else {
if ((field.getPage() = page)
(field.getDepends() != null)) {
validateField(field, results);
}
}
}
}
return results;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
Al Chou wrote: Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. Al No, we definitely should plan to include this into StoredUnivariate (and when UnivariateImpl requires storage). I've been wondering if there was a way to combine the two approaches for the rolling implementation. I think what we're beginning to see is that there are many different benefits/limitations for the different implementations of Univariate (Rolling vs. Stored). I think what we'll find is that: (1) UnivariateImpl is excellent for memory usage, with some limitations in accuracy due to roundoff error with extreme cases. (2) StoredUnivariateImpl can support more accurate algorithms that reduce roundoff error, but with the trade off of greater memory requirements. Thanks for bringing the subject up again. -Mark Date: Mon, 26 May 2003 18:28:45 -0700 (PDT) From: Al Chou [EMAIL PROTECTED] Subject: [math] rolling formulas for statistics (was RE: Greetings from a newcomer (b --- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: --- Phil Steitz [EMAIL PROTECTED] wrote: Brent Worden wrote: Mark R. Diggory wrote: There are easy formulas for skewness and kurtosis based on the central moments which could be used for the stored, univariate implementations: http://mathworld.wolfram.com/Skewness.html http://mathworld.wolfram.com/Kurtosis.html As for the rolling implementations, there might be some more research involved before using this method because of their memoryless property. But for starters, the sum and sumsq can easily be replaced with there central moment counterparts, mean and variance. There are formulas that update those metrics when a new value is added. Weisberg's Applied Linear Regression outlines two such updating formulas for mean and sum of squares which are numerically superior to direct computation and the raw moment methods. Why exactly, are these numerically superior? For what class of examples? Looks like lots more operations to me, especially in the UnivariateImpl case where the mean, variance are computed only when demanded -- i.e., there is no requirement to generate mean[0], mean[1],...etc. I understand that adding (or better, swapping) operations can sometimes add precision, but I am having a hard time seeing exactly where the benefit is in this case, especially given the amount of additional computation required. _Numerical Recipes in C_, 2nd ed. p. 613 (http://lib-www.lanl.gov/numerical/bookcpdf/c14-1.pdf) explains: Many textbooks use the binomial theorem to expand out the definitions [of statistical quantities] into sums of various powers of the data, ...[,] but this can magnify the roundoff error by a large factor... . A clever way to minimize roundoff error, especially for large samples, is to use the corrected two-pass algorithm [1]: First calculate x[bar, the mean of x], then calculate [formula for variance in terms of x - xbar.] ... [1] Algorithms for Computing the Sample Variance: Analysis and Recommendations, Chan, T.F., Golub, G.H., and LeVeque, R.J. 1983, American Statistician, vol. 37, pp. 242?247. Thany you, Al! I am convinced by this for that at least for the variance and higher order moments, whenever we actually store the values (that would include UnivariateImpl with finite window), we should use the corrected one [sic] pass formula (14.1.8) from http://lib-www.lanl.gov/numerical/bookcpdf/c14-1.pdf. It is a clever idea to explicitly correct for error in the mean. = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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]
DoubleMetaphone Implementation
Hello - I am writing to inquire if anyone has any interest in adding a Double Metaphone implementation to the Commons Codec project. To my knowlege there is not an implementation of this in your latest release, and the archive is down so I have no idea if someone else already proposed it. Double Metaphone is an enhancement to the orginal Metaphone algorithm (already included with the Codec project). It is by the author of the original Metaphone algorithm, Lawrence Philips. For his orginal article on the algorithm see http://www.cuj.com/documents/s=8038/cuj0006philips/. I needed to create an implementation in Java and was unable to find a bug-free implementation, so I created my own based from Lawrence Philips' original C++ code (available at ftp://ftp.cuj.com/pub/2000/1806/philips.zip). Since there are no reference implementations or test suites, I have done my best to make sure that my implemenation complies with other implementations available for other languages. If there is an interest in adding the Double Metaphone algorithm, I will see about donating the source (it is currently the property of my employer, but I suspect that there will be little resistance to the donation). Regards, Ben Walstrum __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] matters of copyright
--- Phil Steitz [EMAIL PROTECTED] wrote: The dodgy bit is that someone else who did the same derivation and ended up with a similar implementation (e.g. NR) might claim ownership of the algorithm itself. This is why the limitation expressed in the NR copyright statement is important. In the US, at least, one cannont copyright or patent a bare algorithm. Mathematical formulae and algorithms of a purely mathematical nature are deemed ideas. This fact alone is of course not enough to prevent somone from taking you to court, where you'd then have to prove that your software really was nothing more than a mathematical algorithm expressed in code. For a mathematical library, it would seem a relatively easy thing to prove. Of course, IANAL.
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
Phil Steitz wrote: Al Chou wrote: Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. I was going to mention that. The discussion above regards the non-stored vector approach (UnivariateImpl). I submitted some patches to the stored classes (StoredUnivariate,AbstractStoreUnivariate) last weekend (adding percentiles -- http://issues.apache.org/bugzilla/show_bug.cgi?id=20377) and I was waiting for them to get committed before suggesting this change/submitting the patch. Given our recent NR entanglements, we need to make sure that if and when we apply that patch we document using the original source of the formula. Thanks for the remider. What is relevant to the UnivariateImpl computations is Brent's suggestion re: making running error corrections. Have you investigated this further? I'll pick up this patch and apply it before any of my changes to UnivariateImpl. Thanks for redirecting my attention to it, I'm still getting used to going into bugzilla. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Phil Steitz wrote: Al Chou wrote: Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. I was going to mention that. The discussion above regards the non-stored vector approach (UnivariateImpl). I submitted some patches to the stored classes (StoredUnivariate,AbstractStoreUnivariate) last weekend (adding percentiles -- http://issues.apache.org/bugzilla/show_bug.cgi?id=20377) and I was waiting for them to get committed before suggesting this change/submitting the patch. Given our recent NR entanglements, we need to make sure that if and when we apply that patch we document using the original source of the formula. Thanks for the remider. What is relevant to the UnivariateImpl computations is Brent's suggestion re: making running error corrections. Have you investigated this further? I'll pick up this patch and apply it before any of my changes to UnivariateImpl. Thanks for redirecting my attention to it, I'm still getting used to going into bugzilla. Thanks, Mark. While you're in the neighborhood, can you also commit the patch that I submitted adding MathUtils: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20390 It occurs to me now that MathUtils, a simple utility class extending the basic computing functions in java.lang.Math would make a nice place to encapsulate our array-based mean, variance and standard deviation computations, using Al's suggested improvements. Users would likely find simple double[] |- double functions to compute means, variances, std dev, min and max directly useful and the various Univariate implementations could leverage them. Phil -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] UnivariateImpl - when sumsq ~ xbar*xbar*((double) n)
Yes, I'm working my way through all the bug patches and trying apply them in order. Hopefully this shouldn't take too long, but I'm in and out of the office today, so it might not be til this evening. -Mark Phil Steitz wrote: --- Mark R. Diggory [EMAIL PROTECTED] wrote: Phil Steitz wrote: Al Chou wrote: Uh, did we drop the idea of using the corrected two-pass algorithm for the variance in the non-rolling case? I excerpted that thread below. I was going to mention that. The discussion above regards the non-stored vector approach (UnivariateImpl). I submitted some patches to the stored classes (StoredUnivariate,AbstractStoreUnivariate) last weekend (adding percentiles -- http://issues.apache.org/bugzilla/show_bug.cgi?id=20377) and I was waiting for them to get committed before suggesting this change/submitting the patch. Given our recent NR entanglements, we need to make sure that if and when we apply that patch we document using the original source of the formula. Thanks for the remider. What is relevant to the UnivariateImpl computations is Brent's suggestion re: making running error corrections. Have you investigated this further? I'll pick up this patch and apply it before any of my changes to UnivariateImpl. Thanks for redirecting my attention to it, I'm still getting used to going into bugzilla. Thanks, Mark. While you're in the neighborhood, can you also commit the patch that I submitted adding MathUtils: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20390 It occurs to me now that MathUtils, a simple utility class extending the basic computing functions in java.lang.Math would make a nice place to encapsulate our array-based mean, variance and standard deviation computations, using Al's suggested improvements. Users would likely find simple double[] |- double functions to compute means, variances, std dev, min and max directly useful and the various Univariate implementations could leverage them. Phil -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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]
RE: [COLLECTIONS] FastHashMap performance
In your test, are you synchronizing the HashMap? FastHashMap implements
smart synchronization. It should not be compared with an unsynchronized
version of HashMap.
P.S. In fact, it might be nice to allow doing this smart synchronization
on *any* Map. i.e. alternative to Collections.synchronizeMap(Map).
Eric Pabst
Discover Financial Services
2500 Lake Park Blvd., 3N
West Valley City, UT 84120
Ph: 801.902.4636
Fax: 801.902.4123
|-+---
| | Shapira, Yoav |
| | [EMAIL PROTECTED]|
| | i.com |
| | |
| | 06/03/03 12:54 |
| | PM |
| | Please respond |
| | to Jakarta |
| | Commons |
| | Developers List|
| | |
|-+---
---|
|
|
|To: Jakarta Commons Developers List [EMAIL PROTECTED]
|
|cc:
|
|Subject: RE: [COLLECTIONS] FastHashMap performance
|
---|
Howdy,
I understand it's just a wrapper, and that the
reading cannot be any faster. I'm curious why the
writing is so much faster, even in the default (not fast)
mode of FastHashMap.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 2:36 PM
To: Jakarta Commons Developers List
Subject: Re: [COLLECTIONS] FastHashMap performance
FastHashMap can not be faster than HasMap in single thread just because
it
uses HasMap to implement mappings:
public Object get(Object key) {
if (fast) {
return (map.get(key));
} else {
synchronized (map) {
return (map.get(key));
}
}
}
/**
* Construct an empty map.
*/
public FastHashMap() {
super();
this.map = new HashMap();
}
- Original Message -
From: Shapira, Yoav [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 8:00 PM
Subject: RE: [COLLECTIONS] FastHashMap performance
Howdy,
Neither did I, but I just ran the attached benchmark and got surprising
results. I hope the attachement comes through OK: if not I'll re-post
inline. This benchmark has just one thread writing, one thread
reading,
which I expected to be the case where FastHashMap is not as efficient
as
HashMap.
The benchmark inserts 10 records in the map, then reads 1000 of
those at random. I run this 10 times for each map implemention. I'm
ignoring the first run read times as there's overhead in initializing
the Random generator.
I'm running this test on JDK 1.4.1, no special java switches, just java
MapTest on the command line, on Solaris 8.
I'm very curious to hear comments, ideas. I was expecting to have to
write another test with multiple writing threads, but if FastHashMap is
faster even for the simple case, why ever use the regular HashMap?
The results are:
[MapTest: Map class: java.util.HashMap / Insert time: 1616 / Read time:
30]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 1252 / Read time: 6]
[MapTest: Map class: java.util.HashMap / Insert time: 958 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 1203 / Read time: 2]
[MapTest: Map class: java.util.HashMap / Insert time: 820 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 988 / Read time: 2]
[MapTest: Map class: java.util.HashMap / Insert time: 781 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 1033 / Read time: 3]
[MapTest: Map class: java.util.HashMap / Insert time: 720 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 1067 / Read time: 2]
[MapTest: Map class: java.util.HashMap / Insert time: 1454 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 1267 / Read time: 2]
[MapTest: Map class: java.util.HashMap / Insert time: 1534 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 862 / Read time: 2]
[MapTest: Map class: java.util.HashMap / Insert time: 1433 / Read time:
2]
[MapTest: Map class: org.apache.commons.collections.FastHashMap /
Insert
time: 844 / Read time:
RE: [COLLECTIONS] FastHashMap performance
Howdy, I've had tests with both a normal hashmap (just new HashMap() used) and a synchronized wrapper (Collections.synchronizedMap(new HashMap()). I would expect the normal HashMap to be faster than both the FastHashMap and the synchronized HashMap. Is my expectation wrong? However, here are the results: [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1592 / Read time: 30] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1265 / Read time: 6] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 983 / Read time: 7] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1158 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1194 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 827 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 990 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1006 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 732 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 949 / Read time: 3] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1003 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1579 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 888 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1045 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 793 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1151 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 855 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 905 / Read time: 3] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1217 / Read time: 1] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1269 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1107 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1062 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1252 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 971 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1460 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1404 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1110 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1278 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1193 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1096 / Read time: 2] Yoav Shapira Millennium ChemInformatics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:58 PM To: Jakarta Commons Developers List Subject: RE: [COLLECTIONS] FastHashMap performance In your test, are you synchronizing the HashMap? FastHashMap implements smart synchronization. It should not be compared with an unsynchronized version of HashMap. P.S. In fact, it might be nice to allow doing this smart synchronization on *any* Map. i.e. alternative to Collections.synchronizeMap(Map). Eric Pabst Discover Financial Services 2500 Lake Park Blvd., 3N West Valley City, UT 84120 Ph: 801.902.4636 Fax: 801.902.4123 |-+--- | | Shapira, Yoav | | | [EMAIL PROTECTED]| | | i.com | | | | | | 06/03/03 12:54 | | | PM | | | Please respond | | | to Jakarta | | | Commons | | | Developers List| | | | |-+--- --- - ---| | | |To: Jakarta Commons Developers List commons- [EMAIL PROTECTED]| |cc: | |Subject: RE: [COLLECTIONS] FastHashMap performance | --- - ---| Howdy, I understand it's just a wrapper, and that the reading cannot be any faster. I'm curious why the writing is so much faster, even in the default (not fast) mode of FastHashMap. Yoav Shapira Millennium ChemInformatics
Re: DoubleMetaphone Implementation
Tim - I have been in contact with Lawrence Philips who has assured me that his code is in the public domain, and is therefore completely available, eliminating any legal difficulties related to the DoubleMetaphone implementation. Let me know if (and how) to proceed. Ben Ben, thanks for the contribution. We did have a DoubleMetaphone implementation available before the 1.1 release, but it was removed from the repository because of licensing questions relating to the fact that the code submitted was ported from a CPAN module covered under the Perl Artistic License. In this case, the file Dmetaph.cpp is Copyright 1998, 1999 Lawrence Philips, and there I can find no mention of what terms this code falls under. It may be wise to get the permission of the original author. I'm interested in this as I found DoubleMetaphone to be a useful algorithm. Tim __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COLLECTIONS] FastHashMap performance
I have tried to implement performance tests for maps, but it is not trivial. Try to dissable GC and JIT for performance tests. - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 9:05 PM Subject: RE: [COLLECTIONS] FastHashMap performance Howdy, I've had tests with both a normal hashmap (just new HashMap() used) and a synchronized wrapper (Collections.synchronizedMap(new HashMap()). I would expect the normal HashMap to be faster than both the FastHashMap and the synchronized HashMap. Is my expectation wrong? However, here are the results: [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1592 / Read time: 30] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1265 / Read time: 6] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 983 / Read time: 7] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1158 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1194 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 827 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 990 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1006 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 732 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 949 / Read time: 3] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1003 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1579 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 888 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1045 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 793 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1151 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 855 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 905 / Read time: 3] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1217 / Read time: 1] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1269 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1107 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1062 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1252 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 971 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1460 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1404 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1110 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1278 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1193 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1096 / Read time: 2] Yoav Shapira Millennium ChemInformatics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:58 PM To: Jakarta Commons Developers List Subject: RE: [COLLECTIONS] FastHashMap performance In your test, are you synchronizing the HashMap? FastHashMap implements smart synchronization. It should not be compared with an unsynchronized version of HashMap. P.S. In fact, it might be nice to allow doing this smart synchronization on *any* Map. i.e. alternative to Collections.synchronizeMap(Map). Eric Pabst Discover Financial Services 2500 Lake Park Blvd., 3N West Valley City, UT 84120 Ph: 801.902.4636 Fax: 801.902.4123 |-+--- | | Shapira, Yoav | | | [EMAIL PROTECTED]| | | i.com | | | | | | 06/03/03 12:54 | | | PM | | | Please respond | | | to Jakarta | | | Commons | | | Developers List| | | | |-+--- --- - ---| | | |To: Jakarta Commons Developers List commons- [EMAIL PROTECTED]| |cc: | |Subject: RE: [COLLECTIONS] FastHashMap performance |
Re: [COLLECTIONS] FastHashMap performance
BTW This class can be removed in the future, It is not recommended to use it (not thread safe, but adds synchronization overhead). - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 9:05 PM Subject: RE: [COLLECTIONS] FastHashMap performance Howdy, I've had tests with both a normal hashmap (just new HashMap() used) and a synchronized wrapper (Collections.synchronizedMap(new HashMap()). I would expect the normal HashMap to be faster than both the FastHashMap and the synchronized HashMap. Is my expectation wrong? However, here are the results: [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1592 / Read time: 30] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1265 / Read time: 6] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 983 / Read time: 7] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1158 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1194 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 827 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 990 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1006 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 732 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 949 / Read time: 3] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1003 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1579 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 888 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1045 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 793 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1151 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 855 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 905 / Read time: 3] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1217 / Read time: 1] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1269 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1107 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1062 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1252 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 971 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1460 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1404 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1110 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1278 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1193 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1096 / Read time: 2] Yoav Shapira Millennium ChemInformatics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:58 PM To: Jakarta Commons Developers List Subject: RE: [COLLECTIONS] FastHashMap performance In your test, are you synchronizing the HashMap? FastHashMap implements smart synchronization. It should not be compared with an unsynchronized version of HashMap. P.S. In fact, it might be nice to allow doing this smart synchronization on *any* Map. i.e. alternative to Collections.synchronizeMap(Map). Eric Pabst Discover Financial Services 2500 Lake Park Blvd., 3N West Valley City, UT 84120 Ph: 801.902.4636 Fax: 801.902.4123 |-+--- | | Shapira, Yoav | | | [EMAIL PROTECTED]| | | i.com | | | | | | 06/03/03 12:54 | | | PM | | | Please respond | | | to Jakarta | | | Commons | | | Developers List| | | | |-+--- --- - ---| | | |To: Jakarta Commons Developers List commons- [EMAIL PROTECTED]| |cc: | |Subject: RE: [COLLECTIONS] FastHashMap performance |
RE: [COLLECTIONS] FastHashMap performance
Howdy, Assuming I agree that GC and JIT play a role in my benchmark (which I don't without further convincing), how should I disable them? I see -XX:-DisableExplicitGC is a VM option, but it only disables explicit System.gc() calls, which I don't use anyways. I couldn't find an option to disable JIT. The heap has ample space to hold the objects in my benchmark. My results don't change if I increase -Xmx or change -Xms to match -Xmx. Yoav Shapira Millennium ChemInformatics -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 3:37 PM To: Jakarta Commons Developers List Subject: Re: [COLLECTIONS] FastHashMap performance I have tried to implement performance tests for maps, but it is not trivial. Try to dissable GC and JIT for performance tests. - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 9:05 PM Subject: RE: [COLLECTIONS] FastHashMap performance Howdy, I've had tests with both a normal hashmap (just new HashMap() used) and a synchronized wrapper (Collections.synchronizedMap(new HashMap()). I would expect the normal HashMap to be faster than both the FastHashMap and the synchronized HashMap. Is my expectation wrong? However, here are the results: [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1592 / Read time: 30] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1265 / Read time: 6] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 983 / Read time: 7] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1158 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1194 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 827 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 990 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1006 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 732 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 949 / Read time: 3] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1003 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1579 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 888 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1045 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 793 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1151 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 855 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 905 / Read time: 3] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1217 / Read time: 1] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1269 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1107 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1062 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1252 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 971 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1460 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1404 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1110 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1278 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1193 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1096 / Read time: 2] Yoav Shapira Millennium ChemInformatics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:58 PM To: Jakarta Commons Developers List Subject: RE: [COLLECTIONS] FastHashMap performance In your test, are you synchronizing the HashMap? FastHashMap implements smart synchronization. It should not be compared with an unsynchronized version of HashMap. P.S. In fact, it might be nice to allow doing this smart synchronization on *any* Map. i.e. alternative to Collections.synchronizeMap(Map). Eric Pabst Discover Financial Services 2500 Lake Park Blvd., 3N West Valley City, UT 84120 Ph: 801.902.4636 Fax: 801.902.4123 |-+--- | | Shapira, Yoav | | | [EMAIL PROTECTED]| | | i.com | |
Re: DoubleMetaphone Implementation
On Tue, 2003-06-03 at 14:07, Benjamin Walstrum wrote: I have been in contact with Lawrence Philips who has assured me that his code is in the public domain, and is therefore completely available, eliminating any legal difficulties related to the DoubleMetaphone implementation. I also wrote him a quick email, he gave me the same assurances. Submit you code to Bugzilla, and I'll make sure the patch is applied posthaste. Tim Let me know if (and how) to proceed. Ben Ben, thanks for the contribution. We did have a DoubleMetaphone implementation available before the 1.1 release, but it was removed from the repository because of licensing questions relating to the fact that the code submitted was ported from a CPAN module covered under the Perl Artistic License. In this case, the file Dmetaph.cpp is Copyright 1998, 1999 Lawrence Philips, and there I can find no mention of what terms this code falls under. It may be wise to get the permission of the original author. I'm interested in this as I found DoubleMetaphone to be a useful algorithm. Tim __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/builder ToStringBuilderTest.java
ggregory2003/06/03 13:15:33
Modified:lang/src/test/org/apache/commons/lang/builder
ToStringBuilderTest.java
Log:
Refactor code in ToStringBuilder.reflectionToString(...) into a new subclass called
ReflectionToStringBuilder.
All of the ToStringBuilder.reflectionToString(...) forward their calls to equivalent
methods in ReflectionToStringBuilde.
ReflectionToStringBuilder can be subclassed to provide Field or value filtering.
Since the unit tests exercis ToStringBuilder.reflectionToString(...) which then
forwards those calls to ReflectionToStringBuilder, and ReflectionToStringBuilder does
not provide new features (yet), there are no new unit test cases (yet).
Revision ChangesPath
1.8 +7 -3
jakarta-commons/lang/src/test/org/apache/commons/lang/builder/ToStringBuilderTest.java
Index: ToStringBuilderTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/builder/ToStringBuilderTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ToStringBuilderTest.java 27 Mar 2003 08:55:22 - 1.7
+++ ToStringBuilderTest.java 3 Jun 2003 20:15:32 - 1.8
@@ -217,6 +217,10 @@
//
public void assertReflectionArray(String expected, Object actual) {
+if (actual == null) {
+// Until ToStringBuilder supports null objects.
+return;
+}
assertEquals(expected, ToStringBuilder.reflectionToString(actual));
assertEquals(expected, ToStringBuilder.reflectionToString(actual, null));
assertEquals(expected, ToStringBuilder.reflectionToString(actual, null,
true));
@@ -545,7 +549,7 @@
public void testSimpleReflectionObjectCycle() throws Exception {
SimpleReflectionTestFixture simple = new SimpleReflectionTestFixture();
simple.o = simple;
-assertTrue(ToStringBuilder.getReflectionRegistry().isEmpty());
+assertTrue(ReflectionToStringBuilder.getRegistry().isEmpty());
assertEquals(this.toBaseString(simple) + [o= + this.toBaseString(simple)
+ ], simple.toString());
this.validateEmptyReflectionRegistry();
}
@@ -595,7 +599,7 @@
}
void validateEmptyReflectionRegistry() {
-assertTrue(ToStringBuilder.getReflectionRegistry().isEmpty());
+assertTrue(ReflectionToStringBuilder.getRegistry().isEmpty());
}
// End: Reflection cycle tests
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [COLLECTIONS] FastHashMap performance
From Java theory and practice: Urban performance legends (http://www-106.ibm.com/developerworks/library/j-jtp04223.html?ca=dnt-416): First of all, microbenchmarks rarely measure what you think they're measuring. In the presence of dynamic compilation, you have no idea what bytecode the JVM decides to convert into native code or when, so you can't really compare apples to apples. It's difficult to say why you're getting the results you're getting w/ out seeing the benchmark code. But as the above paragraph states, even w/ your code, it'd be tough to say for sure why the graph is the way it is w/out seeing the bytecode your particular compiler is generating and knowing the details of the way the particular JVM you're using dynamically converts the bytecode to native code. This isn't to say that the results aren't interesting, they're just not horribly meaningful on their own. It'd be interesting to see the code and see the results of running the benchmark under a profiler to see where time was actually being spent, and running more than just 10 runs per object type. Dave Shapira, Yoav [EMAIL PROTECTED] 06/03/2003 03:52 PM Please respond to Jakarta Commons Developers List To: Jakarta Commons Developers List [EMAIL PROTECTED] cc: Subject:RE: [COLLECTIONS] FastHashMap performance Howdy, Assuming I agree that GC and JIT play a role in my benchmark (which I don't without further convincing), how should I disable them? I see -XX:-DisableExplicitGC is a VM option, but it only disables explicit System.gc() calls, which I don't use anyways. I couldn't find an option to disable JIT. The heap has ample space to hold the objects in my benchmark. My results don't change if I increase -Xmx or change -Xms to match -Xmx. Yoav Shapira Millennium ChemInformatics -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 3:37 PM To: Jakarta Commons Developers List Subject: Re: [COLLECTIONS] FastHashMap performance I have tried to implement performance tests for maps, but it is not trivial. Try to dissable GC and JIT for performance tests. - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 9:05 PM Subject: RE: [COLLECTIONS] FastHashMap performance Howdy, I've had tests with both a normal hashmap (just new HashMap() used) and a synchronized wrapper (Collections.synchronizedMap(new HashMap()). I would expect the normal HashMap to be faster than both the FastHashMap and the synchronized HashMap. Is my expectation wrong? However, here are the results: [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1592 / Read time: 30] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1265 / Read time: 6] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 983 / Read time: 7] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1158 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1194 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 827 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 990 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1006 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 732 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 949 / Read time: 3] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1003 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1579 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 888 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1045 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 793 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1151 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 855 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 905 / Read time: 3] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1217 / Read time: 1] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1269 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 1107 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: false / Insert time: 1062 / Read time: 2] [MapTest: FastHashMap: true / Synchronized wrapper: false / Insert time: 1252 / Read time: 2] [MapTest: FastHashMap: false / Synchronized wrapper: true / Insert time: 971 / Read time: 2] [MapTest: FastHashMap: false / Synchronized
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang IllegalClassException.java
ggregory2003/06/03 13:49:59
Modified:lang/src/java/org/apache/commons/lang
IllegalClassException.java
Log:
Minor Javadoc fix and improvements.
Revision ChangesPath
1.3 +8 -7
jakarta-commons/lang/src/java/org/apache/commons/lang/IllegalClassException.java
Index: IllegalClassException.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/IllegalClassException.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IllegalClassException.java16 May 2003 16:14:16 - 1.2
+++ IllegalClassException.java3 Jun 2003 20:49:59 - 1.3
@@ -54,16 +54,17 @@
package org.apache.commons.lang;
/**
- * Thrown when an object is an instance of an unexpected class.
+ * Thrown when an object is an instance of an unexpected type (a class or
interface).
*
* @author Matthew Hawthorne
+ * @author Gary Gregory
* @since 2.0
* @version $Id$
*/
public class IllegalClassException extends IllegalArgumentException {
/**
- * Instantiates with the specified classes.
+ * Instantiates with the specified types (classes or interfaces).
*
* @param expected the expected type
* @param actual the actual type
@@ -72,12 +73,12 @@
super(
Expected:
+ safeGetClassName(expected)
-+ , Actual:
++ , actual:
+ safeGetClassName(actual));
}
/**
- * Instantiates with the specified classes.
+ * Instantiates with the specified message.
*
* @param message the exception message
*/
@@ -86,10 +87,10 @@
}
/**
- * Gets a classname without throwing an Exception.
+ * Returns the class name or codenull/code if the class is
codenull/code.
*
* @param cls a codeClass/code
- * @return the name of codec/code, or a codenull/code
codeString/code
+ * @return the name of codecls/code, or codenull/code if if
codecls/code is codenull/code.
*/
private static final String safeGetClassName(Class cls) {
return cls == null ? null : cls.getName();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [COLLECTIONS] FastHashMap performance
Howdy, From Java theory and practice: Urban performance legends (http://www-106.ibm.com/developerworks/library/j-jtp04223.html?ca=dnt-4 16): I'd read that when it was posted: it's a good and interesting article. Thank you for sending the link anyways. I agree with many of the points made in the article. It's difficult to say why you're getting the results you're getting w/ out seeing the benchmark code. But as the above paragraph states, even w/ your I tried attaching it as a .java file. I'll try again as a jar file which contains the bytecode, source code, my system info, my JDK info, and sample results. code, it'd be tough to say for sure why the graph is the way it is w/out seeing the bytecode your particular compiler is generating and knowing the details of the way the particular JVM you're using dynamically converts the bytecode to native code. I agree. So how would I ago about answering this why question? Namely, why is FastHashMap writing faster than java.util.HashMap writing? This isn't to say that the results aren't interesting, they're just not horribly meaningful on their own. It'd be interesting to see the code and see the results of running the benchmark under a profiler to see where time was actually being spent, and running more than just 10 runs per object type. I agree with both. I will also run it on different operating systems to see if the behavior is consistent. I will post more information as time permits. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] matters of copyright
On Tuesday, June 3, 2003, at 12:41 AM, Phil Steitz wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip it seems to me that brent is assuring us that he went back to the mathematical basis of the algorithm and started from that. a clean implementation based on the mathematics should not infringe the copyright nor is it ethically dubious (providing that the correct credits for the original mathematics are provided if that's possible). what we need to think about is how we can demonstrate this to everybody's satisfaction. the openness of the ASF is one of it's great strengths and there should be some way we can show the right way to develop new implementations. (of course, we need to work out what that is first ;) From Brent's notes on the gamma function implementations, I at least am convinced that his implementation was developed from the math, not the NR algorithm or code. The dodgy bit is that someone else who did the same derivation and ended up with a similar implementation (e.g. NR) might claim ownership of the algorithm itself. This is why the limitation expressed in the NR copyright statement is important. definitely. i think that there are two important lessons here. the first that brent was right in the way that he went about demonstration that he developed his implementation from the mathematics. we should probably think about asking for mathematical descriptions of the algorithms so addition to the developers manual. if these are not available on the web then we should make efforts (as brent did) to create some notes and add them to the developers guide. the second is that we're going to need to audit our implementations against copyrighted ones. (i'm hoping that some better qualified folks might volunteer for this.) if we find any that are too similar, then we should use apache development resources to create fresh clean room implementations. i believe that providing new implementation from the basic mathematics is what commons-math should do. there is no real reason why we should start from existing code. if we can't, then maybe that's a sign that we're moving away from our aims. The one exception to this is obviously existing code that is owned by the contributor. Even in this case, however, refactoring will usually be required (certainly has been for me :-)). maybe 'clean and original implementations created by commons-math developers' was probably closer to what i wanted to say than 'new implementations'. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs cookies.xml
olegk 2003/06/03 14:26:35 Modified:httpclient/xdocs cookies.xml Log: Minor corrections in the Cookies guide Contributed by Oleg Kalnichevski Revision ChangesPath 1.2 +46 -26jakarta-commons/httpclient/xdocs/cookies.xml Index: cookies.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/cookies.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- cookies.xml 1 Jun 2003 18:51:23 - 1.1 +++ cookies.xml 3 Jun 2003 21:26:35 - 1.2 @@ -5,6 +5,7 @@ properties titleHttpClient Cookie Guide/title author email=[EMAIL PROTECTED]Adrian Sutton/author +author email=[EMAIL PROTECTED]Oleg Kalnichevski/author revision$Id$/revision /properties @@ -16,20 +17,32 @@ server when required. It is also possible to manually set cookies to be sent to the server./p - pUnfortunately, there are two major standards for handling Cookies, - RFC2109 and the Netscape Cookie draft, and a large number of - implementations are completely non-standard. To deal with this, - HttpClient provides configurable cookie specifications. This guide will - explain how to use the different cookie specifications and identify some - of the common problems people have when using Cookies and HttpClient./p + pUnfortunately, there are several at times conflicting standards for + handling Cookies: the Netscape Cookie draft, RFC2109, RFC2965 and a large + number of vendor specific implementations that are compliant with neither + specification. To deal with this, HttpClient provides policy driven cookie + management. This guide will explain how to use the different cookie + specifications and identify some of the common problems people have when + using Cookies and HttpClient./p /section section name=Available Specifications pThe following cookie specifications are supported by HttpClient./p + subsection name=Netscape Draft +pThe Netscape draft is the original cookie specification which formed +the basis for RFC2109. Despite this it has some significant +differences with RFC2109 and thus may be required for compatibility +with some servers./p + +pThe Netscape cookie draft is available at a + href=http://wp.netscape.com/newsref/std/cookie_spec.html;http://wp.netscape.com/newsref/std/cookie_spec.html/a +/p + /subsection + subsection name=RFC2109 -pRFC2109 is the final published specification released by the W3C. -Theoretically, all servers that handle cookies should use this +pRFC2109 is the first official cookie specification released by the W3C. +Theoretically, all servers that handle version 1 cookies should use this specification and as such this specification is used by default within HttpClient./p @@ -43,23 +56,31 @@ /p /subsection - subsection name=Netscape Draft -pThe Netscape draft is the original cookie specification which formed -the basis for RFC2109. Despite this it has some significant -differences with RFC2109 and thus may be required for compatibility -with some servers./p - -pThe Netscape cookie draft is available at a - href=http://wp.netscape.com/newsref/std/cookie_spec.html;http://wp.netscape.com/newsref/std/cookie_spec.html/a -/p - /subsection - subsection name=Compatibility pThe compatibility specification is designed to be compatible with as many different servers as possible even if they are not completely -standards compliant. If you are encountering problems with parsing +standards compliant. If you are encountering problems with parsing cookies, you should probably try using this specification./p /subsection + +/section + +section name=Unsupported Specifications + pThe following cookie specifications are not presently supported by HttpClient./p + + subsection name=RFC2965 +pRFC2965 defines cookie version 2 and attempts to address the shortcomings +of the RFC2109 regarding cookie version 1. RFC2965 is intended to eventually +supersede RFC2109./p + +pCurrently HttpClient does not implement this specification. Support for + version 2 cookies will be added in the future/p + +pRFC2965 is available at +a href=http://www.w3.org/Protocols/rfc2965/rfc2965.txt;http://www.w3.org/Protocols/rfc2965/rfc2965.txt/a +/p + /subsection + /section section name=Specifying the
Re: [math] matters of copyright
robert burrell donkin wrote: On Tuesday, June 3, 2003, at 12:41 AM, Phil Steitz wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip it seems to me that brent is assuring us that he went back to the mathematical basis of the algorithm and started from that. a clean implementation based on the mathematics should not infringe the copyright nor is it ethically dubious (providing that the correct credits for the original mathematics are provided if that's possible). what we need to think about is how we can demonstrate this to everybody's satisfaction. the openness of the ASF is one of it's great strengths and there should be some way we can show the right way to develop new implementations. (of course, we need to work out what that is first ;) From Brent's notes on the gamma function implementations, I at least am convinced that his implementation was developed from the math, not the NR algorithm or code. The dodgy bit is that someone else who did the same derivation and ended up with a similar implementation (e.g. NR) might claim ownership of the algorithm itself. This is why the limitation expressed in the NR copyright statement is important. definitely. i think that there are two important lessons here. the first that brent was right in the way that he went about demonstration that he developed his implementation from the mathematics. we should probably think about asking for mathematical descriptions of the algorithms so addition to the developers manual Have you had a chance to look at the draft developer's guidelines that I started and submitted here: http://issues.apache.org/bugzilla/show_bug.cgi?id=20404 We could add a note on this to the section called documentation. if these are not available on the web then we should make efforts (as brent did) to create some notes and add them to the developers guide. I agree. I think that the best approach will be to include full descriptions of mathematical algorithms not available on the web using links in the javadoc to the commons-math developers/users guide. the second is that we're going to need to audit our implementations against copyrighted ones. (i'm hoping that some better qualified folks might volunteer for this.) if we find any that are too similar, then we should use apache development resources to create fresh clean room implementations. I don't understand exactly what you mean here. It might be difficult to find people with the combined legal and math skills to audit the code for copyright infringement. What did you have in mind here? i believe that providing new implementation from the basic mathematics is what commons-math should do. there is no real reason why we should start from existing code. if we can't, then maybe that's a sign that we're moving away from our aims. The one exception to this is obviously existing code that is owned by the contributor. Even in this case, however, refactoring will usually be required (certainly has been for me :-)). maybe 'clean and original implementations created by commons-math developers' was probably closer to what i wanted to say than 'new implementations'. - robert - 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: Any Plans for an Execute library?
Sorry, I was looking at the commons-sandbox. There is a launcher in there. --Maciej Shapira, Yoav wrote: I don't see a commons launcher component. Are you talking about the Catalina launcher, i.e. the classes in org.apache.catalina.launcher? Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] extending BasicDynaBean with toString, equals, and hashCode
I've written an extended dynabean class that extends (actually, wraps) BasicDynaBean to add toString and equals. The toString method uses commons.lang.ToStringBuilder to build the toString, and commons.lang.EqualsBuilder to perform the equals comparison. I know it needs hashCode, I just haven't taken the time to add it yet. Is there any interest in having this class donated to commons-beanutils? Steven Caswell [EMAIL PROTECTED] In our own native land, in defense of the freedom that is our birthright, and which we ever enjoyed till the late violation of it -- for the protection of our property, acquired solely by the honest industry of our fore-fathers and ourselves, against violence actually offered, we have taken up arms. We shall lay them down when hostilities shall cease on the part of the aggressors, and all danger of their being renewed shall be removed, and not before. - Thomas Jefferson
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli OptionGroup.java ExclusiveOptionGroup.java AnonymousArgumentImpl.java Options.java InclusiveOptionGroup.java CommandLineParser.java
jkeyes 2003/06/03 18:11:41
Modified:cli/src/java/org/apache/commons/cli Tag: cli_1_x
OptionGroup.java ExclusiveOptionGroup.java
AnonymousArgumentImpl.java Options.java
InclusiveOptionGroup.java CommandLineParser.java
Log:
inital work on new OptionGroup support, some tidy up remains
added license
removed tabs
Revision ChangesPath
No revision
No revision
1.8.2.2 +67 -9
jakarta-commons/cli/src/java/org/apache/commons/cli/OptionGroup.java
Index: OptionGroup.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/OptionGroup.java,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- OptionGroup.java 19 May 2003 20:59:44 - 1.8.2.1
+++ OptionGroup.java 4 Jun 2003 01:11:40 - 1.8.2.2
@@ -1,16 +1,74 @@
+/*
+ * $Header$
+ * $Revision$
+ * $Date$
+ *
+ *
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
+ * reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * 3. The end-user documentation included with the redistribution, if
+ *any, must include the following acknowlegement:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowlegement may appear in the software itself,
+ *if and wherever such third-party acknowlegements normally appear.
+ *
+ * 4. The names The Jakarta Project, Commons, and Apache Software
+ *Foundation must not be used to endorse or promote products derived
+ *from this software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
+ *
+ * 5. Products derived from this software may not be called Apache
+ *nor may Apache appear in their names without prior written
+ *permission of the Apache Group.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation. For more
+ * information on the Apache Software Foundation, please see
+ * http://www.apache.org/;.
+ *
+ */
package org.apache.commons.cli;
-import java.util.Set;
-
/**
- * @author jkeyes
+ * @author John Keyes
*/
public interface OptionGroup {
- Set getOptions();
- boolean containsOption(Option option);
- boolean isSelected();
- void setSelected(Option option);
- void reset();
-
+
+boolean hasOption(String name);
+
+Option getOption(String name);
+
+void isValid(CommandLine line) throws ParseException;
}
1.1.2.2 +176 -84
jakarta-commons/cli/src/java/org/apache/commons/cli/Attic/ExclusiveOptionGroup.java
Index: ExclusiveOptionGroup.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/Attic/ExclusiveOptionGroup.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- ExclusiveOptionGroup.java 19 May 2003 20:57:51 - 1.1.2.1
+++ ExclusiveOptionGroup.java 4 Jun 2003 01:11:40 - 1.1.2.2
@@ -1,101 +1,193 @@
+/*
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli CommandLineParser.java
jkeyes 2003/06/03 18:23:49
Modified:cli/src/java/org/apache/commons/cli Tag: cli_1_x
CommandLineParser.java
Log:
changed classname
Revision ChangesPath
No revision
No revision
1.6.2.6 +4 -4
jakarta-commons/cli/src/java/org/apache/commons/cli/CommandLineParser.java
Index: CommandLineParser.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/CommandLineParser.java,v
retrieving revision 1.6.2.5
retrieving revision 1.6.2.6
diff -u -r1.6.2.5 -r1.6.2.6
--- CommandLineParser.java4 Jun 2003 01:11:41 - 1.6.2.5
+++ CommandLineParser.java4 Jun 2003 01:23:49 - 1.6.2.6
@@ -118,7 +118,7 @@
processOptionGroup(options, iter, creator, arg);
}
else if (
-this.style == NewCommandLineParser.POSIX
+this.style == CommandLineParser.POSIX
!arg.equals(-)
arg.startsWith(-)
!arg.startsWith(--)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli project.properties
jkeyes 2003/06/03 18:26:34
Modified:cli Tag: cli_1_x project.properties
Log:
sun coding standards
Revision ChangesPath
No revision
No revision
1.5.2.1 +0 -3 jakarta-commons/cli/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/cli/project.properties,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- project.properties12 Jan 2003 23:04:26 - 1.5
+++ project.properties4 Jun 2003 01:26:34 - 1.5.2.1
@@ -7,6 +7,3 @@
compile.deprecation = off
maven.jarResources.basedir=${basedir}/src/java
-
-# use turbine coding standards
-maven.checkstyle.format = turbine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20373] - [math] t distribution patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20373 [math] t distribution patch --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:17 --- This patch can be ignored as it is dependent on the now omitted, Gamma.java. I currently working on resubmitting a new chi-squared and t distribution patch without any reference to NR. I've found most the needed formulas at mathworld. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math RootFinding.java
mdiggory2003/06/03 19:17:17
Modified:math/src/java/org/apache/commons/math RootFinding.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20375
Submitted by: Albert Davidson Chou
Revision ChangesPath
1.2 +61 -33
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/RootFinding.java
Index: RootFinding.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/RootFinding.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RootFinding.java 29 May 2003 19:34:37 - 1.1
+++ RootFinding.java 4 Jun 2003 02:17:17 - 1.2
@@ -55,83 +55,111 @@
/**
* Utility class comprised of root finding techniques.
- *
+ *
* @author Brent Worden
*/
public class RootFinding {
/** Maximum allowed numerical error. */
private static final double EPSILON = 10e-9;
- /**
- * Default constructor. Prohibit construction.
- */
- private RootFinding(){
- super();
- }
+/**
+ * Default constructor. Prohibit construction.
+ */
+private RootFinding(){
+super();
+}
/**
* For a function, f, this method returns two values, a and b that bracket
* a root of f. That is to say, there exists a value c between a and b
* such that f(c) = 0.
- *
+ *
* @param function the function
* @param initial midpoint of the returned range.
* @param lowerBound for numerical safety, a never is less than this value.
* @param upperBound for numerical safety, b never is greater than this value.
* @return a two element array holding {a, b}.
*/
-public static double[] bracket(UnivariateFunction function,
- double initial,
- double lowerBound,
+public static double[] bracket(UnivariateFunction function,
+ double initial,
+ double lowerBound,
double upperBound){
+return bracket( function, initial, lowerBound, upperBound,
Integer.MAX_VALUE ) ;
+}
+
+/**
+ * For a function, f, this method returns two values, a and b that bracket
+ * a root of f. That is to say, there exists a value c between a and b
+ * such that f(c) = 0.
+ *
+ * @param function the function
+ * @param initial midpoint of the returned range.
+ * @param lowerBound for numerical safety, a never is less than this value.
+ * @param upperBound for numerical safety, b never is greater than this value.
+ * @param maximumIterations to guard against infinite looping, maximum number
of iterations to perform
+ * @return a two element array holding {a, b}.
+ */
+public static double[] bracket(UnivariateFunction function,
+ double initial,
+ double lowerBound,
+ double upperBound,
+ int maximumIterations){
double a = initial;
double b = initial;
double fa;
double fb;
-
-do {
+int numIterations = 0 ;
+
+do {
a = Math.max(a - 1.0, lowerBound);
b = Math.min(b + 1.0, upperBound);
fa = function.evaluate(a);
fb = function.evaluate(b);
-} while(fa * fb 0.0);
-
-return new double[]{a, b};
+numIterations += 1 ;
+} while ( (fa * fb 0.0) ( numIterations maximumIterations ) );
+
+return new double[]{a, b};
}
-
+
/**
* For a function, f, this method returns a root c that lies between a and
* b, and satisfies f(c) = 0.
- *
+ *
* @param function the function
- * @param a lower bound of a root
- * @param b upper bound of a root
+ * @param a lower (or upper) bound of a root
+ * @param b upper (or lower) bound of a root
* @return a root of f
*/
-public static double bisection(UnivariateFunction function,
- double a,
+public static double bisection(UnivariateFunction function,
+ double a,
double b){
double m;
double fm;
double fa;
-double fb;
-
+
+if ( b a )
+{
+double xtemp = a ;
+a = b ;
+b = xtemp ;
+}
+
+fa = function.evaluate(a);
+
while(Math.abs(a - b) EPSILON){
DO NOT REPLY [Bug 20375] - [math] bisection root finder, safety and efficiency enhancements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20375. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20375 [math] bisection root finder, safety and efficiency enhancements [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:20 --- I applied this patch and am closing this bug report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat StoreUnivariate.java AbstractStoreUnivariate.java
mdiggory2003/06/03 19:22:48
Modified:math/src/java/org/apache/commons/math/stat
StoreUnivariate.java AbstractStoreUnivariate.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20377
Submitted by: Phil Steitz
Revision ChangesPath
1.2 +31 -1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StoreUnivariate.java
Index: StoreUnivariate.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StoreUnivariate.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StoreUnivariate.java 29 May 2003 20:35:45 - 1.1
+++ StoreUnivariate.java 4 Jun 2003 02:22:48 - 1.2
@@ -113,12 +113,24 @@
/**
* Returns the current set of values in an array of double primitives.
- * The order of addition is preserved
+ * The order of addition is preserved. The returned array is a fresh
+ * copy of the underlying data -- i.e., it is not a reference to the
+ * stored data.
*
* @return returns the current set of numbers in the order in which they
* were added to this set
*/
public abstract double[] getValues();
+
+/**
+ * Returns the current set of values in an array of double primitives,
+ * sorted in ascending order. The returned array is a fresh
+ * copy of the underlying data -- i.e., it is not a reference to the
+ * stored data.
+ *
+ * @return returns the current set of numbers sorted in ascending order
+ */
+public abstract double[] getSortedValues();
/**
* Returns the element at the specified index
@@ -126,5 +138,23 @@
* @return return the element at the specified index
*/
public abstract double getElement(int index);
+
+/**
+ * Returns an estimate for the pth percentile of the stored values,
+ * following the interpolation-adjusted defintion presented
+ * a href=http://www.utdallas.edu/~ammann/stat5311/node8.html;here/ap
+ *
+ * strongPreconditions/strong:ul
+ * licode0 p 100/code (otherwise an codeIllegalArgumentException
+ * /code is thrown)/li
+ * liat least one value must be stored (returns codeDouble.NaN
+ * /code otherwise)/li
+ * /ul
+ *
+ * @param p the requested percentile (scaled from 0 - 100)
+ * @return returns an estimate for the pth percentile of the stored data
+ * values
+ */
+public abstract double getPercentile(double p);
}
1.2 +61 -0
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/AbstractStoreUnivariate.java
Index: AbstractStoreUnivariate.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/AbstractStoreUnivariate.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractStoreUnivariate.java 29 May 2003 20:35:45 - 1.1
+++ AbstractStoreUnivariate.java 4 Jun 2003 02:22:48 - 1.2
@@ -58,6 +58,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Tim O'Brien/a
* @author Mark Diggory
+ * @author a href=mailto:[EMAIL PROTECTED]Phil Steitz/a
*/
public abstract class AbstractStoreUnivariate implements StoreUnivariate {
@@ -290,6 +291,66 @@
accum += Math.pow(getElement(i), 2.0);
}
return accum;
+}
+
+/**
+ * Uses a href=http://www.nist.gov/dads/HTML/shellsort.html;Shell sort
+ * /a
+ * @see org.apache.commons.math.StoreUnivariate#getSortedValues()
+ *
+ */
+public double[] getSortedValues() {
+double[] values = getValues();
+int n = values.length;
+int j = n;
+while (j 1) {
+j = j / 2;
+boolean done = false;
+while (!done) {
+done = true;
+for (int i = 0; i n - j; i++) {
+int k = i + j;
+if (values[i] values[k]) {
+double temp = values[i];
+values[i] = values[k];
+values[k] = temp;
+done = false;
+}
+}
+}
+}
+return values;
+}
+
+/**
+ * Returns an estimate for the pth percentile of the stored values
+ * @see org.apache.commons.math.StoreUnivariate#getPercentile()
+ */
+public double getPercentile(double p) {
+if ((p 100) || (p = 0)) {
+throw new IllegalArgumentException(invalid
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat StoreUnivariateImplTest.java
mdiggory2003/06/03 19:24:51
Modified:math/src/test/org/apache/commons/math/stat
StoreUnivariateImplTest.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20377
Submitted by: Phil Steitz
Revision ChangesPath
1.2 +138 -19
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/StoreUnivariateImplTest.java
Index: StoreUnivariateImplTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/StoreUnivariateImplTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StoreUnivariateImplTest.java 29 May 2003 20:35:46 - 1.1
+++ StoreUnivariateImplTest.java 4 Jun 2003 02:24:51 - 1.2
@@ -56,6 +56,8 @@
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
+import org.apache.commons.math.RandomDataImpl;
+import org.apache.commons.math.RandomData;
/**
* Test cases for the [EMAIL PROTECTED] Univariate} class.
@@ -117,22 +119,29 @@
public void testN0andN1Conditions() throws Exception {
StoreUnivariate u = new StoreUnivariateImpl();
- assertTrue(Mean of n = 0 set should be NaN, Double.isNaN(
u.getMean() ) );
- assertTrue(Standard Deviation of n = 0 set should be NaN,
Double.isNaN( u.getStandardDeviation() ) );
- assertTrue(Variance of n = 0 set should be NaN,
Double.isNaN(u.getVariance() ) );
-
- u.addValue(one);
-
- assertTrue( Mean of n = 1 set should be value of single item n1,
u.getMean() == one);
- assertTrue( StdDev of n = 1 set should be zero, instead it is: +
u.getStandardDeviation(), u.getStandardDeviation() == 0);
- assertTrue( Variance of n = 1 set should be zero, u.getVariance() ==
0);
+assertTrue(Mean of n = 0 set should be NaN,
+Double.isNaN( u.getMean() ) );
+assertTrue(Standard Deviation of n = 0 set should be NaN,
+Double.isNaN( u.getStandardDeviation() ) );
+assertTrue(Variance of n = 0 set should be NaN,
+Double.isNaN(u.getVariance() ) );
+
+u.addValue(one);
+
+assertTrue( Mean of n = 1 set should be value of single item n1,
+u.getMean() == one);
+assertTrue( StdDev of n = 1 set should be zero, instead it is:
++ u.getStandardDeviation(), u.getStandardDeviation() == 0);
+assertTrue( Variance of n = 1 set should be zero,
+u.getVariance() == 0);
}
public void testSkewAndKurtosis() {
StoreUnivariate u = new StoreUnivariateImpl();
- double[] testArray = { 12.5, 12, 11.8, 14.2, 14.9, 14.5, 21, 8.2, 10.3, 11.3,
14.1,
-
9.9, 12.2, 12, 12.1, 11, 19.8, 11, 10, 8.8, 9, 12.3 };
+ double[] testArray =
+{ 12.5, 12, 11.8, 14.2, 14.9, 14.5, 21, 8.2, 10.3, 11.3, 14.1,
+ 9.9, 12.2, 12, 12.1, 11, 19.8, 11, 10, 8.8, 9, 12.3 };
for( int i = 0; i testArray.length; i++) {
u.addValue( testArray[i]);
}
@@ -152,8 +161,10 @@
u.addValue( 3.0 );
u.addValue( 4.0 );
-assertEquals( Product not expected, 24.0, u.getProduct(),
Double.MIN_VALUE );
-assertEquals( Geometric mean not expected, 2.213364,
u.getGeometricMean(), 0.1 );
+assertEquals( Product not expected,
+24.0, u.getProduct(), Double.MIN_VALUE );
+assertEquals( Geometric mean not expected,
+2.213364, u.getGeometricMean(), 0.1 );
// Now test rolling - UnivariateImpl should discount the contribution
// of a discarded element
@@ -162,11 +173,119 @@
}
// Values should be (2,3,4,5,6,7,8,9,10,11)
-assertEquals( Product not expected, 39916800.0, u.getProduct(), 0.1 );
-assertEquals( Geometric mean not expected, 5.755931,
u.getGeometricMean(), 0.1 );
-
-
+assertEquals( Product not expected, 39916800.0,
+u.getProduct(), 0.1 );
+assertEquals( Geometric mean not expected, 5.755931,
+u.getGeometricMean(), 0.1 );
+}
+
+public void testGetSortedValues() {
+double[] test1 = {5,4,3,2,1};
+double[] test2 = {5,2,1,3,4,0};
+double[] test3 = {1};
+int[] testi = null;
+double[] test4 = null;
+RandomData rd = new RandomDataImpl();
+tstGetSortedValues(test1);
+tstGetSortedValues(test2);
+tstGetSortedValues(test3);
+
DO NOT REPLY [Bug 20377] - [math] Adding percentiles to StoredUnivariate, AbstractStoreUnivariate
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20377. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20377 [math] Adding percentiles to StoredUnivariate, AbstractStoreUnivariate [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:28 --- I've applied both patches to the StoreUnivariate** and verified that the Unit Tests work with the Ant build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math MathUtilsTest.java
mdiggory2003/06/03 19:31:14
Added: math/src/java/org/apache/commons/math MathUtils.java
math/src/test/org/apache/commons/math MathUtilsTest.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20390
Submitted by: Phil Steitz
Revision ChangesPath
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/MathUtils.java
Index: MathUtils.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.math;
/**
* Some useful additions to the built-in functions in lang.Mathp
*
* @author Phil Steitz
* @version $Revision: 1.1 $ $Date: 2003/06/04 02:31:13 $
*/
public class MathUtils {
/**
* Returns an exact representation of the
* a href=http://mathworld.wolfram.com/BinomialCoefficient.html;
* Binomial Coefficient/a, coden choose k/code,
* the number of codek/code-element subsets that can be selected from
* an coden/code-element set.
* p
* StrongPreconditions/strong:ul
* li code0 k = n /code (otherwise
* codeIllegalArgumentException/code is thrown)/li
* li The result is small enough to fit into a codelong/code. The
* largest value of coden/code for which all coefficients are
* code Long.MAX_VALUE/code is 66. If the computed value
* exceeds codeLong.MAX_VALUE/code an codeArithMeticException
* /code is thrown./li
* /ul
*
* @param n the size of the set
* @param k the size of the subsets to be counted
* @return coden choose k/code
*/
public static long binomialCoefficient(int n, int k) {
if (n k) {
throw new IllegalArgumentException
(must have n = k for binomial coefficient (n,k));
}
if (n = 0) {
throw new IllegalArgumentException
(must have n 0 for binomial coefficient (n,k));
}
if ((n == k) || (k == 0)) {
return 1;
}
if ((k == 1) || (k == n - 1)) {
return n;
}
long result =
DO NOT REPLY [Bug 20390] - [math] Adding MathUtils class, including binomial coefficients, factorials
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20390. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20390 [math] Adding MathUtils class, including binomial coefficients, factorials [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:34 --- Added both files tot he cvs and ran the UnitTests to verify build works correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/xdocs developers.xml
mdiggory2003/06/03 19:40:26 Modified:math/xdocs developers.xml Log: PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20404 Submitted by: Phil Steitz Revision ChangesPath 1.4 +69 -4 jakarta-commons-sandbox/math/xdocs/developers.xml Index: developers.xml === RCS file: /home/cvs/jakarta-commons-sandbox/math/xdocs/developers.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- developers.xml30 May 2003 15:40:28 - 1.3 +++ developers.xml4 Jun 2003 02:40:26 - 1.4 @@ -14,11 +14,76 @@ case for other components. It is important that developers follow guidelines laid down by the community to ensure that the code they create can be successfully maintained by others. +/p + /section + section name='Guidelines' + p + Developers are asked to comply with the following development guidelines. + Code that does not comply with the guidelines including the word imust/i + will not be committed. Our aim will be to fix all of the exceptions to the + ishould/i guidelines prior to a release. /p - /section - section name='Guidelines' - Still under development...! - /section + subsection name='Coding Style' +p + Commons-math follows a href=http://java.sun.com/docs/codeconv/;Code + Conventions for the Java Programming Language/a. As part of the maven + build process, style checking is performed using the checkStyle plugin, + using the properties specified in codecheckStyle.properties/code. + Committed code ishould/i generate no checkStyle errors. +/p + /subsection + subsection name='Documentation' +ul + li + Committed code imust/i include full javadoc./li + li + All component contracts imust/i be fully specified in the javadoc class, + interface or method comments, including specification of acceptable ranges + of values, exceptions or special return values./li + li + References to definitions for all mathematical + terms used in component documentation imust/i be provided, preferably + as HTML links./li + li + Implementations ishould/i use standard algorithms and + references to algorithm descriptions ishould/i be provided, + preferably as HTML links./li +/ul + /subsection + subsection name='Unit Tests' +ul + li + Committed code imust/i include unit tests./li + li + Unit tests ishould/i provide full path coverage. /li + li + Unit tests ishould/i verify all boundary conditions specified in + interface contracts, including verification that exceptions are thrown or + special values (e.g. Double.NaN, Double.Infinity) are returned as + expected. /li +/ul + /subsection + subsection name='Licensing and copyright' +ul + li + All new source file submissions imust/i include the Apache Software + License in a comment that begins the file /li + li + All contributions must comply with the terms of the + a href=http://www.apache.org/foundation/ASF_Contributor_License_1_form.pdf; + Apache Contributor License Agreement (CLA)/a/li + li + Patches imust/i be accompanied by a clear reference to a source + - if code has been ported from another language, clearly state the + source of the original implementation. If the expression of a given + algorithm is derivative, please note the original source (textbook, + paper, etc.)./li + li + References to source materials covered by restrictive proprietary + licenses should be avoided./li +/ul + /subsection + /section section name='Recommended Readings' p Here is a list of relevant materials. Much of the discussion surrounding - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20404] - [math] Add content to guidelines section in developer.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20404. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20404 [math] Add content to guidelines section in developer.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:44 --- Applied the first part of this patch. The links were already commited to the file earlier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math RandomDataTest.java
mdiggory2003/06/03 19:45:49
Modified:math/src/java/org/apache/commons/math RandomDataImpl.java
RandomData.java
math/src/test/org/apache/commons/math RandomDataTest.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20442
Submitted by: Phil Steitz
Revision ChangesPath
1.3 +131 -135
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/RandomDataImpl.java
Index: RandomDataImpl.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/RandomDataImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RandomDataImpl.java 29 May 2003 19:45:35 - 1.2
+++ RandomDataImpl.java 4 Jun 2003 02:45:49 - 1.3
@@ -64,42 +64,50 @@
/**
* Implements the codeRandomData/code interface using
* codejava.util.Random/code and
- * codejava.util.Random.SecureRandom/code instances to generate data.
+ * codejava.util.Random.SecureRandom/code instances to generate data.
+ * p
* Supports reseeding the underlying
- * a href=http://www.wikipedia.org/wiki/Pseudo-random_number_generatorPRNG/a.
- * The codeSecurityProvider/code and codeAlgorithm/code
- * used by the codeSecureRandom/code instance can also be reset.p
+ * a href=http://www.wikipedia.org/wiki/Pseudo-random_number_generator;
+ * PRNG/a. The codeSecurityProvider/code and codeAlgorithm/code
+ * used by the codeSecureRandom/code instance can also be reset.
+ * p
* For details on the PRNGs, see the JDK documentation for
* codejava.util.Random/code and
- * codejava.util.Random.SecureRandom/code/pp
+ * codejava.util.Random.SecureRandom/code
+ * p
* strongUsage Notes/strong: ul
- * liInstance variables are used to maintain codeRandom/code and
+ * li
+ * Instance variables are used to maintain codeRandom/code and
* codeSecureRandom/code instances used in data generation. Therefore,
* to generate a random sequence of values or strings, you should use just
* strongone/strong codeRandomDataImpl/code instance repeatedly./li
- * liThe secure methods are *much* slower. These should be used only when
- * a a
href=http://www.wikipedia.org/wiki/Cryptographically_secure_pseudo-random_number_generator
- * Secure Random Sequence/a is required./li
- *liWhen a new codeRandomDataImpl/code is created, the underlying random
+ * li
+ * The secure methods are *much* slower. These should be used only when
+ * a a href=http://www.wikipedia.org/wiki/
+ * Cryptographically_secure_pseudo-random_number_generator Secure Random
+ * Sequence/a is required./li
+ * li
+ * When a new codeRandomDataImpl/code is created, the underlying random
* number generators are strongnot/strong intialized. The first call to a
* data generation method, or to a codereSeed()/code method instantiates
* the appropriate generator. If you do not explicitly seed the generator, it
* is by default seeded with the current time in milliseconds/li
- * liThe codereSeed/code and codereSeedSecure/code methods delegate to
- * the corresponding methods on the underlying codeRandom/code and code
- * SecureRandom/code instances. Therefore, the contracts of these methods
- * are as defined in the JDK documentation. In particular, codereSeed(long)
- * /code fully resets the initial state of the non-secure random number
- * generator (so that reseeding with a specific value always results in the
- * same subsequent random sequence); whereas reSeedSecure(long) does strong not
- * /strong reinitialize the secure random number generator (so secure sequences
- * started with calls to reseedSecure(long) won't be identical)./li/ul
- */p
+ * li
+ * The codereSeed/code and codereSeedSecure/code methods delegate
+ * to the corresponding methods on the underlying codeRandom/code and
+ * codeSecureRandom/code instances. Therefore, the contracts of these
+ * methods are as defined in the JDK documentation. In particular,
+ * codereSeed(long)/code fully resets the initial state of the non-secure
+ * random number generator (so that reseeding with a specific value always
+ * results in the same subsequent random sequence); whereas reSeedSecure(long)
+ * does strongnot/strong reinitialize the secure random number generator
+ * (so secure sequences started with calls to reseedSecure(long) won't be
+ * identical)./li/ul
*
* @author Phil Steitz
* @version $Revision$ $Date$
*/
-public class RandomDataImpl implements RandomData{
+public class RandomDataImpl implements RandomData {
/** underlying random number generator */
private Random rand = null;
@@ -107,20 +115,19 @@
/** underlying secure random number generator */
private SecureRandom secRand = null;
-
DO NOT REPLY [Bug 20442] - [math] Fix style, javadoc, test coverage gaps in RandomData
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20442. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20442 [math] Fix style, javadoc, test coverage gaps in RandomData [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:49 --- Commited these patches and ran unit tests to verify that the RandomDataTest is working properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Re: [Docs] Component Lists
On Tue, 3 Jun 2003 08:53:41 -0400 (Subject: Re: [PATCH] Re: [Docs] Component Lists) Michael Becke [EMAIL PROTECTED] wrote: I made the changes and updated the site for HttpClient. I left out the jxpath changes but would be happy to add them if others would like. Mike IMHO, I think it is better to change (add) the jxpath release notice, too ... as one of jxpath users. http://jakarta.apache.org/commons/components.html has as many access views next to http://jakarta.apache.org/commons/ , as statistics will show. If there's inconsistency in the components.html page, commons-users might be frustrated or irritated ... I think. Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20373] - [math] t distribution patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20373 [math] t distribution patch [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:50 --- Thanks, I will close it out then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/xdocs releases.xml
mbecke 2003/06/03 19:52:23 Modified:httpclient/xdocs releases.xml Log: updated release procedures Revision ChangesPath 1.11 +16 -27jakarta-commons/httpclient/xdocs/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/releases.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- releases.xml 26 Feb 2003 19:42:39 - 1.10 +++ releases.xml 4 Jun 2003 02:52:23 - 1.11 @@ -44,9 +44,9 @@ release.br/br//li liUpdate the project version number in the codebuild.xml/code, - codeproject.xml/code, and the HttpMethodBase useragent string. - There is an Ant property named codecomponent.version/code that would be - updated to code2.0/code. Check in any files you have + codeproject.xml/code, codestatus.xml/code, and the HttpMethodBase + useragent string. There is an Ant property named codecomponent.version/code + that would be updated to code2.0/code. Check in any files you have modified.br/br//li liIn your local repository (or on cvs.apache.org) tag strongonly/strong the @@ -64,7 +64,12 @@ to ensure that it correctly reflects the functionality (and the version number) of this code.br/br//li - liCreate a news item. This should be added to httpclient/xdocs/news.xml and +liUpdate release_notes.txt. This file should be updated in CVS when + patches are committed, but it is frequently not. Be sure all relevant + changes since the last release are included. This file should be published + along with the release source and binary distributions.br/br//li + +liCreate a news item. This should be added to httpclient/xdocs/news.xml and the jakarta-site2/xdocs/site/news.xml as well as a one liner in jakarta-site2/xdocs/index.htmlbr/br//li @@ -103,12 +108,6 @@ /pre NOTE: Make sure that the files you copy are group writable./li -liUpdate jakarta-site2 module with the news item in xdocs/site/news.xml - and a one liner in xdocs/index.xml. jakarta-site2 needs to be - checked out from the private cvs. After changes are made run - the build.sh script to generate the site. Browse the generated - html documentation and then commit after you are satisfied.br/br//li - liFollow standard procedures to update the Jakarta web site (stored in CVS repository codejakarta-site2/code to reflect the availability of the new release. Generally, you will be updating the following @@ -123,9 +122,12 @@ licodexdocs/site/news.xml/code - Create a news item that describes the new release, and includes hyperlinks to the release directory./li +licodexdocs/index.xml/code - Create a one line news item + that links to the full item in site/news.xml./li /ul ul liThen run ant at the base to generate the new docs and commit the changes to jakarta-site2. + You will be committing the updated xdocs and html. pre ant cvs commit -m update to reflect release of commons-httpclient @@ -138,9 +140,9 @@ /ul /li -liUpdate the pertinent documents in the jakarta-commons/xdocs CVS and then build the - docs by running ant. These pages will probably include components.xml and httpclient.xml. - CVS commit, then if you have an account on daedalus, update the commons website with a +liUpdate components.xml in the jakarta-commons/xdocs CVS and then build the + docs by running ant (this may require some configuration). CVS commit, + then if you have an account on daedalus, update the commons website with a cvs udpate in /www/jakarta.apache.org/commons.br//li liAnnounce the availability of the new package on the following mailing lists: @@ -151,19 +153,6 @@ li[EMAIL PROTECTED]/li /ulbr//li -liEnsure that the pertinent documents in the component's home directory are updated - to reflect the new release. In particular : - ul -liIn strongstatus.xml/strong: - ul -liUpdate codeRelease Info/code section/li -liEnsure codeDependencies/code is correct/li -liEnsure completed tasks are removed from codeTo Do/code list/li - /ul -/li -liUpdate build with new current version/li - /ul -
cvs commit: jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external - New directory
hlship 2003/06/03 20:01:09 jakarta-commons-sandbox/hivemind/src/test/hivemind/test/external - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/src/test/hivemind/test/config ContributeService.xml ServiceHolder.java ContributeSetService.xml TestConfiguration.java
hlship 2003/06/03 20:02:32
Modified:hivemind/src/java/org/apache/commons/hivemind/parse
ServiceDescriptor.java AbstractConfigurator.java
FactoryDescriptor.java DescriptorParser.java
HiveMind_1.0.xsd
AbstractConfigurationDescriptor.java
AbstractServiceDescriptor.java
InstanceBuilderDescriptor.java
InterceptorDescriptor.java
ExpressionDescriptor.java ModuleDescriptor.java
ContributeServiceDescriptor.java
ContributeConfigurationDescriptor.java
ValueDescriptor.java ConfigurationDescriptor.java
CreateInstanceDescriptor.java
hivemind/src/test/hivemind/test HiveMindSuite.java
HiveMindTestCase.java
hivemind/src/test/hivemind/test/services/impl
TrackerFactory.java
hivemind/src/java/org/apache/commons/hivemind/impl
ConfigurationContribution.java
AbstractExtensionPoint.java
FactoryContribution.java
ConfigurationExtensionPoint.java
InterceptorStack.java ServiceExtensionPoint.java
InterceptorContribution.java
hivemind/src/java/org/apache/commons/hivemind
HiveMindMessages.properties
hivemind/src/test/hivemind/test/parse
TestDescriptorParser.java
hivemind/src/test/hivemind/test/config
TestConfiguration.java
Added: hivemind/src/java/org/apache/commons/hivemind/parse
ServiceRefDescriptor.java ExternalParser.java
XMLDescriptor.java
hivemind/src/test/hivemind/test/external Simple.xml
TestExternalParser.java
hivemind/src/java/org/apache/commons/hivemind/impl
Element.java Attribute.java
hivemind/src/java/org/apache/commons/hivemind
IAttribute.java IElement.java
hivemind/src/test/hivemind/test/parse ServiceRef.xml
SetServiceRef.xml
hivemind/src/test/hivemind/test/config ContributeService.xml
ServiceHolder.java ContributeSetService.xml
Log:
Add support for several new elements.
Add support for external XML document parsing.
Revision ChangesPath
1.2 +9 -1
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/ServiceDescriptor.java
Index: ServiceDescriptor.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/ServiceDescriptor.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ServiceDescriptor.java30 May 2003 20:52:01 - 1.1
+++ ServiceDescriptor.java4 Jun 2003 03:02:30 - 1.2
@@ -1,5 +1,6 @@
package org.apache.commons.hivemind.parse;
+import org.apache.commons.lang.builder.ToStringBuilder;
/**
* Defines a service extension point. Corresponds to
@@ -53,6 +54,13 @@
public void setDescription(String string)
{
_description = string;
+}
+
+protected void extendDescription(ToStringBuilder builder)
+{
+builder.append(id, _id);
+builder.append(interfaceClassName, _interfaceClassName);
+builder.append(required, _required);
}
}
1.2 +19 -1
jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractConfigurator.java
Index: AbstractConfigurator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/parse/AbstractConfigurator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractConfigurator.java 30 May 2003 20:52:01 - 1.1
+++ AbstractConfigurator.java 4 Jun 2003 03:02:30 - 1.2
@@ -2,6 +2,7 @@
import org.apache.commons.hivemind.HiveMind;
import org.apache.commons.hivemind.IModule;
+import org.apache.commons.lang.builder.ToStringBuilder;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.tapestry.ApplicationRuntimeException;
@@ -21,6 +22,23 @@
private static final Log LOG = LogFactory.getLog(AbstractConfigurator.class);
private String _propertyName;
+
+ public String toString()
+ {
+ ToStringBuilder builder = new ToStringBuilder(this);
+
+
cvs commit: jakarta-commons-sandbox/hivemind/xdocs descriptor.xml services.xml navigation.xml
hlship 2003/06/03 20:05:49 Modified:hivemind/xdocs services.xml navigation.xml Added: hivemind/xdocs descriptor.xml Log: Add docs on services and the module descriptor. Revision ChangesPath 1.2 +21 -12jakarta-commons-sandbox/hivemind/xdocs/services.xml Index: services.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/xdocs/services.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- services.xml 30 May 2003 20:52:02 - 1.1 +++ services.xml 4 Jun 2003 03:05:49 - 1.2 @@ -1,5 +1,12 @@ ?xml version=1.0? !-- $Id$ -- +!DOCTYPE document [ + +!ENTITY % common-links SYSTEM ../common/links.xml + +%common-links; + +] document properties @@ -34,7 +41,7 @@ /p p - A module descriptor may include a codelt;servicegt;/codeelement + A module descriptor may include service; element to define a emservice extension point/em. A service extension point establishes an id for the service, defines the interface for the service, and indicates whether the service is optional or required (required is the default). @@ -82,12 +89,12 @@ /p p - An instance creator is represented by a codegt;create-instancegt;/code element. + An instance creator is represented by a create-instance; element. It includes a codeclass/code attribute, the Java class to instantiate. /p p - An instance factory is represented by a codegt;factorygt;/code element. + An instance factory is represented by a codelt;factorygt;/code element. It includes a codeservice-id/code attribute. This is the fully qualfied id of a factory service, a service which implements the codeorg.apache.commons.hivemind.IFactory/code interface. @@ -96,10 +103,10 @@ p In both cases, the properties of the core instance may be configured using enclosed - codelt;setgt;/code - codelt;set-expressiongt;/code - codelt;set-creategt;/code and - codelt;set-factorygt;/code elements. + codeset;/code, + codeset-expression;/code, + codeset-create;/code and + codeset-factory;/code elements. /p /subsection @@ -107,7 +114,7 @@ subsection name=Interceptor Contributions p - An interceptor contribution is represented by a codelt;interceptorgt;/code element. + An interceptor contribution is represented by a interceptor; element. The codeservice-id/code attribute identifies an interceptor factory service: a service that implements the codeorg.apache.commons.hivemind.IInterceptorFactory/code interface. /p @@ -217,7 +224,7 @@ p -Its not absolutely required, but it is good form to explicitly state dependencies. Here, +Its not absolutely required, but it is good form, to explicitly state dependencies. Here, the module supplying the implementation is dependent on the module supplying the interface. /p @@ -258,7 +265,7 @@ Here the Logging interceptor is applied to the service extension point. The interceptor will be inserted between the client code and the core implementation. The client in the code example won't get an instance of the AdderImpl class, it will get an instance of - the interceptor, which internal invokes methods on the AdderImpl instance. Because + the interceptor, which internally invokes methods on the AdderImpl instance. Because we code against interfaces instead of implementations, the client code neither knows nor cares about this. /p @@ -293,7 +300,7 @@ p For required services, HiveMind checks for a factory contribution when the registry is constructed. If a required service extension point has no - contribution, and error is logged (identifying the extension point id). In addition, + contribution, an error is logged (identifying the extension point id). In addition, codegetService()/code will throw an ApplicationRuntimeException. So, if a service is required, you don't have to check for null. @@ -303,6 +310,8 @@ /section + + /body /document 1.2 +2 -1 jakarta-commons-sandbox/hivemind/xdocs/navigation.xml Index: navigation.xml === RCS file:
cvs commit: jakarta-commons-sandbox/hivemind/common - New directory
hlship 2003/06/03 20:08:22 jakarta-commons-sandbox/hivemind/common - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/common links.xml
hlship 2003/06/03 20:08:26 Modified:hivemind .cvsignore project.xml Added: hivemind/common links.xml Log: Add docs on services and the module descriptor. Revision ChangesPath 1.2 +1 -0 jakarta-commons-sandbox/hivemind/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore30 May 2003 20:52:01 - 1.1 +++ .cvsignore4 Jun 2003 03:08:26 - 1.2 @@ -1,2 +1,3 @@ target *.log +velocity.log* 1.2 +3 -11 jakarta-commons-sandbox/hivemind/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 30 May 2003 20:52:01 - 1.1 +++ project.xml 4 Jun 2003 03:08:26 - 1.2 @@ -45,15 +45,6 @@ /url /repository - versions -version - ida1/id - name1.0-alpha-1/name - tagHEAD/tag -/version - /versions - - developers developer @@ -85,7 +76,8 @@ /dependency dependency - idtapestry/id + idjakarta-tapestry/id + artifactIdtapestry/artifactId version3.0-beta-1/version urlhttp://jakarta.apache.org/tapestry//url /dependency 1.1 jakarta-commons-sandbox/hivemind/common/links.xml Index: links.xml === !ENTITY _module 'codelt;modulegt;/code' !ENTITY module 'a href=descriptor.html#module_module;/a' !ENTITY _service 'codelt;servicegt;/code' !ENTITY service 'a href=descriptor.html#service_service;/a' !ENTITY _create-instance 'codelt;create-instancegt;/code' !ENTITY create-instance 'a href=descriptor.html#create-instance_create-instance;/a' !ENTITY _factory 'codelt;factorygt;/code' !ENTITY factory 'a href=descriptor.html#factory_factory;/a' !ENTITY _set 'codelt;setgt;/code' !ENTITY set 'a href=descriptor.html#set_set;/a' !ENTITY _set-expression 'codelt;set-expressiongt;/code' !ENTITY set-expression 'a href=descriptor.html#set-expression_set-expression;/a' !ENTITY _set-create 'codelt;set-creategt;/code' !ENTITY set-create 'a href=descriptor.html#set-create_set-create;/a' !ENTITY _set-factory 'codelt;set-factorygt;/code' !ENTITY set-factory 'a href=descriptor.html#set-factory_set-factory;/a' !ENTITY _interceptor 'codelt;interceptorgt;/code' !ENTITY interceptor 'a href=descriptor.html#interceptor_interceptor;/a' !ENTITY _meta 'codelt;metagt;/code' !ENTITY meta 'a href=descriptor.html#meta_meta;/a' !ENTITY _description 'codelt;descriptiongt;/code' !ENTITY description 'a href=descriptor.html#description_description;/a' !ENTITY _dependency 'codelt;dependencygt;/code' !ENTITY dependency 'a href=descriptor.html#dependency_dependency;/a' !ENTITY _library 'codelt;librarygt;/code' !ENTITY library 'a href=descriptor.html#library_library;/a' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Re: [Docs] Component Lists
Seems reasonable to me. I will go ahead an make the change unless any of the jxpath committers have objections. Just curious, where are you looking for page views? Mike On Tuesday, June 3, 2003, at 10:50 PM, Tetsuya Kitahata wrote: On Tue, 3 Jun 2003 08:53:41 -0400 (Subject: Re: [PATCH] Re: [Docs] Component Lists) Michael Becke [EMAIL PROTECTED] wrote: I made the changes and updated the site for HttpClient. I left out the jxpath changes but would be happy to add them if others would like. Mike IMHO, I think it is better to change (add) the jxpath release notice, too ... as one of jxpath users. http://jakarta.apache.org/commons/components.html has as many access views next to http://jakarta.apache.org/commons/ , as statistics will show. If there's inconsistency in the components.html page, commons-users might be frustrated or irritated ... I think. Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.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]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat CertifiedDataTest.java
mdiggory2003/06/03 21:03:55
Modified:math/src/test/org/apache/commons/math/stat
CertifiedDataTest.java
Log:
Adjusted the code to be able to control the files used and the tolerance for each
file (important, hard tests currently require lower tolerance to pass).
Revision ChangesPath
1.5 +67 -59
jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/CertifiedDataTest.java
Index: CertifiedDataTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/stat/CertifiedDataTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CertifiedDataTest.java2 Jun 2003 05:21:06 - 1.4
+++ CertifiedDataTest.java4 Jun 2003 04:03:55 - 1.5
@@ -58,12 +58,9 @@
import junit.framework.TestSuite;
import java.io.BufferedReader;
-import java.io.File;
import java.io.FileNotFoundException;
-import java.io.FileReader;
-import java.io.FilenameFilter;
import java.io.IOException;
-import java.net.URL;
+import java.io.InputStreamReader;
import org.apache.commons.logging.*;
/**
* Test cases for the [EMAIL PROTECTED] Univariate} class.
@@ -74,10 +71,6 @@
public class CertifiedDataTest extends TestCase {
- protected double tolerance = .01;
-
- protected File[] dataFiles = null;
-
protected Univariate u = null;
protected double mean = Double.NaN;
@@ -98,15 +91,6 @@
* @see junit.framework.TestCase#setUp()
*/
public void setUp() {
- URL url = getClass().getResource(data);
- File file = new File(url.getFile());
-
- dataFiles = file.listFiles(new FilenameFilter() {
- public boolean accept(File dir, String name) {
- return name.endsWith(.txt);
- }
- });
-
}
/**
@@ -120,68 +104,92 @@
/**
* Test UnivariateImpl
-
+ */
public void testUnivariateImpl() {
- for (int i = 0; i dataFiles.length; i++) {
-
- u = new UnivariateImpl();
-
- loadStats(dataFiles[i]);
-
- assertEquals(
- dataFiles[i].getName() + :std,
- std,
- u.getStandardDeviation(),
- tolerance);
-
- assertEquals(
- dataFiles[i].getName() + :mean,
- mean,
- u.getMean(),
- tolerance);
+ u = new UnivariateImpl();
- }
+ loadStats(data/Lew.txt);
+ assertEquals(Lew: std, std, u.getStandardDeviation(), .0001);
+ assertEquals(Lew: mean, mean, u.getMean(), .0001);
+
+ loadStats(data/Lottery.txt);
+ assertEquals(Lottery: std, std, u.getStandardDeviation(),
.0001);
+ assertEquals(Lottery: mean, mean, u.getMean(), .0001);
+
+ loadStats(data/PiDigits.txt);
+ assertEquals(PiDigits: std, std, u.getStandardDeviation(),
.01);
+ assertEquals(PiDigits: mean, mean, u.getMean(), .01);
+
+ loadStats(data/Mavro.txt);
+ assertEquals(Mavro: std, std, u.getStandardDeviation(),
.01);
+ assertEquals(Mavro: mean, mean, u.getMean(), .01);
+
+ //loadStats(data/Michelso.txt);
+ //assertEquals(Michelso: std, std, u.getStandardDeviation(),
.01);
+ //assertEquals(Michelso: mean, mean, u.getMean(), .01);
+
+ loadStats(data/NumAcc1.txt);
+ assertEquals(NumAcc1: std, std, u.getStandardDeviation(),
.01);
+ assertEquals(NumAcc1: mean, mean, u.getMean(), .01);
+
+ //loadStats(data/NumAcc2.txt);
+ //assertEquals(NumAcc2: std, std, u.getStandardDeviation(),
.1);
+ //assertEquals(NumAcc2: mean, mean, u.getMean(), .01);
}
- */
+
/**
* Test UnivariateImpl
*/
public void testStoredUnivariateImpl() {
- for (int i = 0; i dataFiles.length; i++) {
-
- u = new StoreUnivariateImpl();
-
- loadStats(dataFiles[i]);
-
- assertEquals(
-
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat UnivariateImpl.java
mdiggory2003/06/03 21:05:39
Modified:math/src/java/org/apache/commons/math/stat
UnivariateImpl.java
Log:
Improved Variance calculation, test for negative variance and added some more
javadoc.
Revision ChangesPath
1.2 +65 -42
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/UnivariateImpl.java
Index: UnivariateImpl.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/UnivariateImpl.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UnivariateImpl.java 29 May 2003 20:35:45 - 1.1
+++ UnivariateImpl.java 4 Jun 2003 04:05:39 - 1.2
@@ -68,7 +68,7 @@
*
* @author Phil Steitz
* @author a href=mailto:[EMAIL PROTECTED]Tim O'Brien/a
- * @author Mark Diggory
+ * @author a href=mailto:[EMAIL PROTECTED]Mark Diggory/a
* @author Brent Worden
* @version $Revision$ $Date$
*
@@ -79,7 +79,7 @@
private int windowSize = Univariate.INFINITE_WINDOW;
/** Just in case, the windowSize is not inifinite, we need to
- * keep an array to remember values 0 to N
+ * keep an array to remember values 0 to N
*/
private DoubleArray doubleArray;
@@ -107,25 +107,30 @@
/** product of values that have been added */
private double product = Double.NaN;
-/** Creates new univariate */
+/** Creates new univariate with an inifinite window */
public UnivariateImpl() {
clear();
}
-/** Create a new univariate with a fixed window **/
+/** Creates a new univariate with a fixed window **/
public UnivariateImpl(int window) {
windowSize = window;
doubleArray = new FixedDoubleArray( window );
}
-public void addValue(double v) {
-
+/**
+ * @see org.apache.commons.math.stat.Univariate#addValue(double)
+ */
+ public void addValue(double v) {
insertValue(v);
}
-public double getMean() {
+/**
+ * @see org.apache.commons.math.stat.Univariate#getMean()
+ */
+ public double getMean() {
if (n == 0) {
return Double.NaN;
} else {
@@ -134,7 +139,10 @@
}
-public double getGeometricMean() {
+/**
+ * @see org.apache.commons.math.stat.Univariate#getGeometricMean()
+ */
+ public double getGeometricMean() {
if ((product = 0.0) || (n == 0)) {
return Double.NaN;
} else {
@@ -142,36 +150,44 @@
}
}
-
-public double getProduct() {
+/**
+ * @see org.apache.commons.math.stat.Univariate#getProduct()
+ */
+ public double getProduct() {
return product;
}
-
-public double getVariance() {
-double variance = Double.NaN;
-
-if( n == 1 ) {
-variance = 0.0;
-} else if( n 1 ) {
-double xbar = getMean();
-variance = (sumsq - xbar*xbar*((double) n))/(((double) n)-1);
-}
+ /**
+ * @see org.apache.commons.math.stat.Univariate#getStandardDeviation()
+ */
+ public double getStandardDeviation() {
+ double variance = getVariance();
+ if ((variance == 0.0) || (variance == Double.NaN)) {
+ return variance;
+ } else {
+ return Math.sqrt(variance);
+ }
+ }
+
+ /**
+ * Returns the variance of the values that have been added as described by
+ * a href=http://mathworld.wolfram.com/k-Statistic.htmlEquation (5) for
k-Statistics/a.
+ *
+ * @return The variance of a set of values. Double.NaN is returned for
+ * an empty set of values and 0.0 is returned for a lt;= 1 value set.
+ */
+ public double getVariance() {
+ double variance = Double.NaN;
-return variance;
-}
+ if( n == 1 ) {
+ variance = 0.0;
+ } else if( n 1 ) {
+ variance = (((double)n)*sumsq - (sum * sum)) / (double) (n *
(n - 1));
+ }
-
-public double getStandardDeviation() {
-double variance = getVariance();
-if ((variance == 0.0) || (variance == Double.NaN)) {
-return variance;
-} else {
-return Math.sqrt(variance);
-}
-}
-
-
+ return variance 0 ? 0.0 : variance;
+ }
+
/**
* Returns the skewness of the values that have been added as described by
* a href=http://mathworld.wolfram.com/k-Statistic.htmlEquation
Re: [PATCH] Re: [Docs] Component Lists
Hi, Mike. On Tue, 3 Jun 2003 23:42:39 -0400 (Subject: Re: [PATCH] Re: [Docs] Component Lists) Michael Becke [EMAIL PROTECTED] wrote: Seems reasonable to me. I will go ahead an make the change unless any of the jxpath committers have objections. Just curious, where are you looking for page views? Haha. I omitted to explain more details. Well, I am translating the Jakarta-Commons site as well as other projects into Japanese (you can see at http://jakarta.terra-intl.com/commons/), and I am taking the statistics on this site. And, I found that the componentslist page had as many page views next to commons/index.html. Given that the translated site's statistics are also alike to the site's statistics in apache.org, I had come to the conclusion that http://jakarta.apache.org/commons/components.html has as many page views next to http://jakarta.apache.org/commons/; -- BTW, here's an useful information, Mike. If you want to know the whole stats of the apache.org, see http://www.apache.org/~vgritsenko/stats/index.html (Vadim's Home Page) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] What's left for 2.0 (WAS: [collections] Primitive collecti ons (was Entities and LGPL))
Would it make sense to layer [collections] on top of [lang], in the same manner that Xalan is layered on and includes Xerces in it's distribution? The most basic of collection-like things could be in [lang] for example; I am not fond of this either but what are our options? Don't throw ripe fruit at me if you consider this heresy s.v.p. ;-) More heresy here - ultimately I think it will be futile or very awkward to maintain independence. Being that [lang] is supposed to be a core set of utilities, it is reasonable that other libraries depend upon it. What happens if two commons subprojects both need a particular function? I believe there are only three possibilities: 1. replicate the code in both - widely held to be a bad idea. 2. put the code in one of the libraries, and reference that library from the other. This can obviously lead to libraries having multiple dependencies on each other, so this isn't a viable proposition. 3. put the code in a common 'core' library, i.e. [lang], that both libraries can reference. I think that sooner or later we're going to have to bite the bullet on this one, and that [collections] will end up with dependencies on [lang]. No rotten fruit here either, please! - Neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Add Al Chou as contributor
I think that Al Chou should be added to the list of contributors to commons-math. Al has provided useful patches and great suggestions for improvement and advice on implementation strategies. Tim/Mark/Robert: if you agree, can one of you update project.xml? I was going to submit a patch, but though it better to post to the list. One more thing: the web site on jakarta.apache.org is a couple of revs out of date. My awe at the power of maven wanes a little when I see that ;-). Is it just a matter of one of you guys manually firing maven site:deploy Shouldn't the nightly kick this off? How does this work for the other jakarta sites? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[fileiupload] Remodeling of parseRequest?
I REALLY like the FileUpload tool - have had great success with RC1, and look forward to a production release. However, I'm curious if the possibility of making the API model more consistent with the Request model of the Servlet API. There are a couple of things that I think would be handy in this regard: 1) For FileUpload to have getParemeter(String name) or getParameterValues(String name) - I think this can be implemented on top of the current API so that there are no backward-compatibility issues. 2) At LEAST working out a kink (IMHO) where multi-valued parameters actually appear as separate FileItems with the same value returned by getFieldName(). I suppose what I propose would look something like this: DiskFileUpload upload = new DiskFileUpload(); // Now, rather than applying an Iterator to parseRequest, // we still call the same method, // but pull the individual items from the // DiskFileUpload object itself upload.parseRequest(request); FileItem myfile = (FileItem)upload.getParameter(myfile); // And this looks ALMOST like ServletRequest.getParameter(String name) String lastname = (String)upload.getParameter(lastname); String[] favoriteColours = upload.getParameterValues(favoritecolours); Alternately, a getFileItem(String name) method could be added in order to shield the user from having to cast the result of getParameter(String name) to a FileItem - and this same method could wrap ordinary field values in FileItems similarly to the way they are returned in the Iterator. I don't know if this possibility has been discussed or sounds useful to anybody else. I'll be happy to contribute where I can if there is any other interest in this change. Regards, Will Stranathan _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] more improvement to storage free mean, variance computation
Check out procedure sum.2 and var.2 in http://www.stanford.edu/~glynn/PDF/0208.pdf The first looks like Brent's suggestion for a corrected mean computation, with no memory required. The additional computational cost that I complained about is docuemented to be 3x the flops cost of the direct computation, but the computation is claimed to be more stable. So the question is: do we pay the flops cost to get the numerical stability? The example in the paper is compelling; but it uses small words (err, numbers I mean -- sorry, slipped in to my native Fortran for a moment there ;-)). So how do we go about deciding whether the stability in the mean computation is worth the increased computational effort? I would prefer not to answer let the user decide. To make the decision harder, we should note that it is actually worse than 3x, since in the no storage version, the user may request the mean only rarely (if at all) and the 3x comparison is against computiing the mean for each value added. The variance formula looks better than what we have now, still requiring no memory. Should we implement this for the no storage case? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] fileupload 1.0 RC 1 API breakage
FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
Martin Cooper wrote: I posted a patch to the Tomcat-Dev list yesterday which should fix this problem. Apparently, nobody on the Tomcat-Dev list paid any attention to my post. The methods in question have been deprecated for some time. I have not seen the patch email on tomcat-dev. Perhaps its in the moderator queue. BTW, use of FileUpload was implemented in Tomcat once there was a Beta release of FileUpload. So the API must have changed since the Beta release. I have gone out of my way to help FileUpload clients avoid exactly this kind of issue. It really ticks me off to see this kind of message, when I have gone to great lengths to make sure that the clients I know about are made aware of the changes before they happen. Thats great that you performed notifications to known clients. :-) Somehow Tomcat slipped through the cracks. :-( I don't recall seeing anything about this on the Tomcat list. I wlll admit that I subscribe to commons-dev but often don't keep up with messages related to the code bases there I am interested in. Get your own act together, Tomcat developers, before you start pointing the finger at those of us who really try hard to maintain compatibility across Jakarta projects. Was this really necessary? The email below went to both the commons-dev and tomcat -dev lists. If Remy was pointing the finger at anyone, it was at his fellow Tomcat Developers. Thats how I interpreted it. We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal. Regards, Glenn -- Martin Cooper On Wed, 4 Jun 2003, Remy Maucherat wrote: FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... Remy - 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]
DO NOT REPLY [Bug 20335] - There is no way to change RESPONSE_WAIT_TIME_MS programmatically
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20335. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20335 There is no way to change RESPONSE_WAIT_TIME_MS programmatically [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 15:19 --- I believe this report can be closed as HttpClient does provide a way to programmatically set read timeout value. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17569] - Include generated website in the distribution
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17569. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17569 Include generated website in the distribution [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|2.0 Beta 1 |2.0 Beta 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20451] New: - HttpMethodBase.checkValidRedirects() is too restrictive
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20451 HttpMethodBase.checkValidRedirects() is too restrictive Summary: HttpMethodBase.checkValidRedirects() is too restrictive Product: Commons Version: 2.0 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Surely it should be possible to redirect from http - https? This should be enabled by default, or at least user configurable through properties files or subclassing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20451] - HttpMethodBase.checkValidRedirects() is too restrictive
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20451 HttpMethodBase.checkValidRedirects() is too restrictive [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 15:45 --- This is a well-known issue caused by a pretty serious design flaw, which, unfortunately, cannot be fixed without breaking the existing API. The bug will be addressed in the 2.1 release. Sorry Oleg *** This bug has been marked as a duplicate of 16729 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10809] - Developer documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809 Developer documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 21:02 --- Oleg, Changes to the cookie spec look good to me. Thanks for checking that over. We should definitely commit and redeply the website as soon as it's next convienient. There are now a few changes waiting to be deployed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10809] - Developer documentation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809 Developer documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 21:31 --- Thanks, Adrian. Patch committed. Welcome to the Fellowship, by the way Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 10809] - Developer documentation
The site has been redeployed. Mike On Tuesday, June 3, 2003, at 05:02 PM, [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809 Developer documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 21:02 --- Oleg, Changes to the cookie spec look good to me. Thanks for checking that over. We should definitely commit and redeply the website as soon as it's next convienient. There are now a few changes waiting to be deployed. - 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]
