[
https://issues.apache.org/jira/browse/MATH-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981240#action_12981240
]
Patrick Meyer commented on MATH-473:
------------------------------------
I think you might encounter problems with the cumulative count and percentages
if there is no sorting. Your data may only be nominal and thus have no need for
sorting, but I think the changes would require more than switching between a
TreeMap and HashMap. Specifically, thought would need to be given to the
cumulative count and percentage methods. In terms of performance, I don't think
there would be a perceptible difference between a TreeMap and a HashMap.
Also, I think you could simply write your own class that implements the
comparable interface. That way you could define any type of sorting you would
like.
> Frequency: new option: NON-sorted
> ---------------------------------
>
> Key: MATH-473
> URL: https://issues.apache.org/jira/browse/MATH-473
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Dan Checkoway
>
> I have a request for enhancement on org.apache.commons.math.stat.Frequency.
> I would like to be able to specify that the the backing map NOT be sorted.
> Right now it uses TreeMap. I would like to have the option of specifying
> that sorting is not important, and would in fact hinder performance, and a
> plain old HashMap should be used instead.
> i.e. constructor such as:
> public Frequency(boolean sorted);
> If sorted is true, use a TreeMap. If sorted is false, use a HashMap. Is
> this feasible? I'd be happy to contribute a patch if that would help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
