Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sat, 7 Jun 2014 16:06:01 +0000 (UTC)
From: "Gilles (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12713154.1399575099993.87607.1402157161806@arcas>
In-Reply-To: <JIRA.12713154.1399575099993@arcas>
References: <JIRA.12713154.1399575099993@arcas>
Subject: [jira] [Commented] (MATH-1120) Need Percentile computations that
 can be matched with standard spreadsheet formula
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020858#comment-14020858 ] 

Gilles commented on MATH-1120:
------------------------------

* I would not have the "alternateName", nor refer to "ScyPy" for every enum value. One name is sufficient to guide people to the docs (Javadoc and/or Wikipedia).
* A comment like "Each enum has a MathJax comment about the formulaes" would be cryptic for a reader of the HTML generated doc (where one just sees the rendered formula).
* There are some typos (but this could corrected later).
* I would not include other programming languages (i.e. "R") excerpts in the Javadoc.
* I would not mix HTML with MathJax for a single formula (cf. "index" and "estimate").
* Do not use a single uppercase for a variable name (cf. "N").
* Some "final" keywords could be added.
* "href" attribute values must be between double-quotes. And one is broken over two lines (cf. Javadoc of "EstimationTechnique")
* Is "EstimationTechnique" the best possible name?  As it will be part of the public API, perhaps you could ask this question on the "dev" ML.
* MAX_CACHED_LEVELS is used twice in the same computation:  {code}(0x1 << MAX_CACHED_LEVELS) - 1{code}
  Why not directly define the constant as the result? It would also make the code easier to read.
* The "mediaOf3" deprecation message should probably contain a link to the replacement.

Otherwise, the list of alternate percentile definitions seems a nice addition to the CM stat functionality. Thanks.

> Need Percentile computations that can be matched with standard spreadsheet formula
> ----------------------------------------------------------------------------------
>
>                 Key: MATH-1120
>                 URL: https://issues.apache.org/jira/browse/MATH-1120
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.2
>            Reporter: Venkatesha Murthy TS
>              Labels: Percentile
>             Fix For: 4.0
>
>         Attachments: excel-percentile-patch, percentile-with-estimation-patch, r-output.txt
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> The current Percentile implementation assumes and hard-codes the quantile pth position as 
> p * (N+1)/100 and provides a kth selected value.
> However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code.
> For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1.
> Please let me know if i could submit this as a patch.


--
This message was sent by Atlassian JIRA
(v6.2#6252)