Re: [beanutils] commons collection classes
Now this is the part that I don't understand. Why would that have been an incompatible change? The changes should have been internal to beanutils. Because BeanUtils exposes FastHashMap in its public API (and Digester does the same with ArrayStack) - its the return type from four methods. Ahhh ...bugger! The bad news was that an implementation (rather than Map) was exposed in the API in the first place. It does seem pretty minor to me changing that API from FastHashMap -- Map in only 4 places that probably aren't used outside BeanUtils. Having said that - the current situation has been in place for over 2 years and there haven't been complaints until now. Just out of interest which of the 4 classes caused you a problem? I was tracking down classpath clashes in other areas and basically just did a full check ...and just came across this. I think people are just no aware they are using the old version provided by beanutils. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote: Stephen Colebourne skrev den 18-05-2007 18:37: Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. I agree that it is important, actually crucial. People trust in these modules, and _if_ they break something when upgrading it is very prominently displayed on the download page etc. I think it would be a bad idea to deliberatly introduce such things. I suggest marking the offending methods as deprecated for the 1.x series, and schedule them for removal in the 2.x series. Well, then let's create a 2.x branch and do a release without the classes *now*. No problem with that. Then it is communicated and people can choose. But doing *nothing* just because of binary compatibility is silly. Especially as no one *has* to upgrade libraries. And checking release notes if you do can't hurt if you upgrade. Just let's get rid of this mess. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 17/05/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 5/17/07, sebb [EMAIL PROTECTED] wrote: The site report page http://people.apache.org/~jochen/commons-io/site/project-reports.html says that the RAT report is a Report on binary and source API differences between releases That's a bug in the rat-maven-plugin and cannot easily be fixed now. Sorry, OK, in that case, perhaps the text could be changed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons compress status?
On 18.05.2007, at 19:17, Bear Giles wrote: Torsten Curdt wrote: Hm... seems like I disagree here. I want a simple library that deals with common compression and archive formats - tar - ar - cpio - gzip - bzip2 - zip VFS is a filesystem abstraction layer. It may use the library but should not provide the implementation IMO. Compression and archive are really only related by a USES relationship and there's no reason why they -have- to remain in the same package. But they are so often used in the same context that I would argue it's a not worth splitting this up into separate libraries. Especially as the JDK already provides the basic implementations of some of the compressors. CAB (windows) is an additional format, sure ...let's add it :) and you can make an argument for the Debian and Red Hat package formats as well. Debian is using ar and tgz. Just the structure of the archive makes it a Debian package. Not exactly sure about RPMs. ...but where is your point? I am not saying we can't add other implementations. Only that a separation would be a bit artificial. Plus the two things have to work together very well from the API point of view. Having this in one library would make sure that this is the case. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 10:44, Jochen Wiedmann wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. I do think, that introducing a new deployment mechanism is a larger disruption than the changes made so far in 3-SNAPSHOT. In other words, I'd prefer to see this in a separate release. Apart from that, what prevents us from publishing version 3 now and a version 4, if the above questions are resolved? I do not understand this oh, just wait until I've got my favourite feature in whenever it comes to a release of the commons-parent. This thing doesn't need exhaustive QA or something like that, and it's not like we weren't able to manage 12 releases of it every year. I am with you on the release often ...but I on the other hand fixating the plugin versions and a working release setup is a bit of blocker for me ATM. So if you want to release now - fine. But I'd like to have another release that fixes those things ASAP anyway. So I was just wondering whether waiting a few more days would make such a big difference. I agree that we need to specify the plugin versions. If not in the parent, then the individual poms are going to have to do it (in which case, I don't know if there is value in specifying things in the parent. Could be ignorance here - are the plugin settings merged somehow?) The important requirement IMO is that anything that we release has a (perpetually) repeatable source build, both from the source distro and the svn tag. If we release something that has only an m2 build and does not specify plugin versions, we risk breaking that. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
Torsten Curdt wrote: On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote: I suggest marking the offending methods as deprecated for the 1.x series, and schedule them for removal in the 2.x series. Well, then let's create a 2.x branch and do a release without the classes *now*. No problem with that. Then it is communicated and people can choose. But doing *nothing* just because of binary compatibility is silly. Doing nothing because of binary incompatibility is not silly, its essential. Commons has to be far more extreme than almost any other OSS project on this point. In fact, I contend that commons is now in such a position that we can't make incompatible changes even in major version number releases. Especially as no one *has* to upgrade libraries. And checking release notes if you do can't hurt if you upgrade. Users are forced to upgrade all the time, and thats why they require backwards compatibility. For example, if project A is complied against the old [beanutils] jar, while project B is compiled against the new [beanutils] jar, then it is impossible to use both project A and project B together. You cannot physically upgrade the jar file to the one B needs, because A needs the old one. The only solutions to this at present are - for the 2.x series to have a different package name, including 'v2' - to force the user to play with class loaders, so they can load two different versions of the same class In summary, I suggest we all just let this one be. This isn't causing major pain IMO. The lesson should be to not have dependencies between commons projects wherever possible. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
I would expect a JDK change to be a major version number change. Stephen Gary Gregory wrote: It seems like a nice coincidence that IO 1.3 is based on JRE 1.3, and we could have IO 1.4 based on JRE 1.4, IO 1.5 on JRE 1.5 ;) Thank you, Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 1:10 PM To: Jakarta Commons Developers List Subject: Re: [IO] Move to a minimum of JDK 1.4? On 5/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? snip/ Sounds good. I've read the rest of the thread -- probably good to branch regardless of whether both lines are under active (evolutionary, in my mind) development or not. If someone shows up with desire to do a point / bugfix release for JDK 1.3 etc. -Rahul Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - 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]
[jira] Created: (BEANUTILS-279) Allowing Multiple Converters Per Destination Class
Allowing Multiple Converters Per Destination Class -- Key: BEANUTILS-279 URL: https://issues.apache.org/jira/browse/BEANUTILS-279 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0, 1.8.0 Reporter: Bradley M. Handy Priority: Minor Attachments: ConvertUtils-1.7.0-patch.tgz Currently only one Converter may be registered per destination class. It may be prudent for an application to have the ability to use multiple named Converter instances to convert values to a destination type. By adding a second-level Map keyed by Converter name, this can be accomplished without affecting existing behavior. A default name is used for the default Converter which will allow for emulation of the previous single Converter implementation. Patch files for both BeanUtils 1.7.0 and the current Head revision of the affected files has been provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-279) Allowing Multiple Converters Per Destination Class
[ https://issues.apache.org/jira/browse/BEANUTILS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bradley M. Handy updated BEANUTILS-279: --- Attachment: ConvertUtils-1.7.0-patch.tgz Patch files for BeanUtils 1.7.0 codebase. Allowing Multiple Converters Per Destination Class -- Key: BEANUTILS-279 URL: https://issues.apache.org/jira/browse/BEANUTILS-279 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0, 1.8.0 Reporter: Bradley M. Handy Priority: Minor Attachments: ConvertUtils-1.7.0-patch.tgz Currently only one Converter may be registered per destination class. It may be prudent for an application to have the ability to use multiple named Converter instances to convert values to a destination type. By adding a second-level Map keyed by Converter name, this can be accomplished without affecting existing behavior. A default name is used for the default Converter which will allow for emulation of the previous single Converter implementation. Patch files for both BeanUtils 1.7.0 and the current Head revision of the affected files has been provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-279) Allowing Multiple Converters Per Destination Class
[ https://issues.apache.org/jira/browse/BEANUTILS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bradley M. Handy updated BEANUTILS-279: --- Attachment: ConvertUtils-20070519-patch.tgz Patch files for BeanUtils codebase as of 6:00PM GMT-0500 on 2007-05-19. Allowing Multiple Converters Per Destination Class -- Key: BEANUTILS-279 URL: https://issues.apache.org/jira/browse/BEANUTILS-279 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0, 1.8.0 Reporter: Bradley M. Handy Priority: Minor Attachments: ConvertUtils-1.7.0-patch.tgz, ConvertUtils-20070519-patch.tgz Currently only one Converter may be registered per destination class. It may be prudent for an application to have the ability to use multiple named Converter instances to convert values to a destination type. By adding a second-level Map keyed by Converter name, this can be accomplished without affecting existing behavior. A default name is used for the default Converter which will allow for emulation of the previous single Converter implementation. Patch files for both BeanUtils 1.7.0 and the current Head revision of the affected files has been provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-279) Allowing Multiple Converters Per Destination Class
[ https://issues.apache.org/jira/browse/BEANUTILS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-279: -- Fix Version/s: LATER THAN 1.8.0 Affects Version/s: (was: 1.8.0) Allowing Multiple Converters Per Destination Class -- Key: BEANUTILS-279 URL: https://issues.apache.org/jira/browse/BEANUTILS-279 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0 Reporter: Bradley M. Handy Priority: Minor Fix For: LATER THAN 1.8.0 Attachments: ConvertUtils-1.7.0-patch.tgz, ConvertUtils-20070519-patch.tgz Currently only one Converter may be registered per destination class. It may be prudent for an application to have the ability to use multiple named Converter instances to convert values to a destination type. By adding a second-level Map keyed by Converter name, this can be accomplished without affecting existing behavior. A default name is used for the default Converter which will allow for emulation of the previous single Converter implementation. Patch files for both BeanUtils 1.7.0 and the current Head revision of the affected files has been provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539812 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/converters/ArrayConverter.java test/org/apache/commons/beanutils/converters/ArrayConverterTestCa
Author: niallp
Date: Sat May 19 18:13:29 2007
New Revision: 539812
URL: http://svn.apache.org/viewvc?view=revrev=539812
Log:
BEANUTILS-242 - number of small improvements:
- add handling for conversion to String of Collections and non-arrays
- make conversion to String configurable (either first element or delimited
list)
- improve conversion to array for primitive and date values
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/ArrayConverter.java
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ArrayConverterTestCase.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/ArrayConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/ArrayConverter.java?view=diffrev=539812r1=539811r2=539812
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/ArrayConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/ArrayConverter.java
Sat May 19 18:13:29 2007
@@ -105,6 +105,7 @@
private int defaultSize;
private char delimiter= ',';
private char[] allowedChars = new char[] {'.', '-'};
+private boolean onlyFirstToString = true;
// --- Constructors
@@ -171,6 +172,19 @@
}
/**
+ * Indicates whether converting to a String should create
+ * a delimited list or just convert the first value.
+ *
+ * @param onlyFirstToString codetrue/code converts only
+ * the first value in the array to a String, codefalse/code
+ * converts all values in the array into a delimited list (default
+ * is codetrue/code
+ */
+public void setOnlyFirstToString(boolean onlyFirstToString) {
+this.onlyFirstToString = onlyFirstToString;
+}
+
+/**
* Convert the input object into a String.
*
* @param value The value to be converted.
@@ -178,25 +192,35 @@
*/
protected String convertToString(Object value) {
+int size = 0;
+Iterator iterator = null;
Class type = value.getClass();
-if (!type.isArray()) {
-throw new ConversionException(toString(getClass())
-+ cannot handle conversion from '
-+ toString(type) + ' to String (not an array).);
+if (type.isArray()) {
+size = Array.getLength(value);
+} else if (value instanceof Collection) {
+Collection collection = (Collection)value;
+size = collection.size();
+iterator = collection.iterator();
+} else {
+Object converted = elementConverter.convert(String.class, value);
+return (converted == null ? (String)getDefault(String.class) :
converted.toString());
}
-int size = Array.getLength(value);
if (size == 0) {
return (String)getDefault(String.class);
}
+if (onlyFirstToString) {
+size = 1;
+}
+
// Create a StringBuffer containing a delimited list of the values
StringBuffer buffer = new StringBuffer();
for (int i = 0; i size; i++) {
if (i 0) {
buffer.append(delimiter);
}
-Object element = Array.get(value, i);
+Object element = iterator == null ? Array.get(value, i) :
iterator.next();
element = elementConverter.convert(String.class, element);
if (element != null) {
buffer.append(element);
@@ -230,12 +254,7 @@
if (value.getClass().isArray()) {
size = Array.getLength(value);
} else {
-Collection collection = null;
-if (value instanceof Collection) {
-collection = (Collection)value;
-} else {
-collection = parseElements(type, value.toString().trim());
-}
+Collection collection = convertToCollection(type, value);
size = collection.size();
iterator = collection.iterator();
}
@@ -254,6 +273,28 @@
}
return newArray;
+}
+
+/**
+ * Convert an Object into a Collection.
+ *
+ * @param type The type to convert the value to
+ * @param value value to be converted
+ * @return List of parsed elements.
+ */
+protected Collection convertToCollection(Class type, Object value) {
+if (value instanceof Collection) {
+return (Collection)value;
+}
+if (value instanceof Number ||
+value instanceof Boolean ||
+value instanceof java.util.Date) {
+List list = new ArrayList(1);
+
svn commit: r539828 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/BeanUtilsBean.java test/org/apache/commons/beanutils/BeanUtilsTestCase.java
Author: niallp
Date: Sat May 19 22:10:08 2007
New Revision: 539828
URL: http://svn.apache.org/viewvc?view=revrev=539828
Log:
BEANUTILS-110 - revert to the original suggestion from Etienne Bernard to
resolve the second issue with this bug
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtilsBean.java
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanUtilsTestCase.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtilsBean.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtilsBean.java?view=diffrev=539828r1=539827r2=539828
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtilsBean.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtilsBean.java
Sat May 19 22:10:08 2007
@@ -556,13 +556,7 @@
return (results);
} else {
String results[] = new String[1];
-try {
-Class type = results.getClass();
-Converter converter = getConvertUtils().lookup(type);
-results = (String[])converter.convert(type, value);
-} catch (Exception e) {
-results[0] = value.toString();
-}
+results[0] = getConvertUtils().convert(value);
return (results);
}
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanUtilsTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanUtilsTestCase.java?view=diffrev=539828r1=539827r2=539828
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanUtilsTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanUtilsTestCase.java
Sat May 19 22:10:08 2007
@@ -418,15 +418,10 @@
// Test comma delimited list
String value1 = ABC;
-String value2 = DEF;
-String value3 = GHK;
-String delimitedList = value1 + , + value2 + , + value3;
-bean.setStringProperty(delimitedList);
+bean.setStringProperty(ABC);
arr = BeanUtils.getArrayProperty(bean, stringProperty);
-assertEquals(Delimited List Test lth, 3, arr.length);
-assertEquals(Delimited List Test value1, value1, arr[0]);
-assertEquals(Delimited List Test value2, value2, arr[1]);
-assertEquals(Delimited List Test value3, value3, arr[2]);
+assertEquals(Delimited List Test lth, 1, arr.length);
+assertEquals(Delimited List Test value1, ABC, arr[0]);
} catch (IllegalAccessException e) {
fail(IllegalAccessException);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539829 - /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
Author: psteitz
Date: Sat May 19 22:45:54 2007
New Revision: 539829
URL: http://svn.apache.org/viewvc?view=revrev=539829
Log:
eliminated unnecessary Double creation.
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?view=diffrev=539829r1=539828r2=539829
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
Sat May 19 22:45:54 2007
@@ -558,7 +558,7 @@
public static double round(double x, int scale, int roundingMethod) {
try {
return (new BigDecimal
- (new Double(x).toString())
+ (Double.toString(x))
.setScale(scale, roundingMethod))
.doubleValue();
} catch (NumberFormatException ex) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539830 - in /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random: RandomVectorGenerator.java UncorrelatedRandomVectorGenerator.java
Author: psteitz
Date: Sat May 19 22:48:00 2007
New Revision: 539830
URL: http://svn.apache.org/viewvc?view=revrev=539830
Log:
Javadoc only.
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/RandomVectorGenerator.java
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/RandomVectorGenerator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/RandomVectorGenerator.java?view=diffrev=539830r1=539829r2=539830
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/RandomVectorGenerator.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/RandomVectorGenerator.java
Sat May 19 22:48:00 2007
@@ -17,7 +17,7 @@
package org.apache.commons.math.random;
-/** This interface represent a random generator for whole vectors.
+/** This interface represents a random generator for whole vectors.
* @version $Id: RandomVectorGenerator.java 1705 2006-09-17 19:57:39Z luc $
* @author L. Maisonobe
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java?view=diffrev=539830r1=539829r2=539830
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java
Sat May 19 22:48:00 2007
@@ -19,8 +19,12 @@
import java.util.Arrays;
-/** This class allows to generate random vectors with uncorrelated components.
- * @version $Id:$
+/**
+ * A [EMAIL PROTECTED] RandomVectorGenerator} that generates vectors with
uncorrelated
+ * components. Components of generated vectors follow (independent) Gaussian
+ * distributions, with parameters supplied in the constructor.
+ *
+ * @version $Revision$
*/
public class UncorrelatedRandomVectorGenerator
@@ -60,7 +64,7 @@
this.generator = generator;
}
- /** Generate a correlated random vector.
+ /** Generate an uncorrelated random vector.
* @return a random vector as a newly built array of double
*/
public double[] nextVector() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
