[jira] [Created] (MATH-568) Code in Userguide for Statistics wrong or deprecated
Code in Userguide for Statistics wrong or deprecated
-
Key: MATH-568
URL: https://issues.apache.org/jira/browse/MATH-568
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Environment: windows 7
Reporter: Christoph M. Friedrich
Priority: Trivial
The code for the Statistics examples is not running and can easily be fixed.
Example:
// Get a DescriptiveStatistics instance
DescriptiveStatistics stats = new DescriptiveStatistics();
// Add the data from the array
for( int i = 0; i inputArray.length; i++) {
stats.addValue(inputArray[i]);
}
// Compute some statistics
double mean = stats.getMean();
double std = stats.getStandardDeviation();
double median = stats.getMedian();
Fails with getMedian not found, change to getPercentile(50);
The second Codeexample for StatuUtils states:
// Compute statistics directly from the array
// assume values is a double[] array
double mean = StatUtils.mean(values);
double std = StatUtils.variance(values);
double median = StatUtils.percentile(50);
the last line needs to be changed to: double median =
StatUtils.percentile(values,50);
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-271) FileUtils.copyDirectory should be able to handle arbitrary number of files
[ https://issues.apache.org/jira/browse/IO-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030354#comment-13030354 ] Sebb commented on IO-271: - If using String[] list() instead of File[] listFile(): * when using a filter, each String has to be turned into a File. * the copy stage also requires the String to be turned into a File. Using String[] does reduce the maximum memory requirements as the File lifetime is very short. However in the filtered case it can double the number of File instances that need to be created. Also, the listFiles() methods are more efficient, because they take advantage of the fact that the list() entries have already been normalised. I'm not sure these trade-offs are worth it for the general case. FileUtils.copyDirectory should be able to handle arbitrary number of files -- Key: IO-271 URL: https://issues.apache.org/jira/browse/IO-271 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.0.1 Reporter: Stephen Kestle Priority: Minor File.listFiles() uses up to a bit over 2 times as much memory as File.list(). The latter should be used in doCopyDirectory where there is no filter specified. This memory usage is a problem when copying directories with hundreds of thousands of files. I was also thinking of the option of implementing a file filter (that could be composed with the inputted filter) that would batch the file copy operation; copy the first 1 (that match), then the next 1 etc etc. Because of the lack of ordering consistency (between runs) of File.listFiles(), there would need to be a final file filter that would accept files that have not successfully been copied. I'm primarily concerned about copying into an empty directory (I validate this beforehand), but for general operation where it's a merge, the modification date re-writing should only be done in the final run of copies so that while batching occurs (and indeed the final missed filtering) files do not get copied if they have been modified after the start time. (I presume that I'm reading FileUtils correctly in that it overrides files...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-375) Provide static methods to simplify usage of BeanToPropertyValueTransformer with CollectionUtils
[
https://issues.apache.org/jira/browse/BEANUTILS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030430#comment-13030430
]
Ondra Žižka commented on BEANUTILS-375:
---
I would like to have this implemented.
1) IMO that's the most often use case, would be used a lot.
{quote}
It doesn't really add much benefit - it will just mean one line of your code is
slightly shorter
{quote}
Well, that's the purpose of commons, isn't it? To save people from writing
boilerplate code.
You can write whole application to one line. What is the limit of slightly?
It's not about the length of line, it's about making the code more readable.
When someone decides to use {{BeanToPropertyValueTransformer)}, then he usually
uses it several times in a class.
Removing all occurences of this ugly long name would help improve readability.
Please reconsider this.
Provide static methods to simplify usage of BeanToPropertyValueTransformer
with CollectionUtils
---
Key: BEANUTILS-375
URL: https://issues.apache.org/jira/browse/BEANUTILS-375
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean-Collections
Affects Versions: 1.8.3
Reporter: Tomasz Nurkiewicz
Priority: Trivial
Attachments: BeanToPropertyValueTransformer.java
Provide static {{BeanToPropertyValueTransformer#collect}} methods to simplify
the usage of {{BeanToPropertyValueTransformer}} with
{{CollectionUtils#collect}}. See attached implementation. This is how such a
utility method could be used (pay attention to static import):
{code}import org.junit.Test;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.Locale;
import static
org.apache.commons.beanutils.BeanToPropertyValueTransformer.collect;
import static org.fest.assertions.Assertions.assertThat;
public class TestCollect {
@Test
public void proofOfConcept() throws Exception {
//given
ListLocale locales = Arrays.asList(
Locale.FRANCE,
Locale.GERMANY,
Locale.ITALY,
new Locale(pl, PL));
//when: calls Locale.getCounty() on each item
Collection countries = collect(locales, country);
//then
assertThat(countries).containsOnly(FR, DE, IT, PL);
}
}{code}
Without proposed method:
{code}Collection countries = CollectionUtils.collect(locales, new
BeanToPropertyValueTransformer(country)){code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (BEANUTILS-375) Provide static methods to simplify usage of BeanToPropertyValueTransformer with CollectionUtils
[
https://issues.apache.org/jira/browse/BEANUTILS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030430#comment-13030430
]
Ondra Žižka edited comment on BEANUTILS-375 at 5/7/11 11:57 PM:
I would like to have this implemented.
1) IMO that's the most often use case, would be used a lot.
{quote}
It doesn't really add much benefit - it will just mean one line of your code is
slightly shorter
{quote}
Well, that's the purpose of commons, isn't it? To save people from writing
boilerplate code.
You can write whole application to one line. What is the limit of slightly?
It's not about the length of line, it's about making the code more readable.
When someone decides to use {{BeanToPropertyValueTransformer}}, then he usually
uses it several times in a class.
Removing all occurrences of this ugly long name would help improve readability.
Please reconsider this.
was (Author: pekarna):
I would like to have this implemented.
1) IMO that's the most often use case, would be used a lot.
{quote}
It doesn't really add much benefit - it will just mean one line of your code is
slightly shorter
{quote}
Well, that's the purpose of commons, isn't it? To save people from writing
boilerplate code.
You can write whole application to one line. What is the limit of slightly?
It's not about the length of line, it's about making the code more readable.
When someone decides to use {{BeanToPropertyValueTransformer)}, then he usually
uses it several times in a class.
Removing all occurences of this ugly long name would help improve readability.
Please reconsider this.
Provide static methods to simplify usage of BeanToPropertyValueTransformer
with CollectionUtils
---
Key: BEANUTILS-375
URL: https://issues.apache.org/jira/browse/BEANUTILS-375
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean-Collections
Affects Versions: 1.8.3
Reporter: Tomasz Nurkiewicz
Priority: Trivial
Attachments: BeanToPropertyValueTransformer.java
Provide static {{BeanToPropertyValueTransformer#collect}} methods to simplify
the usage of {{BeanToPropertyValueTransformer}} with
{{CollectionUtils#collect}}. See attached implementation. This is how such a
utility method could be used (pay attention to static import):
{code}import org.junit.Test;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.Locale;
import static
org.apache.commons.beanutils.BeanToPropertyValueTransformer.collect;
import static org.fest.assertions.Assertions.assertThat;
public class TestCollect {
@Test
public void proofOfConcept() throws Exception {
//given
ListLocale locales = Arrays.asList(
Locale.FRANCE,
Locale.GERMANY,
Locale.ITALY,
new Locale(pl, PL));
//when: calls Locale.getCounty() on each item
Collection countries = collect(locales, country);
//then
assertThat(countries).containsOnly(FR, DE, IT, PL);
}
}{code}
Without proposed method:
{code}Collection countries = CollectionUtils.collect(locales, new
BeanToPropertyValueTransformer(country)){code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-375) Provide static methods to simplify usage of BeanToPropertyValueTransformer with CollectionUtils
[
https://issues.apache.org/jira/browse/BEANUTILS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030431#comment-13030431
]
Ondra Žižka commented on BEANUTILS-375:
---
I'd also suggest to allow voting on resolved / closed issues.
Provide static methods to simplify usage of BeanToPropertyValueTransformer
with CollectionUtils
---
Key: BEANUTILS-375
URL: https://issues.apache.org/jira/browse/BEANUTILS-375
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean-Collections
Affects Versions: 1.8.3
Reporter: Tomasz Nurkiewicz
Priority: Trivial
Attachments: BeanToPropertyValueTransformer.java
Provide static {{BeanToPropertyValueTransformer#collect}} methods to simplify
the usage of {{BeanToPropertyValueTransformer}} with
{{CollectionUtils#collect}}. See attached implementation. This is how such a
utility method could be used (pay attention to static import):
{code}import org.junit.Test;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.Locale;
import static
org.apache.commons.beanutils.BeanToPropertyValueTransformer.collect;
import static org.fest.assertions.Assertions.assertThat;
public class TestCollect {
@Test
public void proofOfConcept() throws Exception {
//given
ListLocale locales = Arrays.asList(
Locale.FRANCE,
Locale.GERMANY,
Locale.ITALY,
new Locale(pl, PL));
//when: calls Locale.getCounty() on each item
Collection countries = collect(locales, country);
//then
assertThat(countries).containsOnly(FR, DE, IT, PL);
}
}{code}
Without proposed method:
{code}Collection countries = CollectionUtils.collect(locales, new
BeanToPropertyValueTransformer(country)){code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
