<!--
RSS generated by JIRA (5.0.4#731-sha1:3aa7374293d111f571925889c44fdf45364dfd21) at Wed Jun 13 19:26:44 UTC 2012

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+MATH+AND+issuetype+%3D+Bug+AND+priority+in+%28Blocker%2C+Critical%2C+Major%2C+Minor%29+AND+resolution+in+%28Fixed%2C+Later%29+AND+created+%3C%3D+2010-03-28&tempMax=1000&field=key&field=summary
-->
<!-- If you wish to do custom client-side styling of RSS, uncomment this:
<?xml-stylesheet href="https://issues.apache.org/jira/styles/jiraxml2html.xsl" type="text/xsl"?>
-->
<rss version="0.92">
    <channel>
        <title>ASF JIRA</title>
        <link>https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+MATH+AND+issuetype+%3D+Bug+AND+priority+in+%28Blocker%2C+Critical%2C+Major%2C+Minor%29+AND+resolution+in+%28Fixed%2C+Later%29+AND+created+%3C%3D+2010-03-28</link>
        <description>An XML representation of a search request</description>
                <language>en-uk</language>
                        <issue start="0" end="181" total="181"/>
                <build-info>
            <version>5.0.4</version>
            <build-number>731</build-number>
            <build-date>06-05-2012</build-date>
        </build-info>
<item>
            <title>[MATH-360] SmoothingBicubicSplineInterpolatorTest.testPreconditions()  assigns wzval but does not use it - test bug?</title>
                <link>https://issues.apache.org/jira/browse/MATH-360</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Findbugs points out that SmoothingBicubicSplineInterpolatorTest.testPreconditions()  assigns wzval but does not use it - is this a test bug?&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[][] wzval = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[xval.length][yval.length + 1];
&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; {
    p = interpolator.interpolate(xval, wyval, zval); &lt;span class=&quot;code-comment&quot;&gt;// &amp;lt;== should the last param be wzval ??
&lt;/span&gt;    Assert.fail(&lt;span class=&quot;code-quote&quot;&gt;&quot;an exception should have been thrown&quot;&lt;/span&gt;);
} &lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; (IllegalArgumentException e) {
    &lt;span class=&quot;code-comment&quot;&gt;// Expected
&lt;/span&gt;}
wzval = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[xval.length - 1][yval.length];&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12460242">MATH-360</key>
            <summary>SmoothingBicubicSplineInterpolatorTest.testPreconditions()  assigns wzval but does not use it - test bug?</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Thu, 25 Mar 2010 15:22:42 +0000</created>
                <updated>Sat, 3 Apr 2010 03:01:07 +0000</updated>
                    <resolved>Thu, 25 Mar 2010 17:31:01 +0000</resolved>
                                            <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                            <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-358] ODE integrator goes past specified end of integration range</title>
                <link>https://issues.apache.org/jira/browse/MATH-358</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;End of integration range in ODE solving is handled as an event.&lt;br/&gt;
In some cases, numerical accuracy in events detection leads to error in events location.&lt;br/&gt;
The following test case shows the end event is not handled properly and an integration that should cover a 60s range in fact covers a 160s range, more than twice the specified range.&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMissedEvent() &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; IntegratorException, DerivativeException {
          &lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; t0 = 1878250320.0000029;
          &lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; t =  1878250379.9999986;
          FirstOrderDifferentialEquations ode = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; FirstOrderDifferentialEquations() {
            
            &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; getDimension() {
                &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; 1;
            }
            
            &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void computeDerivatives(&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; t, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] y, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] yDot)
                &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; DerivativeException {
                yDot[0] = y[0] * 1.0e-6;
            }
        };

        DormandPrince853Integrator integrator = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; DormandPrince853Integrator(0.0, 100.0,
                                                                               1.0e-10, 1.0e-10);

        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] y = { 1.0 };
        integrator.setInitialStepSize(60.0);
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; finalT = integrator.integrate(ode, t0, y, t, y);
        Assert.assertEquals(t, finalT, 1.0e-6);
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment>&lt;p&gt;Linux&lt;/p&gt;</environment>
            <key id="12460137">MATH-358</key>
            <summary>ODE integrator goes past specified end of integration range</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Mar 2010 17:25:37 +0000</created>
                <updated>Sat, 3 Apr 2010 03:01:40 +0000</updated>
                    <resolved>Wed, 24 Mar 2010 22:13:19 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12849491" author="luc" created="Wed, 24 Mar 2010 22:13:19 +0000"  >&lt;p&gt;fixed in subversion repository as of r927202&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-354] compiler dependency in RandomDataImpl.getPoisson(double mean)</title>
                <link>https://issues.apache.org/jira/browse/MATH-354</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;in RandomDataImpl.getPoisson(double mean) I got the following problem in the case mean&amp;gt;= 6.0:&lt;/p&gt;

&lt;p&gt;in the branch if (u &amp;lt;= c1):&lt;/p&gt;

&lt;p&gt;if (x &amp;lt; -mu)&lt;br/&gt;
    w = Double.POSITIVE_INFINITY;&lt;/p&gt;

&lt;p&gt;implicits that (int) (mu+ x) &amp;lt; 0&lt;/p&gt;

&lt;p&gt;I found that for some compiler/run-time environments the subsequent update of the &quot;accept&quot; value then fails, as by the right hand side of the comparison leads to an Exception in MathUtils.factorialLog((int) (mu + x)). Some compiler/jre combinations, however, skip evaluating the right side as by isInfinity(w).&lt;/p&gt;

&lt;p&gt;To ensure stability, I currently worked around by an explicit if(Double.isInfinity(w)) branch, however, I would like to ask whether there is a more elegant way to ensure general functionality of that method.&lt;/p&gt;

&lt;p&gt;Thank you, micha. &lt;/p&gt;</description>
                <environment>&lt;p&gt;jre1.5/jre1.6&lt;/p&gt;</environment>
            <key id="12459572">MATH-354</key>
            <summary>compiler dependency in RandomDataImpl.getPoisson(double mean)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gmicha">Michael Sammeth</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Mar 2010 21:08:07 +0000</created>
                <updated>Sat, 3 Apr 2010 03:05:12 +0000</updated>
                    <resolved>Thu, 18 Mar 2010 22:34:20 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12847141" author="psteitz" created="Thu, 18 Mar 2010 22:34:20 +0000"  >&lt;p&gt;The method has been rewritten in version 2.1.  The current version no longer includes the compiler-dependent code referenced in this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 18 Mar 2010 22:34:20 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-352] Jacobian rank determination in LevenbergMarquardtOptimizer is not numerically robust</title>
                <link>https://issues.apache.org/jira/browse/MATH-352</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;LevenbergMarquardtOptimizer is designed to handle singular jacobians,  i.e. situations when some of the fitted parameters depend on each other. The check for that condition is in LevenbergMarquardtOptimizer.qrDecomposition uses precise comparison to 0.&lt;/p&gt;

&lt;p&gt;    if (ak2 == 0 ) {
                rank = k;
                return;
        }&lt;br/&gt;
&lt;br/&gt;
A correct check would be comparison with a small epsilon. Hard coded 2.2204e-16 is used elsewhere in the same file for similar purpose.&lt;br/&gt;
&lt;br/&gt;
final double QR_RANK_EPS = Math.ulp(1d); //2.220446049250313E-16&lt;br/&gt;
....&lt;br/&gt;
    if (ak2  &amp;lt; QR_RANK_EPS) {
                rank = k;
                return;
        }  }&lt;/p&gt;

&lt;p&gt;Current exact equality check is not tolerant of the real world poorly conditioned situations. For example I am trying to fit a cylinder into sample 3d points. Although theoretically cylinder has only 5 independent variables, derivatives for optimizing function (signed distance) for such minimal parametrization are complicated and it  it much easier to work with a 7 variable parametrization (3 for axis direction, 3 for axis origin and 1 for radius). This naturally results in rank-deficient jacobian, but because of the numeric errors the actual ak2 values for the dependent rows ( I am seeing values of 1e-18 and less), rank handling code does not kick in.&lt;br/&gt;
Keeping these tiny values around then leads to huge corrections for the corresponding very slowly changing parameters, and consequently to numeric errors and instabilities. I have noticed the problem because tiny shift in the initial guess (on the order of 1e-12 in the axis component and origins) resulted in significantly different finally converged answers (origins and radii differing by as much as 0.02) which I tracked to loss of precision due to numeric error with root cause described above.&lt;br/&gt;
Providing a cutoff as suggested fixes the issue. After the fix, small perturbations in the initial guess had practically no effect to the converged result - as expected from a robust algorithm.&lt;/p&gt;</description>
                <environment>&lt;p&gt;commons-math 2.0&lt;/p&gt;</environment>
            <key id="12458613">MATH-352</key>
            <summary>Jacobian rank determination in LevenbergMarquardtOptimizer is not numerically robust</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="geneg102">Gene Gorokhovsky</reporter>
                        <labels>
                        <label>DifferentiableMultivariateVectorialOptimizer</label>
                        <label>Levenberg</label>
                        <label>Marquardt</label>
                        <label>commons-math</label>
                        <label>optimizer</label>
                        <label>qr</label>
                        <label>rank</label>
                    </labels>
                <created>Wed, 10 Mar 2010 03:58:01 +0000</created>
                <updated>Wed, 23 Mar 2011 20:01:13 +0000</updated>
                    <resolved>Sun, 6 Jun 2010 14:04:42 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12876045" author="luc" created="Sun, 6 Jun 2010 14:04:42 +0000"  >&lt;p&gt;Fixed in subversion repository as of r951864.&lt;br/&gt;
A setQRRankingThreshold has been added as proposed in &lt;a href=&quot;http://markmail.org/message/p2j76cnwsyehl7u6&quot;&gt;http://markmail.org/message/p2j76cnwsyehl7u6&lt;/a&gt;.&lt;br/&gt;
Thanks for reporting the issue.&lt;/p&gt;</comment>
                    <comment id="13010329" author="luc" created="Wed, 23 Mar 2011 20:01:13 +0000"  >&lt;p&gt;Closing issue as it was included in version 2.2, which has been released&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Jun 2010 14:04:42 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-349] Dangerous code in &quot;PoissonDistributionImpl&quot;</title>
                <link>https://issues.apache.org/jira/browse/MATH-349</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;In the following excerpt from class &quot;PoissonDistributionImpl&quot;:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-style: solid;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;border-bottom-style: solid;&quot;&gt;&lt;b&gt;PoissonDistributionImpl.java&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; PoissonDistributionImpl(&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; p, NormalDistribution z) {
        &lt;span class=&quot;code-keyword&quot;&gt;super&lt;/span&gt;();
        setNormal(z);
        setMean(p);
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;(1) Overridable methods are called within the constructor.&lt;br/&gt;
(2) The reference &quot;z&quot; is stored and modified within the class.&lt;/p&gt;

&lt;p&gt;I&apos;ve encountered problem (1) in several classes while working on issue 348. In those cases, in order to remove potential problems, I copied/pasted the body of the &quot;setter&quot; methods inside the constructor but I think that a more elegant solution would be to remove the &quot;setters&quot; altogether (i.e. make the classes immutable).&lt;br/&gt;
Problem (2) can also create unexpected behaviour. Is it really necessary to pass the &quot;NormalDistribution&quot; object; can&apos;t it be always created within the class?&lt;/p&gt;</description>
                <environment></environment>
            <key id="12458249">MATH-349</key>
            <summary>Dangerous code in &quot;PoissonDistributionImpl&quot;</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="erans">Gilles</reporter>
                        <labels>
                    </labels>
                <created>Fri, 5 Mar 2010 15:15:19 +0000</created>
                <updated>Wed, 23 Mar 2011 19:59:37 +0000</updated>
                    <resolved>Sun, 26 Sep 2010 21:55:34 +0000</resolved>
                                            <fixVersion>3.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12842271" author="psteitz" created="Sat, 6 Mar 2010 15:49:19 +0000"  >&lt;p&gt;The reason this constructor exists is to allow users to plug in an alternative normal distribution implementation to be used in computing normal approximations.  I don&apos;t see 1) as a serious issue, but I am +1 on deprecating the setters with aim to make this class immutable in 3.0.  2) is a harder problem, as there is no requirement that a NormalDistribution be clonable.   I see three solutions, none of which are particularly appealing:&lt;/p&gt;

&lt;p&gt;1) leave as is and specify in the javadoc that z is going to be modified&lt;br/&gt;
2) change the implementation to avoid changing the parameters of z &lt;br/&gt;
3) deprecate the constructor altogether&lt;/p&gt;

&lt;p&gt;I vote for 1) + 3) - update the javadoc, but deprecate.  If we get complaints before 3.0, we can reconsider; otherwise eliminate in 3.0&lt;/p&gt;</comment>
                    <comment id="12842729" author="erans" created="Mon, 8 Mar 2010 16:48:22 +0000"  >&lt;p&gt;Problem (1)&lt;br/&gt;
In principle, it is not safe to call overridable methods in the constructor, so, if only to promote coding quality, can I implement private (&quot;helper&quot;) setter methods that shall be called from within the constructors and from the public setters?&lt;/p&gt;

&lt;p&gt;Problem (2)&lt;br/&gt;
In &quot;PoissonDistributionImpl.java&quot;, there is this code:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-style: solid;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;border-bottom-style: solid;&quot;&gt;&lt;b&gt;PoissonDistributionImpl.java&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; PoissonDistributionImpl(&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; p, NormalDistribution z) {
    &lt;span class=&quot;code-keyword&quot;&gt;super&lt;/span&gt;();
    setNormal(z);
    setMean(p);
}

&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void setMean(&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; p) {
    &lt;span class=&quot;code-comment&quot;&gt;// ...
&lt;/span&gt;    &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;.mean = p;
    normal.setMean(p);
    normal.setStandardDeviation(&lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.sqrt(p));
}

&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void setNormal(NormalDistribution value) {
    normal = value;
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;In the constructor, the code makes sure that the &quot;mean&quot; of this class and the mean of the &quot;normal&quot; object are consistent.&lt;br/&gt;
But there is no such guarantee anymore when calling the &quot;setNormal&quot; method. &lt;span class=&quot;error&quot;&gt;&amp;#91;The comment warns the user that he is responsible for setting the right parameter in &amp;quot;value&amp;quot; but this is far from fool-proof...&amp;#93;&lt;/span&gt;&lt;/p&gt;
</comment>
                    <comment id="12842750" author="psteitz" created="Mon, 8 Mar 2010 17:45:01 +0000"  >&lt;p&gt;I agree that both (1) and (2) are problems.  The private helpers would be OK to address (1), but I am also OK with deprecating the setters and just setting the fields directly (per &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-348&quot; title=&quot;Indirect access to instance variables&quot;&gt;&lt;del&gt;MATH-348&lt;/del&gt;&lt;/a&gt;) in the constructor.  As stated above, I am also +1 on deprecating the pluggability of the normal impl, which will (eventually) address (2).  I guess to address (2) now we either need to modify setNormal to update the parameters of the normal instance as setMean does or change the normal approximation implementation to not depend on the parameters of the distribution (which addresses the problem of z being updated).  Its probably easiest and best in the long term to take the first approach, documenting the fact that z is going to be updated (both in setNormal and constructor javadoc).&lt;/p&gt;</comment>
                    <comment id="12843031" author="erans" created="Tue, 9 Mar 2010 13:02:00 +0000"  >&lt;p&gt;Issue is partially fixed (removed the consistency problem) in revision 920852.&lt;br/&gt;
Setters were marked as deprecated.&lt;/p&gt;</comment>
                    <comment id="12843047" author="psteitz" created="Tue, 9 Mar 2010 13:46:21 +0000"  >&lt;p&gt;Issue (2) in the bug description remains open.  I think we should leave this issue open until we have a solution for this.  As stated above, I can see two ways to fix this:&lt;/p&gt;

&lt;p&gt;a) modify the normal approximation implementation so that it does not change the parameters of z&lt;br/&gt;
b) eliminate pluggability of z (i.e., deprecate and then remove the constructor that accepts a normal instance as a parameter)&lt;/p&gt;

&lt;p&gt;a) could be accomplished in 2.x, but it would complicate the code and could be bad for numerics.  My vote is for b) - add a warning (about safety as well as deprecation), deprecate now and if we get no complaints before 3.0, remove then.   Leave the issue open with fix version 3.0.&lt;/p&gt;</comment>
                    <comment id="12843052" author="erans" created="Tue, 9 Mar 2010 14:07:40 +0000"  >&lt;p&gt;The same kind of problem also exists in &quot;ChiSquaredDistributionImpl.java&quot;.&lt;br/&gt;
In both classes, the constructor that takes the distribution as a parameter has been deprecated.&lt;/p&gt;</comment>
                    <comment id="12843146" author="psteitz" created="Tue, 9 Mar 2010 15:22:58 +0000"  >&lt;p&gt;Sorry,  I missed the constructor deprecations in r920852&lt;/p&gt;</comment>
                    <comment id="12843171" author="psteitz" created="Tue, 9 Mar 2010 15:25:40 +0000"  >&lt;p&gt;Leaving open until deprecated constructors are removed in 3.0.&lt;/p&gt;</comment>
                    <comment id="12914889" author="erans" created="Sat, 25 Sep 2010 23:07:48 +0000"  >&lt;p&gt;&lt;tt&gt;PoissonDistributionImpl&lt;/tt&gt; made immutable in revision 1001331.&lt;/p&gt;</comment>
                    <comment id="12915051" author="erans" created="Sun, 26 Sep 2010 21:54:19 +0000"  >&lt;p&gt;&lt;tt&gt;ChiSquaredDistributionImpl&lt;/tt&gt; made immutable in revision 1001533.&lt;/p&gt;</comment>
                    <comment id="12915052" author="erans" created="Sun, 26 Sep 2010 21:55:34 +0000"  >&lt;p&gt;Removed deprecated code.  Classes are now immutable.&lt;/p&gt;</comment>
                    <comment id="13010327" author="luc" created="Wed, 23 Mar 2011 19:59:37 +0000"  >&lt;p&gt;Closing issue as it was included in version 2.2, which has been released&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 6 Mar 2010 15:49:19 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-347] Brent solver shouldn&apos;t need strict ordering of min, max and initial</title>
                <link>https://issues.apache.org/jira/browse/MATH-347</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The &quot;solve(final UnivariateRealFunction f, final double min, final double max, final double initial)&quot; function calls verifySequence() which enforces a strict ordering of min, max and initial parameters. I can&apos;t see why that is necessary - the rest of solve() seems to be able to handle &quot;initial == min&quot; and &quot;initial == min&quot; cases just fine. In fact, the JavaDoc suggests setting initial to min when not known but that is not possible at the moment.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12457428">MATH-347</key>
            <summary>Brent solver shouldn&apos;t need strict ordering of min, max and initial</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aktasv">Volkan Aktas</reporter>
                        <labels>
                    </labels>
                <created>Thu, 25 Feb 2010 14:33:30 +0000</created>
                <updated>Sat, 3 Apr 2010 03:06:18 +0000</updated>
                    <resolved>Mon, 1 Mar 2010 19:39:28 +0000</resolved>
                            <version>2.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12838356" author="aktasv" created="Thu, 25 Feb 2010 14:36:23 +0000"  >&lt;p&gt;Also would like to add that when this constraint is removed it should be possible to make the &quot;solve(final UnivariateRealFunction f, final double min, final double max)&quot; call the other solve() function without any additional logic.&lt;/p&gt;
</comment>
                    <comment id="12839822" author="luc" created="Mon, 1 Mar 2010 19:39:24 +0000"  >&lt;p&gt;Fixed in subversion repository as of r917668.&lt;br/&gt;
Thanks for reporting the issue&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 1 Mar 2010 19:39:24 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-344] Brent solver returns the wrong value if either bracket endpoint is root</title>
                <link>https://issues.apache.org/jira/browse/MATH-344</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The solve(final UnivariateRealFunction f, final double min, final double max, final double initial) function returns yMin or yMax if min or max are deemed to be roots, respectively, instead of min or max.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12457210">MATH-344</key>
            <summary>Brent solver returns the wrong value if either bracket endpoint is root</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aktasv">Volkan Aktas</reporter>
                        <labels>
                    </labels>
                <created>Tue, 23 Feb 2010 20:23:21 +0000</created>
                <updated>Sat, 3 Apr 2010 03:07:01 +0000</updated>
                    <resolved>Tue, 23 Feb 2010 21:10:00 +0000</resolved>
                            <version>2.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12837444" author="luc" created="Tue, 23 Feb 2010 21:10:00 +0000"  >&lt;p&gt;Fixed in subversion repository as of r915522&lt;br/&gt;
thanks for reporting the issue&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 23 Feb 2010 21:10:00 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-343] Brent solver doesn&apos;t throw IllegalArgumentException when initial guess has the wrong sign</title>
                <link>https://issues.apache.org/jira/browse/MATH-343</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Javadoc for &quot;public double solve(final UnivariateRealFunction f, final double min, final double max, final double initial)&quot; claims that &quot;if the values of the function at the three points have the same sign&quot; an IllegalArgumentException is thrown. This case isn&apos;t even checked.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12457208">MATH-343</key>
            <summary>Brent solver doesn&apos;t throw IllegalArgumentException when initial guess has the wrong sign</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aktasv">Volkan Aktas</reporter>
                        <labels>
                    </labels>
                <created>Tue, 23 Feb 2010 20:21:00 +0000</created>
                <updated>Sat, 3 Apr 2010 03:44:32 +0000</updated>
                    <resolved>Tue, 23 Feb 2010 21:02:31 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12837442" author="luc" created="Tue, 23 Feb 2010 21:02:31 +0000"  >&lt;p&gt;Fixed in subversion repository as of r915517&lt;br/&gt;
Thanks for reporting the issue&lt;/p&gt;</comment>
                    <comment id="12837494" author="aktasv" created="Tue, 23 Feb 2010 22:56:41 +0000"  >&lt;p&gt;Thanks for the quick turnaround. One comment: I&apos;m not sure whether the check before throwing the IllegalArgumentException is necessary. You can have only the following situations (given that min &amp;lt;= initial &amp;lt;= max and assuming neither min nor max is a root):&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;yMin and yMax have the same sign:
	&lt;ul&gt;
		&lt;li&gt;yInitial has a different sign: Handled on line 121 (function is not monotonous between min and max)&lt;/li&gt;
		&lt;li&gt;yInitial has the same sign: Falls through to line 136 and yMin * yMax &amp;gt; 0 by definition&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;yMin and yMax do not have the same sign:
	&lt;ul&gt;
		&lt;li&gt;yInitial has the same sign as yMax: Handled on line 121&lt;/li&gt;
		&lt;li&gt;yInitial has the same sign as yMin: Handled on line 133&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;In this case I&apos;d say code between lines 131 and 142 should be replaced by the throw statement on line 137.&lt;/p&gt;</comment>
                    <comment id="12837747" author="luc" created="Wed, 24 Feb 2010 11:34:29 +0000"  >&lt;p&gt;You are right.&lt;br/&gt;
I have removed the unreachable code and committed it in the subversion repository&lt;br/&gt;
Thanks again&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 23 Feb 2010 21:02:31 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-342] SVD crashes when applied to a strongly rectangular matrix (typical case of least-squares problem)</title>
                <link>https://issues.apache.org/jira/browse/MATH-342</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When SVD is applied to a strongly rectangular matrix (number of rows way larger than number of columns, typical case of least-squares problem), finite precision arithmetics shows up:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;in EigenDecompositionImpl.isSymmetric: a by-definition symmetric matrix returns false;&lt;/li&gt;
	&lt;li&gt;in EigenDecompositionImpl.findEigenVectors: too many iterations exception&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="12456954">MATH-342</key>
            <summary>SVD crashes when applied to a strongly rectangular matrix (typical case of least-squares problem)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="dimpbx">Dimitri Pourbaix</assignee>
                                <reporter username="dimpbx">Dimitri Pourbaix</reporter>
                        <labels>
                    </labels>
                <created>Sun, 21 Feb 2010 21:41:36 +0000</created>
                <updated>Sat, 3 Apr 2010 03:45:19 +0000</updated>
                    <resolved>Sun, 21 Feb 2010 21:50:20 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12836453" author="dimpbx" created="Sun, 21 Feb 2010 21:50:20 +0000"  >&lt;p&gt;The two identified troublesome behaviors of EigenDecomposition are corrected.  Besides the regular unit tests, the two classes SingularValueDecompositionimpl and EigenDecompositionImpl have now been successfully tested over 300k+ systems coming from some astronomical application.  No crash reported!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-341] Test for firsst Derivative in PolynomialFunction ERROR</title>
                <link>https://issues.apache.org/jira/browse/MATH-341</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I have written the attached test using our data for generating a curve function&lt;/p&gt;

&lt;p&gt;However the first derivative test fails see: testfirstDerivativeComparisonFullPower&lt;/p&gt;

&lt;p&gt;Either my test is in error or there is a bug in PolynomialFunction class.&lt;/p&gt;


&lt;p&gt;Roger Ball&lt;br/&gt;
Creoss Business Solutions &lt;/p&gt;</description>
                <environment></environment>
            <key id="12455491">MATH-341</key>
            <summary>Test for firsst Derivative in PolynomialFunction ERROR</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="rfball">Roger Ball</reporter>
                        <labels>
                    </labels>
                <created>Fri, 5 Feb 2010 20:32:59 +0000</created>
                <updated>Tue, 9 Feb 2010 23:21:27 +0000</updated>
                    <resolved>Tue, 9 Feb 2010 20:08:51 +0000</resolved>
                            <version>2.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12830281" author="rfball" created="Fri, 5 Feb 2010 20:34:02 +0000"  >&lt;p&gt;FirstDerivativePolyNomTest.java&lt;/p&gt;</comment>
                    <comment id="12830314" author="luc" created="Fri, 5 Feb 2010 21:50:33 +0000"  >&lt;p&gt;I think there are no bugs here.&lt;br/&gt;
The first part of the test (method testfirstDerivativeComparison) runs without error.&lt;br/&gt;
The second part of the test (method testfirstDerivativeComparisonFullPower) prints coefficients that do not match.&lt;/p&gt;

&lt;p&gt;However, the coefficients computed seem wrong to me because&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;the getCoefficients method returns an array in increasing degree order (i.e. coeff&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; is the constant term)&lt;/li&gt;
	&lt;li&gt;the coefficients array length is d+1 when d is the degree&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This implies that the g_coeff array which should contain the coefficients of the derivative must have length myPolyNom.degree() and not myPolyNom.degree()-1 and the following loop should match.  Also the computation of the coefficients of the derivative shoud be:&lt;/p&gt;

&lt;p&gt;  g_coeff&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; = f_coeff&lt;span class=&quot;error&quot;&gt;&amp;#91;i+1&amp;#93;&lt;/span&gt; * (i + 1);&lt;/p&gt;

&lt;p&gt;instead of&lt;/p&gt;

&lt;p&gt;  g_coeff&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; = f_coeff&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt;*(myPolyNom.degree()-i);&lt;/p&gt;

&lt;p&gt;With these changes, the automatic computation of derivative works.&lt;/p&gt;

&lt;p&gt;A first comment on this case is that using polynomial fitting for such functions with large numbers of points shows very large Gibbs oscillations near the interval ends. One way to see this is to draw the curve from the sample points and from evaluation of myPolyNom with x varying from 5 to 30 with a 0.1 step. You will see that the polynomial fits the sample points perfectly, but near interval ends it has HUGE oscillations.&lt;/p&gt;

&lt;p&gt;Another comment is that extracting the coefficients from the lagrangian form should be used with caution. Unfortunately, this is written only in the protected computationCoefficients() method javadoc, not in the public getCoefficients() method javadoc ... The computation is ill-conditioned and in fact the coefficients returned in your case are really bad. This could be seen by evaluating the original lagrangian form polynomial and the one reconstructed from the coefficients. The original does match the expected points, the reconstructed one does not.&lt;/p&gt;

&lt;p&gt;So I think there is only a documentation problem: we should warn the user about extracting coefficients in this implementation.&lt;/p&gt;

&lt;p&gt;Do you agree with this analysis ?&lt;/p&gt;</comment>
                    <comment id="12831561" author="rfball" created="Tue, 9 Feb 2010 17:59:27 +0000"  >&lt;p&gt;Regarding: &lt;br/&gt;
&quot;So I think there is only a documentation problem: we should warn the user about extracting coefficients in this implementation.&lt;/p&gt;

&lt;p&gt;Do you agree with this analysis ?&quot;&lt;/p&gt;

&lt;p&gt;Certainly a documentation problem. However, if the coefficients do not result in a curve expression that is valid of the entire range of values for which the curve expression is derived then the curve expression is not really useful in a practical sense. I also the erractic occillations in curve. These occillations are HUGE when comparred to the data. Therefore the expression is not all together valid.&lt;/p&gt;</comment>
                    <comment id="12831637" author="luc" created="Tue, 9 Feb 2010 20:00:51 +0000"  >&lt;p&gt;I will fix the documentation.&lt;/p&gt;

&lt;p&gt;The coefficients are valid when the number of points is reduced (for example consider only the 8 or 10 last points, it should work). Also note that polynomials in lagrangian form should really stay in this form and should not be converted to the canonical sum of monomials. It IS ill-conditioned so attempting this for high degree is not advised.&lt;/p&gt;

&lt;p&gt;The oscillations you see are not an implementation problem, the mathematical solution is really like this. This is a theoretical problem known as Runge&apos;s phenomenon. See for example &lt;a href=&quot;http://demonstrations.wolfram.com/RungesPhenomenon/&quot;&gt;http://demonstrations.wolfram.com/RungesPhenomenon/&lt;/a&gt; and especially the high degree versions at the bottom of the page. You will see huge interpolation error at the end of the interval. When using polynomial interpolation, increasing the degree and the number of points but keeping them equidistant does NOT reduce maximal error (in fact for some functions error will tend towards infinity). The expression perfectly fits the sample points you provide but it has no information of what to do between them.&lt;/p&gt;

&lt;p&gt;Polynomial interpolation should really be used with care. If you want smoother behavior, you should use several lower degrees polynomials each covering a subrange of your data.&lt;/p&gt;</comment>
                    <comment id="12831640" author="luc" created="Tue, 9 Feb 2010 20:08:51 +0000"  >&lt;p&gt;added a warning in getCoefficients() method documentation&lt;br/&gt;
fixed in subversion repository as of r908190&lt;br/&gt;
thanks for reporting the problem&lt;/p&gt;</comment>
                    <comment id="12831690" author="rfball" created="Tue, 9 Feb 2010 21:57:31 +0000"  >&lt;p&gt;Looking at &quot;See for example &lt;a href=&quot;http://demonstrations.wolfram.com/RungesPhenomenon/&quot;&gt;http://demonstrations.wolfram.com/RungesPhenomenon/&lt;/a&gt; &quot; it seems that if you select Chebyshev sample points the error drops dramatically all along the curve. Is this an option in the apache math library?&lt;/p&gt;</comment>
                    <comment id="12831750" author="luc" created="Tue, 9 Feb 2010 23:21:27 +0000"  >&lt;p&gt;You select the points yourself as you provides the x and y arrays, so yes, you can choos points at Chebyshev abscissas.&lt;br/&gt;
The array even don&apos;t need to be sorted. However, you cannot have two points with the same x value.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12435005" name="FirstDerivativePolyNomTest.java" size="4387" author="rfball" created="Fri, 5 Feb 2010 20:34:02 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 5 Feb 2010 21:50:33 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-340] BigFraction numerator constrainted by int size during multiplication</title>
                <link>https://issues.apache.org/jira/browse/MATH-340</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When multiplying two BigFraction objects with numerators larger than will fit in an java-primitive int the result of BigFraction.ZERO is incorrectly returned.&lt;/p&gt;


&lt;p&gt;Test Case:&lt;/p&gt;

&lt;p&gt;	        BigFraction fractionA = new BigFraction(0.00131);&lt;br/&gt;
	        BigFraction fractionB = new BigFraction(.37).reciprocal();&lt;br/&gt;
	        BigFraction errorResult = fractionA.multiply(fractionB);&lt;br/&gt;
	        System.out.println(&quot;Error Result: &quot; + errorResult);&lt;br/&gt;
		BigFraction correctResult = new BigFraction(fractionA.getNumerator().multiply(fractionB.getNumerator()), fractionA.getDenominator().multiply(fractionB.getDenominator()));&lt;br/&gt;
	        System.out.println(&quot;Correct Result: &quot; + correctResult);&lt;/p&gt;</description>
                <environment>&lt;p&gt;All&lt;/p&gt;</environment>
            <key id="12455227">MATH-340</key>
            <summary>BigFraction numerator constrainted by int size during multiplication</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mjtaylor">Matt Taylor</reporter>
                        <labels>
                    </labels>
                <created>Wed, 3 Feb 2010 20:17:35 +0000</created>
                <updated>Sat, 3 Apr 2010 03:45:55 +0000</updated>
                    <resolved>Wed, 3 Feb 2010 21:21:06 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12829272" author="luc" created="Wed, 3 Feb 2010 21:21:06 +0000"  >&lt;p&gt;Fixed in subversion repository as of r906251.&lt;br/&gt;
Thanks for the report.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 3 Feb 2010 21:21:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-338] Wrong parameter for first step size guess for Embedded Runge Kutta methods</title>
                <link>https://issues.apache.org/jira/browse/MATH-338</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;In a space application using DOP853 i detected what seems to be a bad parameter in the call to the method  initializeStep of class AdaptiveStepsizeIntegrator.&lt;/p&gt;

&lt;p&gt;Here, DormandPrince853Integrator is a subclass for EmbeddedRungeKuttaIntegrator which perform the call to initializeStep at the beginning of its method integrate(...)&lt;/p&gt;

&lt;p&gt;The problem comes from the array &quot;scale&quot; that is used as a parameter in the call off initializeStep(..)&lt;/p&gt;

&lt;p&gt;Following the theory described by Hairer in his book &quot;Solving Ordinary Differential Equations 1 : Nonstiff Problems&quot;, the scaling should be :&lt;/p&gt;

&lt;p&gt;sci = Atol i + |y0i| * Rtoli&lt;/p&gt;

&lt;p&gt;Whereas EmbeddedRungeKuttaIntegrator uses :  sci = Atoli&lt;/p&gt;

&lt;p&gt;Note that the Gragg-Bulirsch-Stoer integrator uses the good implementation &quot;sci = Atol i + |y0i| * Rtoli  &quot; when he performs the call to the same method initializeStep(..)&lt;/p&gt;

&lt;p&gt;In the method initializeStep, the error leads to a wrong step size h used to perform an  Euler step. Most of the time it is unvisible for the user.&lt;br/&gt;
But in my space application the Euler step with this wrong step size h (much bigger than it should be)  makes an exception occur (my satellite hits the ground...)&lt;/p&gt;


&lt;p&gt;To fix the bug, one should use the same algorithm as in the rescale method in GraggBulirschStoerIntegrator&lt;br/&gt;
For exemple :&lt;/p&gt;

&lt;p&gt; final double[] scale= new double&lt;span class=&quot;error&quot;&gt;&amp;#91;y0.length&amp;#93;&lt;/span&gt;;;&lt;/p&gt;

&lt;p&gt;          if (vecAbsoluteTolerance == null) {&lt;br/&gt;
              for (int i = 0; i &amp;lt; scale.length; ++i) {
                final double yi = Math.max(Math.abs(y0[i]), Math.abs(y0[i]));
                scale[i] = scalAbsoluteTolerance + scalRelativeTolerance * yi;
              }&lt;br/&gt;
            } else {&lt;br/&gt;
              for (int i = 0; i &amp;lt; scale.length; ++i) {
                final double yi = Math.max(Math.abs(y0[i]), Math.abs(y0[i]));
                scale[i] = vecAbsoluteTolerance[i] + vecRelativeTolerance[i] * yi;
              }&lt;br/&gt;
            }&lt;/p&gt;

&lt;p&gt;          hNew = initializeStep(equations, forward, getOrder(), scale,&lt;br/&gt;
                           stepStart, y, yDotK&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;, yTmp, yDotK&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;);&lt;/p&gt;



&lt;p&gt;Sorry for the length of this message, looking forward to hearing from you soon&lt;/p&gt;

&lt;p&gt;Vincent Morand&lt;/p&gt;



</description>
                <environment>&lt;p&gt;Eclipse sous Red Hat 5&lt;/p&gt;</environment>
            <key id="12446898">MATH-338</key>
            <summary>Wrong parameter for first step size guess for Embedded Runge Kutta methods</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="vincent.morand">Morand Vincent</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Jan 2010 10:59:13 +0000</created>
                <updated>Sat, 3 Apr 2010 03:54:31 +0000</updated>
                    <resolved>Thu, 28 Jan 2010 15:17:46 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12805948" author="luc" created="Thu, 28 Jan 2010 15:17:46 +0000"  >&lt;p&gt;Fixed in subversion repository as of r904112.&lt;br/&gt;
Note that I have changed slightly the fix you proposed: the call to Math.max was not needed because both arguments were the same (in GBS integrator, they are different).&lt;br/&gt;
Note that instead of letting the integrator guess the first step by itself, you can provide it yourself by calling setInitialStepSize. This setting must be done before the call to integrate, which is called by Orekit propagate method if you happen to use Orekit for your application &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; For such applications, an initial step of the order of magnitude of 1/100 of the keplerian period is a fair bet, it will be adjusted by the integrator if inconsistent with your accuracy settings.&lt;/p&gt;

&lt;p&gt;Thanks for the report.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 28 Jan 2010 15:17:46 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-335] Fraction.hashCode() inconsistent with Fraction.equals()</title>
                <link>https://issues.apache.org/jira/browse/MATH-335</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Fraction.hashCode() is inconsistent with Fraction.equals().&lt;/p&gt;

&lt;p&gt;hashCode() uses getNumerator() (which is not final) rather than directly accessing the field.&lt;/p&gt;

&lt;p&gt;Seems to me that hashCode() has no reason to use the getters - or if it does, then equals should do so too.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12446819">MATH-335</key>
            <summary>Fraction.hashCode() inconsistent with Fraction.equals()</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Wed, 27 Jan 2010 15:31:02 +0000</created>
                <updated>Sat, 3 Apr 2010 20:33:07 +0000</updated>
                    <resolved>Sun, 14 Mar 2010 01:38:48 +0000</resolved>
                                            <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12805564" author="luc" created="Wed, 27 Jan 2010 16:40:24 +0000"  >&lt;p&gt;Agreed. I would prefer it uses the fields directly.&lt;/p&gt;</comment>
                    <comment id="12845005" author="sebb@apache.org" created="Sun, 14 Mar 2010 01:38:48 +0000"  >&lt;p&gt;URL: &lt;a href=&quot;http://svn.apache.org/viewvc?rev=922715&amp;amp;view=rev&quot;&gt;http://svn.apache.org/viewvc?rev=922715&amp;amp;view=rev&lt;/a&gt;&lt;br/&gt;
Log:&lt;br/&gt;
&lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-335&quot; title=&quot;Fraction.hashCode() inconsistent with Fraction.equals()&quot;&gt;&lt;del&gt;MATH-335&lt;/del&gt;&lt;/a&gt; Fraction.hashCode() inconsistent with Fraction.equals()&lt;br/&gt;
Change hashCode() to use fields directly&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 27 Jan 2010 16:40:24 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-333] eigenvectors computation is wrong when several vectors share the same eigenvalue</title>
                <link>https://issues.apache.org/jira/browse/MATH-333</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;A typical example is to decompose identity matrix. There is only one eigenvalue: 1.0. Instead of returning n different eigenvectors forming a complete vector base, the same vector is returned n times.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12446568">MATH-333</key>
            <summary>eigenvectors computation is wrong when several vectors share the same eigenvalue</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="dimpbx">Dimitri Pourbaix</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Mon, 25 Jan 2010 17:56:01 +0000</created>
                <updated>Sat, 3 Apr 2010 20:34:39 +0000</updated>
                    <resolved>Tue, 16 Feb 2010 17:43:21 +0000</resolved>
                                            <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12828792" author="luc" created="Tue, 2 Feb 2010 22:12:56 +0000"  >&lt;p&gt;This issue should really be fixed for 2.1&lt;/p&gt;</comment>
                    <comment id="12832268" author="dimpbx" created="Wed, 10 Feb 2010 22:52:28 +0000"  >&lt;p&gt;EigenDecomposition is the Java (strict) translation of some parts of the&lt;br/&gt;
LAPACK library, as obscure as the original.  It is likely efficient when&lt;br/&gt;
it works properly but it is a debugging nightmare when it does not.  Far&lt;br/&gt;
away from most OOP paradigms, every useful quantity is stored in a huge&lt;br/&gt;
array which is used as a working area.&lt;/p&gt;

&lt;p&gt;Part of the LAPACK complexity as far as EigenDecomposition is concerned&lt;br/&gt;
is caused by its wish to handle almost any kind of matrix.  So, lots of&lt;br/&gt;
routines are introduced to handle these different cases.  If one tries to&lt;br/&gt;
follow the path of a real symmetric matrix in that jungle, one still ends&lt;br/&gt;
up with a lot of routines and thus with a lot of Java methods.  However,&lt;br/&gt;
if one decides from the beginning that we will deal with real symmetric&lt;br/&gt;
matrices only, there are way simpler alternatives to the LAPACK collection.&lt;/p&gt;

&lt;p&gt;Even without changing the current methods, a bit of mathematical consistency&lt;br/&gt;
might be welcome: the class EigenDecomposition is clearly described as sol-&lt;br/&gt;
ving an eigen problem for a real symmetic matrix.  Fine.  But if it is so,&lt;br/&gt;
there is no point in keeping imaginaryEigenvalues: the eigen values of a&lt;br/&gt;
real symmetric matrix are real (LAPACK legacy)!!!  The only reason I see for&lt;br/&gt;
keeping the imaginary part is because solver() needs it.&lt;br/&gt;
At the cost of a second eigen decomposition, SVD now returns the correct&lt;br/&gt;
number of singular values (and left and right singular vectors) even when&lt;br/&gt;
the matrix is singular.&lt;/p&gt;

&lt;p&gt;A few signs in the eigen vectors of testMath308 must be changed to&lt;br/&gt;
successfully pass to the tests.&lt;/p&gt;

&lt;p&gt;testTruncated and testMath320A (in SingularValueSolverTest) have been&lt;br/&gt;
removed since SVD always return the maximum number of singular values.&lt;br/&gt;
testMatricesValues2 (from SingularValueDecompositionImplTest) is&lt;br/&gt;
removed because the SVD decomposition is not unique.&lt;/p&gt;</comment>
                    <comment id="12832411" author="dimpbx" created="Thu, 11 Feb 2010 07:30:47 +0000"  >&lt;p&gt;The attached file is the result &apos;svn diff&apos; from trunk.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12435510" name="EigenDecompositionImpl.java" size="21368" author="dimpbx" created="Wed, 10 Feb 2010 22:52:28 +0000" />
                    <attachment id="12435555" name="MATH-333_320.patch" size="106113" author="dimpbx" created="Thu, 11 Feb 2010 07:30:46 +0000" />
                    <attachment id="12435511" name="SingularValueDecompositionImpl.java" size="13823" author="dimpbx" created="Wed, 10 Feb 2010 22:52:28 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 10 Feb 2010 22:52:28 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-329] In stat.Frequency, getPct(Object) uses getCumPct(Comparable) instead of getPct(Comparable) </title>
                <link>https://issues.apache.org/jira/browse/MATH-329</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Drop in Replacement of 1.2 with 2.0 not possible because all getPct calls will be cummulative without code change&lt;/p&gt;

&lt;p&gt;Frequency.java&lt;/p&gt;

&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Returns the percentage of values that are equal to v&lt;/li&gt;
	&lt;li&gt;@deprecated replaced by {@link #getPct(Comparable)} as of 2.0&lt;br/&gt;
     */&lt;br/&gt;
    @Deprecated&lt;br/&gt;
    public double getPct(Object v) {
        return getCumPct((Comparable&amp;lt;?&amp;gt;) v);
    }&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="12445486">MATH-329</key>
            <summary>In stat.Frequency, getPct(Object) uses getCumPct(Comparable) instead of getPct(Comparable) </summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="williausrohr">Willi Wu</reporter>
                        <labels>
                    </labels>
                <created>Thu, 14 Jan 2010 08:01:33 +0000</created>
                <updated>Sat, 3 Apr 2010 20:35:27 +0000</updated>
                    <resolved>Sat, 16 Jan 2010 20:02:15 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                          <timeoriginalestimate seconds="600">10m</timeoriginalestimate>
                    <timeestimate seconds="600">10m</timeestimate>
                                  <comments>
                    <comment id="12801262" author="psteitz" created="Sat, 16 Jan 2010 20:02:15 +0000"  >&lt;p&gt;Fixed in r900016.  Thanks for reporting this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 16 Jan 2010 20:02:15 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-327]  Maximal number of iterations (540) exceeded</title>
                <link>https://issues.apache.org/jira/browse/MATH-327</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I have a matrix of size 49x19 and when I apply SVD on this matrix it raises the following exception. The problem which I am facing is that SVD works for some matrix and doesn&apos;t work for others. I have no clue what is the possible reason.&lt;/p&gt;

&lt;p&gt;Exception::&lt;br/&gt;
CorrespondenceAnalysis: org.apache.commons.math.MaxIterationsExceededException: Maximal number of iterations (540) exceeded &lt;br/&gt;
[org.apache.commons.math.linear.EigenDecompositionImpl.processGeneralBlock(EigenDecompositionImpl.java:881), org.apache.commons.math.linear.EigenDecompositionImpl.findEigenvalues(EigenDecompositionImpl.java:651), org.apache.commons.math.linear.EigenDecompositionImpl.decompose(EigenDecompositionImpl.java:243), org.apache.commons.math.linear.EigenDecompositionImpl.&amp;lt;init&amp;gt;(EigenDecompositionImpl.java:202), org.apache.commons.math.linear.SingularValueDecompositionImpl.&amp;lt;init&amp;gt;(SingularValueDecompositionImpl.java:114),&lt;/p&gt;


&lt;p&gt;RealMatrix m = [&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000, 1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143, 0.95238096, 1.00000000, 1.00000000, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000, 1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000, 0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142, 0.95238096, 1.00000000, 0.93333334, 0.96428573&amp;#93;&lt;/span&gt;]&lt;/p&gt;

&lt;p&gt;RealMatrix rcp = MatrixUtils.createRealMatrix(CP);	&lt;br/&gt;
SingularValueDecomposition svd = new SingularValueDecompositionImpl(rcp);		&lt;/p&gt;

&lt;p&gt;RealMatrix U = svd.getU();&lt;br/&gt;
RealMatrix S = svd.getS();&lt;br/&gt;
RealMatrix Vt = svd.getVT();&lt;br/&gt;
double[] singularValues = svd.getSingularValues();&lt;/p&gt;</description>
                <environment>&lt;p&gt;Windows 7 (32-bit)  JDK 1.6_16&lt;/p&gt;</environment>
            <key id="12444750">MATH-327</key>
            <summary> Maximal number of iterations (540) exceeded</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mansoorkhan">Mansoor Ahmed Khan</reporter>
                        <labels>
                    </labels>
                <created>Tue, 5 Jan 2010 21:49:32 +0000</created>
                <updated>Sat, 24 Mar 2012 16:16:59 +0000</updated>
                    <resolved>Wed, 20 Jul 2011 12:18:41 +0000</resolved>
                                            <fixVersion>3.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12796884" author="axelclk" created="Tue, 5 Jan 2010 22:40:06 +0000"  >&lt;p&gt;Maybe that Math-320 isn&apos;t completely solved.&lt;br/&gt;
For the getU() method from the latest SVN sources I&apos;m getting NaN values:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;@Test
    &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMath327() {
      &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[][] arr = {
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.99107143, 1.00000000, 1.00000000, 1.00000000,
              1.00000000, 0.94450431, 1.00000000, 1.00000000, 0.99107143,
              0.95238096, 1.00000000, 1.00000000, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 },
          { 1.00000000, 1.00000000, 0.94999999, 0.95833331, 1.00000000,
              1.00000000, 0.99107143, 0.94583333, 1.00000000, 0.95000000,
              0.98333333, 0.92106681, 0.97368419, 1.00000000, 0.95357142,
              0.95238096, 1.00000000, 0.93333334, 0.96428573 } };

      RealMatrix rcp = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Array2DRowRealMatrix(arr);
      SingularValueDecomposition svd = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; SingularValueDecompositionImpl(rcp);

      &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(svd.getU());
      &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(svd.getS());
      &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(svd.getVT());
      
&lt;span class=&quot;code-comment&quot;&gt;//      &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(svd.getU().multiply(svd.getS()).multiply(svd.getVT()));
&lt;/span&gt;      &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] singularValues = svd.getSingularValues();
      &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.err.println();
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="12796914" author="luc" created="Tue, 5 Jan 2010 23:21:48 +0000"  >&lt;p&gt;I got the NaN values too with the original values, but not the exception.&lt;/p&gt;

&lt;p&gt;Could you try the latest version for subversion repository ?&lt;/p&gt;

&lt;p&gt;It seems there are only a small number of different values in the initial matrix (about 14, depending on whether you consider 0.95000000 and 0.94999999 be the same 19.0/20.0 or not). The low print accuracy used by the default print leads to a problem: do we run the same test as the original one ? Could you provide the numbers to full precision ?&lt;/p&gt;

&lt;p&gt;With the original low accuracy data, the matrix is singular : it has 4 non-null singular values only: 30.157767108847377, 0.27095453462617336, 6.218305311492343E-8 and 7.32410687763558E-15. I&apos;m pretty sure the last one should really be zero, and not sure about the third one.&lt;br/&gt;
So the problem may be related to &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-320&quot; title=&quot;NaN singular value from SVD&quot;&gt;&lt;del&gt;MATH-320&lt;/del&gt;&lt;/a&gt;, and as Axel noticed, U is still wrong in this case on the last column, which corresponds to the very small but non-zero last singular value.&lt;/p&gt;</comment>
                    <comment id="12806069" author="luc" created="Thu, 28 Jan 2010 20:17:20 +0000"  >&lt;p&gt;The matrix is really exactly rank 2, regardless of the exact values of the elements, as there are only two different rows.&lt;br/&gt;
These rows are at indices 0 and 4. All other rows are copies of these ones.&lt;br/&gt;
The issue may be related to numerical problems, which would explain why we get the spurious 6.218305311492343E-8 and 7.32410687763558E-15 singular values.&lt;/p&gt;</comment>
                    <comment id="12915656" author="luc" created="Tue, 28 Sep 2010 07:22:45 +0000"  >&lt;p&gt;Checking again this issue with current version in branch 2.X on subversion repository.&lt;br/&gt;
Using the original low accuracy values and making sure we simply have two different rows, I get the two largest singular values 30.157767108847384 and 0.2709545346259456, a large set of 0 values and a last non null values at 3.547702387229884E-7.&lt;br/&gt;
Reconstructing the matrix from its decomposition and subtracting the initial matrix gives a norm of 7.9e-7.&lt;/p&gt;

&lt;p&gt;I suspect there are numerical problems here, enhanced by the large number of identical rows and initial low accuracy of the numbers in the issue report.&lt;br/&gt;
The current implementation of SVD uses directly A.At and At.A (where t is the transpose) and eigen decomposition. I think in this case lots of precision is lost. I would be happy with singular values and reconstruction errors at about 1.0e-10 or something like that, but a result larger than 1.0e-7 seems a real problem to me.&lt;/p&gt;</comment>
                    <comment id="12975153" author="psteitz" created="Sun, 26 Dec 2010 19:59:45 +0000"  >&lt;p&gt;Pushing out to 3.0, when we may need to reimplement SVD to deal with this and other numerical stability problems.&lt;/p&gt;</comment>
                    <comment id="13011196" author="pkfeldman" created="Fri, 25 Mar 2011 13:54:16 +0000"  >&lt;p&gt;Another unit test:&lt;br/&gt;
A &lt;span class=&quot;error&quot;&gt;&amp;#91;7 x 168&amp;#93;&lt;/span&gt; =&lt;br/&gt;
0.003000302	-0.005529946	0.01538155	-0.001403205	-0.018213096	0.000076204	-0.000023713	0.000093626	0.000143789	-0.000092728	-0.00009325	-0.000471574	0.000256266	-0.000235424	-0.000559821	-0.000181869	0.000070384	0.000005498	0.000383238	0.000187495	0.000744314	-0.000299571	0.000655884	-0.000367504	-0.000296129	0.001865159	0.002139813	0.001156764	-0.000274115	0.00194246	-0.001067201	-0.000965123	-0.000838439	-0.000233388	-0.000400203	0.000097493	0.000236697	-0.000612503	0.000248345	0.000058795	0.000121681	0.000441167	0.000328212	0.000333702	0.000739353	0.000205686	0.00011173	0.001217128	0.000488424	0.000382149	0.000308471	-0.000490277	0.000345624	-0.000834169	0.000216899	0.000433887	-0.000369019	0.000646984	-0.000300974	0.000373483	0.000647662	-0.000253848	0.000223624	0.000634534	0.000747524	-0.000077809	-0.000353221	0.000240388	0.000414233	0.000207479	0.000041459	-0.000305439	-0.000105042	0.00019835	0.000413267	0.000026096	-0.00046518	-0.000128547	-0.000043406	0.00005626	0.00000624	-0.000126197	-0.000020413	-0.000151383	-0.000024204	-0.000030944	0.000022925	-0.000064255	0.000240003	0.000262614	0.000044858	-0.000320061	-0.000030874	0.000131975	0.000079968	-0.000113183	0.000073552	-0.000008934	0.00004173	0.000052111	-0.000061729	0.000044233	0.00031579	0.000136546	0.000069494	0.000086781	-0.000040722	0.000040594	0.000105801	0.000037761	0.000010309	-0.000152556	0.000021932	0.000034306	0.000012486	-0.000005934	-0.000046878	0.000023209	0.000008168	0.000008117	-0.000016579	-0.00000505	0.000004528	-0.00000555	-0.000000095	-0.00000136	-0.000005205	-0.000002595	0.000000285	-0.000001563	-0.000000953	-0.000000364	-0.000001132	-0.000000645	-0.000000775	-0.000000144	-0.000000641	-0.00000031	-0.000000023	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002969656	-0.005304577	0.015172372	-0.001362703	-0.01832869	0.000054703	-0.000122829	-0.00003114	0.000041451	0.000025999	-0.000135931	-0.000186937	0.000239001	-0.000051824	-0.000383595	-0.00012191	-0.000021933	-0.000024977	0.000385048	0.000119015	0.000599602	-0.000358632	0.000726135	-0.000131523	-0.000116199	0.001494981	0.001850129	0.000724508	-0.000261562	0.001491656	-0.000748772	-0.000627043	-0.000597073	0.000000987	-0.000220861	-0.000078266	0.000303396	-0.000299759	0.000036112	0.000047285	0.000101568	0.000350496	0.000181929	0.000083279	0.00025771	0.000026141	-0.000010124	0.000382831	0.000080824	0.000021461	0.000143501	-0.000042618	0.000111455	-0.000339422	-0.000006761	0.000101824	-0.000082054	-0.000060832	-0.000124609	0.000138409	0.000029263	-0.000077077	0.000092533	-0.000011487	0.000023891	-0.000064685	0.000033676	0.000077876	0.000019453	0.000176876	-0.000211758	0.000035019	0.000043861	-0.000043324	0.000183336	-0.000029838	-0.000109527	0.000065992	-0.000221244	-0.000014366	-0.000032553	-0.000062429	0.00004144	0.000035076	0.000062257	0.000033082	0.000005334	0.000073079	-0.000159208	-0.000239372	-0.000056981	0.000281376	-0.000009754	-0.000031414	-0.000108677	0.000193121	-0.000082145	0.000036054	-0.000074536	-0.000005391	0.000091036	-0.00005061	-0.000360727	-0.000218139	-0.000109819	-0.000100537	0.000092986	-0.00010101	-0.000154437	-0.000115903	-0.000022312	0.000308967	-0.000020773	-0.000103365	-0.000013504	0.000011012	0.000171955	-0.000173067	-0.000026495	-0.000048153	0.000161432	0.000028197	-0.000036547	0.000067851	0.000013284	0.000040178	-0.000008893	0.000015076	-0.000015242	0.000013819	0.000003256	0.000000331	0.000014678	0.00000763	0.000002552	0.000004191	0.000004197	0.000000411	-0.000000075	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002887098	-0.005162996	0.014815235	-0.001285135	-0.017864999	0.00000749	-0.000086847	-0.000083018	0.000105148	0.000081389	-0.000091836	-0.000139615	0.000144603	0.000009173	-0.000390802	-0.000178339	-0.000026705	0.000019374	0.000339385	0.000106817	0.000534724	-0.000295593	0.000630123	-0.00006547	-0.000158208	0.001252922	0.001515506	0.000467301	-0.000238628	0.001181597	-0.000586928	-0.000454072	-0.000436001	0.00011785	-0.000120203	-0.000050288	0.000131089	-0.00013403	-0.000094773	0.000109751	0.000052716	0.000224419	0.000031617	-0.000005773	0.000039057	-0.000067576	-0.000073733	-0.000022599	-0.00008645	-0.000176968	-0.000001081	0.000065436	-0.000057159	0.000019626	-0.000076696	-0.000085582	0.000027081	-0.000237917	0.000027559	-0.000027321	-0.000138684	-0.000010139	0.000026879	-0.000280673	-0.000163613	-0.00006582	0.00008998	-0.000072257	-0.000129705	0.000144026	-0.000195254	0.000131956	0.000008668	-0.00004325	-0.000036238	-0.000014767	0.000003249	0.000103041	-0.000106909	-0.000013922	-0.000025123	0.000014109	0.000077397	0.000074812	0.000097137	0.000008743	-0.000015867	0.000078784	-0.000160333	-0.000220779	-0.000096102	0.000276578	0.000044677	-0.000166	-0.000113381	0.000126259	-0.000094119	0.000046776	0.000006033	-0.000019026	0.000047752	-0.000077061	-0.000245975	-0.000149312	-0.000033577	-0.000036015	0.000006292	-0.000016404	-0.000042226	0.000005486	-0.000030862	-0.000047629	-0.000008657	0.000011517	-0.00001011	-0.000010266	0.000024103	0.000041587	-0.000072901	0.00008128	-0.000182947	-0.000016937	0.000031871	-0.000074912	0.000004791	-0.000132392	0.00002209	-0.000042783	0.000027412	-0.000036629	-0.000013631	0.000006481	-0.000035375	-0.00002774	-0.000009908	-0.000015946	-0.000012614	-0.000001499	0.000000198	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002831307	-0.005036083	0.014495839	-0.001222631	-0.01743462	-0.000021877	-0.000089791	-0.00008631	0.000101769	0.000084557	-0.000093566	-0.000003847	0.000103268	0.000007839	-0.000342041	-0.000176391	-0.000013103	0.000043794	0.000266074	0.00011671	0.000488465	-0.00024847	0.000460824	-0.000028753	-0.00021999	0.001021342	0.001224627	0.000221835	-0.00029908	0.000917751	-0.000398617	-0.000299065	-0.000313377	0.000213555	-0.000069759	-0.000065952	0.000058733	-0.00002764	-0.000131624	0.000092763	0.000093374	0.000102217	-0.000039354	-0.000046958	-0.000102751	-0.000104948	-0.000110721	-0.000264731	-0.000183338	-0.000194462	-0.000097041	0.000096354	-0.000152521	0.000223908	-0.00014148	-0.00020514	0.000060268	-0.000291261	0.00009264	-0.000133008	-0.000194146	-0.000000404	0.000022513	-0.000420375	-0.000274199	-0.000004157	0.000118682	-0.000145176	-0.000187359	0.000118614	-0.000190098	0.000157552	-0.000000434	0.000005534	-0.000122158	-0.000035336	0.000091302	0.000070502	-0.000035075	0.000026897	-0.000026027	0.000068863	0.000030758	0.000118906	0.000052865	-0.000026329	-0.00000826	0.000101079	-0.000197935	-0.000140233	-0.000114663	0.000170086	0.000034608	-0.000173948	-0.000106214	0.000022543	-0.000095437	0.000028632	0.000052431	0.000005499	-0.000007454	-0.000044578	-0.000000059	0.000043577	0.000018142	0.000032244	-0.000026283	0.000068926	0.000042058	0.000008931	-0.000011774	-0.000111127	-0.000011769	0.000009934	0.000014911	-0.000079832	-0.000083897	0.000157805	0.000059901	-0.000004452	-0.000123879	-0.000055225	0.000008354	-0.000052262	-0.000087207	0.000107662	0.000039901	0.000035044	0.000016752	0.000021868	0.000026419	-0.000009502	0.000036966	0.000039395	0.000019642	0.000030458	0.000013378	0.000008617	-0.000000132	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002756109	-0.004887643	0.014196414	-0.00116362	-0.01703753	0.000004375	-0.000097905	-0.000069192	0.000084888	0.000113941	-0.000104082	0.000006669	0.000086462	-0.000044821	-0.000238952	-0.000135702	0.000022235	0.000037076	0.000177186	0.000152045	0.000381545	-0.000224624	0.000260298	-0.000069067	-0.000207512	0.000794191	0.00090326	0.000111248	-0.00026504	0.00064074	-0.000259072	-0.000186556	-0.000222422	0.000225984	-0.000048346	-0.000070009	0.000011544	0.000062158	-0.000140825	0.000057386	0.000083756	0.000017278	-0.000134431	-0.000146456	-0.000251551	-0.000135834	-0.000087733	-0.000452141	-0.000243808	-0.000136996	-0.000212436	0.000144639	-0.000265376	0.000421396	-0.000148677	-0.000262259	0.000043509	-0.000298101	0.000123116	-0.000182754	-0.000189525	0.000046441	-0.000032655	-0.000384988	-0.000406727	0.000091405	0.000189811	-0.000144187	-0.000117633	0.000105068	-0.000075964	0.000148894	0.00004975	0.000094222	-0.000219824	-0.000073299	0.000100216	0.000046446	-0.00002118	0.000072675	0.00004038	0.000129741	-0.000046565	0.00011456	-0.000035221	-0.0000787	0.000024227	0.000092911	-0.000123184	-0.000023855	-0.000078062	0.000047717	0.000046576	-0.000088641	-0.00002932	-0.000090071	-0.000041614	0.000003208	0.000036034	0.000008077	0.000009485	-0.000014586	0.000140279	0.000173089	0.000056949	0.000011312	-0.000016935	0.0000546	0.000071702	0.000054964	0.000038482	-0.000020307	0.000019496	-0.000076559	0.000037942	-0.000004126	-0.000097085	0.000158935	0.000084689	-0.000032025	0.000027741	-0.000001712	0.000047726	0.000067935	0.000062807	0.000042019	-0.000107553	0.000003783	-0.000068377	0.000033799	-0.000008086	-0.000014471	-0.000014571	-0.000012693	-0.000021009	-0.000043842	-0.000001391	-0.00002082	0.000000039	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002713439	-0.004752147	0.013965534	-0.001108472	-0.01672038	0.000009941	-0.000112401	-0.00006527	0.000078248	0.000152419	-0.000116667	0.000033126	0.000064384	-0.00007936	-0.000147899	-0.000068426	0.000033315	0.00002579	0.000120293	0.000215288	0.000323611	-0.000171217	0.000157969	-0.00005578	-0.00015296	0.000572407	0.000688925	0.000060766	-0.00020446	0.00048807	-0.00014862	-0.00009754	-0.000180141	0.000210196	-0.000036916	-0.000060428	0.00000925	0.000081098	-0.000136197	0.000013623	0.000080662	-0.000003224	-0.000165756	-0.00019215	-0.000308542	-0.000137013	-0.000061222	-0.000510196	-0.000248039	-0.000057964	-0.000224912	0.000125232	-0.000278473	0.000514189	-0.000154484	-0.000254711	-0.000009644	-0.000268256	0.000156188	-0.000188104	-0.000139626	0.000072911	-0.00008888	-0.000233338	-0.00046348	0.000144267	0.000185848	-0.000069423	-0.000046224	0.000076921	0.000062911	0.000085604	0.000134094	0.000122251	-0.000171917	-0.000080133	0.000124002	-0.000011948	-0.00006699	0.000122377	0.000084481	0.000108265	-0.000117191	0.000053756	-0.000096093	-0.000050405	0.000012092	0.000013554	-0.000033783	0.00004524	0.000030117	-0.000098499	0.000016659	0.000051857	0.000022419	-0.000134127	0.000007665	-0.000040693	-0.000026113	-0.000036273	0.000006864	0.000076699	0.000169231	0.000164427	0.000030649	0.000033798	-0.00002345	-0.00001429	0.000047296	0.00007971	0.000069608	0.000062877	0.000017838	-0.000017769	0.00002631	0.000071317	-0.000130968	0.000042289	0.000067647	-0.000064236	0.000128106	0.000063577	0.000000735	0.000037498	0.000047856	-0.000035523	0.000035664	0.000029723	0.000045477	-0.000025745	-0.000041613	0.000047659	-0.000017681	-0.000030828	0.00001873	0.000035826	-0.000004717	0.000033014	0.000000109	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;br/&gt;
0.002654198	-0.004617799	0.013738668	-0.00106814	-0.016441538	0.000020623	-0.000085095	-0.00006464	0.000053609	0.000186066	-0.000107783	0.000031834	0.000022983	-0.000074228	-0.000068779	-0.000039889	0.000029619	0.000041417	0.000044411	0.000255179	0.000198631	-0.000132924	0.000082586	-0.00006463	-0.000063918	0.000359364	0.000438507	0.00003992	-0.000101309	0.000328214	-0.000061309	0.000003358	-0.000096576	0.000163887	-0.000022349	-0.000050092	-0.000012869	0.000115162	-0.000111409	-0.000009761	0.000077735	0.000014956	-0.000206665	-0.000207496	-0.000314351	-0.000161785	-0.000017807	-0.000524724	-0.000276115	0.000019489	-0.000205149	0.00009544	-0.000241665	0.000578938	-0.000166919	-0.00022578	-0.000108395	-0.000231887	0.000217214	-0.000205621	-0.000083071	0.000108178	-0.000157203	0.000010994	-0.000467108	0.000166157	0.000150765	-0.000021731	0.00002444	0.000040855	0.000246309	-0.000001378	0.000270913	0.000055249	-0.000110662	-0.000061757	0.000080507	-0.000087269	-0.000080525	0.000103341	0.000076934	0.000031422	-0.000094885	0.000004692	-0.000073083	0.000050076	-0.000016419	-0.000076807	0.00008026	0.000072597	0.000083693	-0.00015694	0.00000627	0.00009672	0.000092051	-0.000114397	0.000057658	-0.000030369	-0.000037034	-0.000059939	-0.000030038	0.000095397	0.000100554	0.000056162	0.000021134	0.00002121	0.00001418	-0.000050626	0.00000043	0.000054517	0.000023516	0.000065812	0.00000895	0.000094756	-0.000010199	0.000131197	-0.00010293	-0.000061066	0.000003383	0.00000012	0.000065144	0.000028177	-0.000085212	-0.00000508	0.000002609	-0.000083369	0.0000428	-0.000049929	0.000005855	-0.000043563	0.000045236	-0.000031818	0.000035129	0.000036617	-0.000019773	0.000008113	0.000001782	-0.000039179	-0.000000243	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0&lt;/p&gt;

&lt;p&gt;b &lt;span class=&quot;error&quot;&gt;&amp;#91;7 x 1&amp;#93;&lt;/span&gt; =&lt;br/&gt;
-0.1&lt;br/&gt;
-0.066666667&lt;br/&gt;
-0.033333333&lt;br/&gt;
0.000000001&lt;br/&gt;
0.008333333&lt;br/&gt;
0.016666667&lt;br/&gt;
0.025&lt;/p&gt;

&lt;p&gt;The SVD solve in ACM 2.2 throws the MaxIterationsExceededError. &lt;br/&gt;
In R, the solve works:&lt;br/&gt;
pinv &amp;lt;- with(svd(A), v %&lt;b&gt;% diag(1/d) %&lt;/b&gt;% t(u))&lt;br/&gt;
x &amp;lt;- pinv %*% b&lt;/p&gt;</comment>
                    <comment id="13011212" author="luc" created="Fri, 25 Mar 2011 14:09:00 +0000"  >&lt;p&gt;Thanks for the new test case. Could you run it again with an increased print accuracy and exponential format please ? Something like new DecimalFormat(&quot;0.###############E00&quot;) will be fine.&lt;/p&gt;</comment>
                    <comment id="13068315" author="luc" created="Wed, 20 Jul 2011 12:18:41 +0000"  >&lt;p&gt;Fixed in subversion repository as of r1148714.&lt;/p&gt;

&lt;p&gt;This issue was fixed by changing SVD implementation according to issue &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-611&quot; title=&quot;A fast and stable SVD implementation from JAMA&quot;&gt;&lt;del&gt;MATH-611&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="12310010">
                <name>Incorporates</name>
                                                <inwardlinks description="is part of">
                            <issuelink>
            <issuekey id="12512945">MATH-611</issuekey>
        </issuelink>
                    </inwardlinks>
                            </issuelinktype>
                    </issuelinks>
                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 5 Jan 2010 22:40:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-326] getLInfNorm() uses wrong formula in both ArrayRealVector and OpenMapRealVector (in different ways)</title>
                <link>https://issues.apache.org/jira/browse/MATH-326</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;the L_infinity norm of a finite dimensional vector is just the max of the absolute value of its entries.&lt;/p&gt;

&lt;p&gt;The current implementation in ArrayRealVector has a typo:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; getLInfNorm() {
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; max = 0;
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; a : data) {
            max += &lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.max(max, &lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.abs(a));
        }
        &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; max;
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;the += should just be an =.&lt;/p&gt;

&lt;p&gt;There is sadly a unit test assuring us that this is the correct behavior (effectively a regression-only test, not a test for correctness).&lt;/p&gt;

&lt;p&gt;Worse, the implementation in OpenMapRealVector is not even positive semi-definite:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; getLInfNorm() {
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; max = 0;
        Iterator iter = entries.iterator();
        &lt;span class=&quot;code-keyword&quot;&gt;while&lt;/span&gt; (iter.hasNext()) {
            iter.advance();
            max += iter.value();
        }
        &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; max;
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I would suggest that this method be moved up to the AbstractRealVector superclass and implemented using the sparseIterator():&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; getLInfNorm() {
    &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; norm = 0;
    Iterator&amp;lt;Entry&amp;gt; it = sparseIterator();
    Entry e;
    &lt;span class=&quot;code-keyword&quot;&gt;while&lt;/span&gt;(it.hasNext() &amp;amp;&amp;amp; (e = it.next()) != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
      norm = &lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.max(norm, &lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.abs(e.getValue()));
    }
    &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; norm;
  }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Unit tests with negative valued vectors would be helpful to check for this kind of thing in the future.&lt;/p&gt;</description>
                <environment>&lt;p&gt;all&lt;/p&gt;</environment>
            <key id="12444282">MATH-326</key>
            <summary>getLInfNorm() uses wrong formula in both ArrayRealVector and OpenMapRealVector (in different ways)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jake.mannix">Jake Mannix</reporter>
                        <labels>
                    </labels>
                <created>Tue, 29 Dec 2009 00:09:20 +0000</created>
                <updated>Sat, 3 Apr 2010 20:37:40 +0000</updated>
                    <resolved>Tue, 29 Dec 2009 12:26:59 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12795040" author="luc" created="Tue, 29 Dec 2009 12:26:59 +0000"  >&lt;p&gt;Fixed in subversion repository as of r894367.&lt;br/&gt;
For consistency, the implementation of L1 and L2 norms have also been pushed upward in the abstract class.&lt;br/&gt;
Thanks for reporting and providing a fix to this bug&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 29 Dec 2009 12:26:59 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-322] during ODE integration, the last event in a pair of very close event may not be detected</title>
                <link>https://issues.apache.org/jira/browse/MATH-322</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When an events follows a previous one very closely, it may be ignored. The occurrence of the bug depends on the side of the bracketing interval that was selected. For example consider a switching function that is increasing around first event around t = 90, reaches its maximum and is decreasing around the second event around t = 135. If an integration step spans from 67.5 and 112.5, the switching function values at start and end of step will  have opposite signs, so the first event will be detected. The solver will find the event really occurs at 90.0 and will therefore truncate the step at 90.0. The next step will start from where the first step ends, i.e. it will start at 90.0. Let&apos;s say this step spans from 90.0 to 153.0. The switching function switches once again in this step.&lt;/p&gt;

&lt;p&gt;If the solver for the first event converged to a value slightly before 90.0 (say 89.9999999), then the switch will not be detected because g(89.9999999) and g(153.0) are both negative.&lt;/p&gt;

&lt;p&gt;This bug was introduced as of r781157 (2009-06-02) when special handling of events very close to step start was added.&lt;/p&gt;</description>
                <environment>&lt;p&gt;All&lt;/p&gt;</environment>
            <key id="12442588">MATH-322</key>
            <summary>during ODE integration, the last event in a pair of very close event may not be detected</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Sun, 6 Dec 2009 23:01:35 +0000</created>
                <updated>Sat, 3 Apr 2010 20:48:07 +0000</updated>
                    <resolved>Sun, 6 Dec 2009 23:06:04 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12786733" author="luc" created="Sun, 6 Dec 2009 23:06:04 +0000"  >&lt;p&gt;fixed in subversion repository as of r887794&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-320] NaN singular value from SVD</title>
                <link>https://issues.apache.org/jira/browse/MATH-320</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The following jython code&lt;br/&gt;
Start code&lt;/p&gt;

&lt;p&gt;from org.apache.commons.math.linear import *&lt;/p&gt;

&lt;p&gt;Alist = [&lt;span class=&quot;error&quot;&gt;&amp;#91;1.0, 2.0, 3.0&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;2.0,3.0,4.0&amp;#93;&lt;/span&gt;,&lt;span class=&quot;error&quot;&gt;&amp;#91;3.0,5.0,7.0&amp;#93;&lt;/span&gt;]&lt;/p&gt;

&lt;p&gt;A = Array2DRowRealMatrix(Alist)&lt;/p&gt;

&lt;p&gt;decomp = SingularValueDecompositionImpl(A)&lt;/p&gt;

&lt;p&gt;print decomp.getSingularValues()&lt;/p&gt;

&lt;p&gt;End code&lt;/p&gt;

&lt;p&gt;prints&lt;br/&gt;
array(&apos;d&apos;, &lt;span class=&quot;error&quot;&gt;&amp;#91;11.218599757513008, 0.3781791648535976, nan&amp;#93;&lt;/span&gt;)&lt;br/&gt;
The last singular value should be something very close to 0 since the matrix&lt;br/&gt;
is rank deficient.  When i use the result from getSolver() to solve a system, i end &lt;br/&gt;
up with a bunch of NaNs in the solution.  I assumed i would get back a least squares solution.&lt;/p&gt;

&lt;p&gt;Does this SVD implementation require that the matrix be full rank?  If so, then i would expect&lt;br/&gt;
an exception to be thrown from the constructor or one of the methods.&lt;/p&gt;

</description>
                <environment>&lt;p&gt;Linux (Ubuntu 9.10) java version &quot;1.6.0_16&quot;&lt;/p&gt;</environment>
            <key id="12440296">MATH-320</key>
            <summary>NaN singular value from SVD</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="dieterv77">Dieter Vandenbussche</reporter>
                        <labels>
                    </labels>
                <created>Tue, 10 Nov 2009 15:42:34 +0000</created>
                <updated>Thu, 23 Jun 2011 20:02:56 +0000</updated>
                    <resolved>Thu, 31 Dec 2009 17:55:04 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12776063" author="luc" created="Tue, 10 Nov 2009 20:23:02 +0000"  >&lt;p&gt;This is a real new bug, thanks for reporting it.&lt;/p&gt;

&lt;p&gt;Before I look more precisely at it, could you do a quick check for me ?&lt;/p&gt;

&lt;p&gt;If at the end of the SingularValueDecompositionImpl constructor, around line 118 in the java source file you change from:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;  singularValues[i] = Math.sqrt(singularValues[i]);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;to&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;  singularValues[i] = Math.sqrt(Math.max(0, singularValues[i]));
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;does the problem still appear on singular values and does the solver work properly ?&lt;/p&gt;</comment>
                    <comment id="12776449" author="dieterv77" created="Wed, 11 Nov 2009 13:37:27 +0000"  >&lt;p&gt;Yes, making that change fixes the singular values, printing the singular values now gives&lt;/p&gt;

&lt;p&gt;array(&apos;d&apos;, &lt;span class=&quot;error&quot;&gt;&amp;#91;11.218599757513008, 0.3781791648535976, 0.0&amp;#93;&lt;/span&gt;)&lt;/p&gt;

&lt;p&gt;The unittests for the project still pass as well.&lt;/p&gt;

&lt;p&gt;However, now the solve fails with a SinularMatrixException&lt;/p&gt;

&lt;p&gt;Traceback (most recent call last):&lt;br/&gt;
  File &quot;testdecomp.py&quot;, line 14, in &amp;lt;module&amp;gt;&lt;br/&gt;
    soln = solver.solve(&lt;span class=&quot;error&quot;&gt;&amp;#91;5.0, 6.0,7.0&amp;#93;&lt;/span&gt;)&lt;br/&gt;
	at org.apache.commons.math.linear.SingularValueDecompositionImpl$Solver.solve(SingularValueDecompositionImpl.java:371)&lt;br/&gt;
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)&lt;br/&gt;
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)&lt;br/&gt;
	at java.lang.reflect.Method.invoke(Method.java:597)&lt;/p&gt;

&lt;p&gt;org.apache.commons.math.linear.SingularMatrixException: org.apache.commons.math.linear.SingularMatrixException: matrix is singular&lt;/p&gt;

&lt;p&gt;This confuses me, i guess i&apos;m assuming incorrectly that if the solve method can solve in the least squares sense, then it should be&lt;br/&gt;
able to handle singular matrices.  Is that just a restriction on the current solve methods and if so, are there plans to relax that restriction?&lt;/p&gt;

&lt;p&gt;thanks very much for your time&lt;/p&gt;</comment>
                    <comment id="12776462" author="luc" created="Wed, 11 Nov 2009 14:21:59 +0000"  >&lt;p&gt;The method should solve the problem in the least square sense.&lt;br/&gt;
The fact it does not do it is not a restriction, it&apos;s a bug.&lt;br/&gt;
I&apos;ll have a look at it&lt;/p&gt;</comment>
                    <comment id="12792062" author="axelclk" created="Thu, 17 Dec 2009 18:43:44 +0000"  >
&lt;p&gt;Is this a similar problem for the getU() method?&lt;/p&gt;

&lt;p&gt;  public void testU() {&lt;br/&gt;
      double[][] testMatrix = {&lt;br/&gt;
          { 1.0 , 2.0 },&lt;br/&gt;
          { 1.0 , 2.0 } };&lt;br/&gt;
      SingularValueDecompositionImpl svd =&lt;br/&gt;
          new SingularValueDecompositionImpl(MatrixUtils.createRealMatrix(testMatrix));&lt;br/&gt;
// wrong result:&lt;br/&gt;
      assertEquals(&quot;Array2DRowRealMatrix{{-0.7071067811865472,NaN},{-0.7071067811865475,NaN}}&quot;, svd.getU().toString());&lt;br/&gt;
    }&lt;/p&gt;</comment>
                    <comment id="12792132" author="luc" created="Thu, 17 Dec 2009 21:21:11 +0000"  >&lt;p&gt;The two issues are probably related.&lt;br/&gt;
I&apos;ll look at both cases.&lt;/p&gt;</comment>
                    <comment id="12795490" author="luc" created="Wed, 30 Dec 2009 23:27:04 +0000"  >&lt;p&gt;A first round on fixing this bug has been committed in the subversion repository as of r894735.&lt;br/&gt;
Axel example is confirmed to be an occurrence of the same bug as Dieter example.&lt;/p&gt;

&lt;p&gt;The SVD is now computed either as a compact SVD (only positive singular values considered) or as a truncated SVD&lt;br/&gt;
(max number of singular values to consider is user-specified). The solver simply applies the pseudo-inverse.&lt;/p&gt;

&lt;p&gt;The fix is not considered complete yet because I think that the results provided by the solver are not really the ones&lt;br/&gt;
that give the smallest residuals. See for example the commented out parts of testMath320A in&lt;br/&gt;
SingularValueSolverTest.  Could you check this, please ?&lt;/p&gt;</comment>
                    <comment id="12795591" author="axelclk" created="Thu, 31 Dec 2009 11:57:52 +0000"  >&lt;p&gt;This statement should print the values of the original matrix approximately:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(svd.getU().multiply(svd.getS()).multiply(svd.getVT()));&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;This is true for&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMath320A() {&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 
&lt;p&gt;but not for&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMath320B() {&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;For reference values try wolfram alpha:&lt;br/&gt;
N[SingularValueDecomposition&lt;span class=&quot;error&quot;&gt;&amp;#91;{{1,2},{1,2}}&amp;#93;&lt;/span&gt;]&lt;/p&gt;</comment>
                    <comment id="12795606" author="luc" created="Thu, 31 Dec 2009 14:47:19 +0000"  >&lt;p&gt;Thanks for the hint Axel!&lt;br/&gt;
The print statement is even not satisfying for testMath320A, the approximation is really too bad. I would expect about 13 exact figures, not 1 or 2.&lt;br/&gt;
The problem seems to be related to matrix U which is not correct. In fact, it is even not unitary (i.e. U^T^.U is not the identity matrix).&lt;br/&gt;
I&apos;ll look at this.&lt;/p&gt;</comment>
                    <comment id="12795628" author="luc" created="Thu, 31 Dec 2009 17:55:04 +0000"  >&lt;p&gt;This should be fixed in subversion repository now (r894908).&lt;br/&gt;
Thanks for reporting the bug and sorry for the delay.&lt;/p&gt;</comment>
                    <comment id="13054069" author="gsteri1" created="Thu, 23 Jun 2011 20:02:56 +0000"  >&lt;p&gt;Did anyone notice that the 3rd eigenvalue is negative? On my box the eigenvalue is -2.1028862676867717E-14. I am not sure what the fix was, but whatever problems existed still persist. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 10 Nov 2009 20:23:02 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-318] wrong result in eigen decomposition</title>
                <link>https://issues.apache.org/jira/browse/MATH-318</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Some results computed by EigenDecompositionImpl are wrong. The following case computed by Fortran Lapack fails with version 2.0&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMathpbx02() {

        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] mainTridiagonal = {
        	  7484.860960227216, 18405.28129035345, 13855.225609560746,
        	 10016.708722343366, 559.8117399576674, 6750.190788301587, 
        	    71.21428769782159
        };
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] secondaryTridiagonal = {
        	 -4175.088570476366,1975.7955858241994,5193.178422374075, 
        	  1995.286659169179,75.34535882933804,-234.0808002076056
        };

        &lt;span class=&quot;code-comment&quot;&gt;// the reference values have been computed using routine DSTEMR
&lt;/span&gt;        &lt;span class=&quot;code-comment&quot;&gt;// from the fortran library LAPACK version 3.2.1
&lt;/span&gt;        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] refEigenValues = {
        		20654.744890306974412,16828.208208485466457,
        		6893.155912634994820,6757.083016675340332,
        		5887.799885688558788,64.309089923240379,
        		57.992628792736340
        };
        RealVector[] refEigenVectors = {
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {-0.270356342026904, 0.852811091326997, 0.399639490702077, 0.198794657813990, 0.019739323307666, 0.000106983022327, -0.000001216636321}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.179995273578326,-0.402807848153042,0.701870993525734,0.555058211014888,0.068079148898236,0.000509139115227,-0.000007112235617}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {-0.399582721284727,-0.056629954519333,-0.514406488522827,0.711168164518580,0.225548081276367,0.125943999652923,-0.004321507456014}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.058515721572821,0.010200130057739,0.063516274916536,-0.090696087449378,-0.017148420432597,0.991318870265707,-0.034707338554096}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.855205995537564,0.327134656629775,-0.265382397060548,0.282690729026706,0.105736068025572,-0.009138126622039,0.000367751821196}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {-0.002913069901144,-0.005177515777101,0.041906334478672,-0.109315918416258,0.436192305456741,0.026307315639535,0.891797507436344}),
        		&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {-0.005738311176435,-0.010207611670378,0.082662420517928,-0.215733886094368,0.861606487840411,-0.025478530652759,-0.451080697503958})
        };

        &lt;span class=&quot;code-comment&quot;&gt;// the following line triggers the exception
&lt;/span&gt;        EigenDecomposition decomposition =
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; EigenDecompositionImpl(mainTridiagonal, secondaryTridiagonal, MathUtils.SAFE_MIN);

        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] eigenValues = decomposition.getRealEigenvalues();
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; i = 0; i &amp;lt; refEigenValues.length; ++i) {
            assertEquals(refEigenValues[i], eigenValues[i], 1.0e-3);
            &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (refEigenVectors[i].dotProduct(decomposition.getEigenvector(i)) &amp;lt; 0) {
                assertEquals(0, refEigenVectors[i].add(decomposition.getEigenvector(i)).getNorm(), 1.0e-5);
            } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                assertEquals(0, refEigenVectors[i].subtract(decomposition.getEigenvector(i)).getNorm(), 1.0e-5);
            }
        }

    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12440038">MATH-318</key>
            <summary>wrong result in eigen decomposition</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Fri, 6 Nov 2009 15:09:36 +0000</created>
                <updated>Sat, 3 Apr 2010 20:49:07 +0000</updated>
                    <resolved>Fri, 6 Nov 2009 15:12:47 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12774307" author="luc" created="Fri, 6 Nov 2009 15:12:47 +0000"  >&lt;p&gt;fixed in subversion repository as of r833433.&lt;br/&gt;
Thanks again to Dimitri would found and fixed this bug.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-309] nextExponential parameter check bug - patch supplied</title>
                <link>https://issues.apache.org/jira/browse/MATH-309</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Index: src/main/java/org/apache/commons/math/random/RandomDataImpl.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; src/main/java/org/apache/commons/math/random/RandomDataImpl.java	(revision 830102)&lt;br/&gt;
+++ src/main/java/org/apache/commons/math/random/RandomDataImpl.java	(working copy)&lt;br/&gt;
@@ -462,7 +462,7 @@&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;@return the random Exponential value&lt;br/&gt;
      */&lt;br/&gt;
     public double nextExponential(double mean) {&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;if (mean &amp;lt; 0.0) {&lt;br/&gt;
+        if (mean &amp;lt;= 0.0) &lt;div class=&quot;error&quot;&gt;&lt;span class=&quot;error&quot;&gt;Unknown macro: {             throw MathRuntimeException.createIllegalArgumentException(                   &amp;quot;mean must be positive ({0})&amp;quot;, mean);         }&lt;/span&gt; &lt;/div&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Ubuntu 9.04&lt;/p&gt;</environment>
            <key id="12439175">MATH-309</key>
            <summary>nextExponential parameter check bug - patch supplied</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mikl">Mikkel Meyer Andersen</reporter>
                        <labels>
                    </labels>
                <created>Tue, 27 Oct 2009 13:20:53 +0000</created>
                <updated>Sat, 3 Apr 2010 20:52:59 +0000</updated>
                    <resolved>Sat, 31 Oct 2009 02:33:15 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                <version>1.2</version>
                <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                          <timeoriginalestimate seconds="300">5m</timeoriginalestimate>
                    <timeestimate seconds="300">5m</timeestimate>
                                  <comments>
                    <comment id="12772212" author="psteitz" created="Sat, 31 Oct 2009 02:33:15 +0000"  >&lt;p&gt;Fixed in r831510.  Thanks for reporting this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12423317" name="patch_random_exp" size="630" author="mikl" created="Tue, 27 Oct 2009 13:21:43 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 31 Oct 2009 02:33:15 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-308] ArrayIndexOutOfBoundException in EigenDecompositionImpl</title>
                <link>https://issues.apache.org/jira/browse/MATH-308</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The following test triggers an ArrayIndexOutOfBoundException:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testMath308() {

        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] mainTridiagonal = {
            22.330154644539597, 46.65485522478641, 17.393672330044705, 54.46687435351116, 80.17800767709437
        };
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] secondaryTridiagonal = {
            13.04450406501361, -5.977590941539671, 2.9040909856707517, 7.1570352792841225
        };

        &lt;span class=&quot;code-comment&quot;&gt;// the reference values have been computed using routine DSTEMR
&lt;/span&gt;        &lt;span class=&quot;code-comment&quot;&gt;// from the fortran library LAPACK version 3.2.1
&lt;/span&gt;        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] refEigenValues = {
            14.138204224043099, 18.847969733754262, 52.536278520113882, 53.456697699894512, 82.044413207204002
        };
        RealVector[] refEigenVectors = {
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {  0.584677060845929, -0.367177264979103, -0.721453187784497,  0.052971054621812, -0.005740715188257 }),
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {  0.713933751051495, -0.190582113553930,  0.671410443368332, -0.056056055955050,  0.006541576993581 }),
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {  0.222368839324646,  0.514921891363332, -0.021377019336614,  0.801196801016305, -0.207446991247740 }),
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {  0.314647769490148,  0.750806415553905, -0.167700312025760, -0.537092972407375,  0.143854968127780 }),
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { -0.000462690386766, -0.002118073109055,  0.011530080757413,  0.252322434584915,  0.967572088232592 })
        };

        &lt;span class=&quot;code-comment&quot;&gt;// the following line triggers the exception
&lt;/span&gt;        EigenDecomposition decomposition =
            &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; EigenDecompositionImpl(mainTridiagonal, secondaryTridiagonal, MathUtils.SAFE_MIN);

        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] eigenValues = decomposition.getRealEigenvalues();
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; i = 0; i &amp;lt; refEigenValues.length; ++i) {
            assertEquals(refEigenValues[i], eigenValues[i], 1.0e-6);
            &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (refEigenVectors[i].dotProduct(decomposition.getEigenvector(i)) &amp;lt; 0) {
                assertEquals(0, refEigenVectors[i].add(decomposition.getEigenvector(i)).getNorm(), 1.0e-6);
            } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                assertEquals(0, refEigenVectors[i].subtract(decomposition.getEigenvector(i)).getNorm(), 1.0e-6);
            }
        }

    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Running the previous method as a Junit test triggers the exception when the EigenDecompositionImpl instance is built. The first few lines of the stack trace are:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;java.lang.ArrayIndexOutOfBoundsException: -1
	at org.apache.commons.math.linear.EigenDecompositionImpl.computeShiftIncrement(EigenDecompositionImpl.java:1545)
	at org.apache.commons.math.linear.EigenDecompositionImpl.goodStep(EigenDecompositionImpl.java:1072)
	at org.apache.commons.math.linear.EigenDecompositionImpl.processGeneralBlock(EigenDecompositionImpl.java:894)
	at org.apache.commons.math.linear.EigenDecompositionImpl.findEigenvalues(EigenDecompositionImpl.java:658)
	at org.apache.commons.math.linear.EigenDecompositionImpl.decompose(EigenDecompositionImpl.java:246)
	at org.apache.commons.math.linear.EigenDecompositionImpl.&amp;lt;init&amp;gt;(EigenDecompositionImpl.java:205)
	at org.apache.commons.math.linear.EigenDecompositionImplTest.testMath308(EigenDecompositionImplTest.java:136)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I&apos;m currently investigating this bug. It is not a simple index translation error between the original fortran (Lapack) and commons-math implementation.&lt;/p&gt;</description>
                <environment>&lt;p&gt;linux&lt;/p&gt;</environment>
            <key id="12439042">MATH-308</key>
            <summary>ArrayIndexOutOfBoundException in EigenDecompositionImpl</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Sun, 25 Oct 2009 22:25:23 +0000</created>
                <updated>Wed, 14 Apr 2010 00:02:36 +0000</updated>
                    <resolved>Tue, 3 Nov 2009 22:19:04 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12773246" author="luc" created="Tue, 3 Nov 2009 22:19:04 +0000"  >&lt;p&gt;fixed in subversion repository as of r832577&lt;br/&gt;
Many thanks to Dimitri who debugged this with a careful step by step comparison between the original lapack fortran and our translation in Java.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-307] BigReal/Fieldelement divide without setting a proper scale -&gt; exception: no exact representable decimal result</title>
                <link>https://issues.apache.org/jira/browse/MATH-307</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;BigReal implements the methode divide of Fieldelement. The problem is that there is no scale defined for the BigDecimal so the class will throw an error when the outcome is not a representable decimal result. &lt;br/&gt;
(Exception: no exact representable decimal result)&lt;/p&gt;

&lt;p&gt;The workaround for me was to copy the BigReal and set the scale and roundingMode the same as version 1.2.&lt;/p&gt;

&lt;p&gt;Maybe is it possible to set the scale in FieldMatrix and implements it also a divide(BigReal b, int scale, int roundMode) ?? &lt;/p&gt;
</description>
                <environment>&lt;p&gt;independent&lt;/p&gt;</environment>
            <key id="12438999">MATH-307</key>
            <summary>BigReal/Fieldelement divide without setting a proper scale -&gt; exception: no exact representable decimal result</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="joan">Joan Schipper</reporter>
                        <labels>
                    </labels>
                <created>Sat, 24 Oct 2009 14:36:24 +0000</created>
                <updated>Wed, 14 Apr 2010 00:03:39 +0000</updated>
                    <resolved>Sun, 24 Jan 2010 10:35:39 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                          <timeoriginalestimate seconds="14400">4h</timeoriginalestimate>
                    <timeestimate seconds="14400">4h</timeestimate>
                                  <comments>
                    <comment id="12794725" author="luc" created="Sun, 27 Dec 2009 20:04:40 +0000"  >&lt;p&gt;I have added rounding mode and scale fields in BigReal in subversion tree as of r894107.&lt;br/&gt;
Could you please check if this solves the issue for you ?&lt;/p&gt;</comment>
                    <comment id="12794738" author="joan" created="Sun, 27 Dec 2009 21:00:18 +0000"  >
&lt;p&gt;Thank you for your reply and effort.&lt;/p&gt;

&lt;p&gt;If this method is replaced for the implementation of scale and roundingMode it will certainly work:&lt;/p&gt;

&lt;p&gt;old method:&lt;/p&gt;

&lt;p&gt;  public BigReal divide(BigReal a) throws ArithmeticException {
       return new BigReal(d.divide(a.d));
   }&lt;/p&gt;

&lt;p&gt;suggested method:&lt;/p&gt;

&lt;p&gt;  public BigReal divide(BigReal a) throws ArithmeticException {
       return new BigReal(d.divide(a.d, scale, roundingMode));
   }&lt;/p&gt;

&lt;p&gt;Joan &lt;/p&gt;</comment>
                    <comment id="12794739" author="joan" created="Sun, 27 Dec 2009 21:00:30 +0000"  >
&lt;p&gt;Thank you for your reply and effort.&lt;/p&gt;

&lt;p&gt;If this method is replaced for the implementation of scale and &lt;br/&gt;
roundingMode it will certainly work:&lt;/p&gt;

&lt;p&gt;   public BigReal divide(BigReal a) throws ArithmeticException {
        return new BigReal(d.divide(a.d));
    }&lt;/p&gt;

&lt;p&gt;is replaced by:&lt;/p&gt;

&lt;p&gt;   public BigReal divide(BigReal a) throws ArithmeticException {
        return new BigReal(d.divide(a.d, scale, roundingMode));
    }&lt;/p&gt;

&lt;p&gt;Joan&lt;/p&gt;
</comment>
                    <comment id="12794741" author="luc" created="Sun, 27 Dec 2009 21:08:01 +0000"  >&lt;p&gt;Oops. Sorry for having forgotten this ... I&apos;ve checked it in now.&lt;/p&gt;</comment>
                    <comment id="12804221" author="luc" created="Sun, 24 Jan 2010 10:35:39 +0000"  >&lt;p&gt;Fixed since 2009-12-27 as of r894109&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 27 Dec 2009 20:04:40 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-306] Method &apos;divide&apos; in class &apos;Complex&apos; uses a false formula for a special case resulting in erroneous division by zero.</title>
                <link>https://issues.apache.org/jira/browse/MATH-306</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The formula that &apos;divide&apos; wants to implement is&lt;/p&gt;

&lt;p&gt;( a + bi )  /  ( c + di )  =  ( ac + bd + ( bc - ad ) i )  /  ( c^2 + d^2 )&lt;/p&gt;

&lt;p&gt;as correctly written in the description.&lt;/p&gt;

&lt;p&gt;When c == 0.0 this leads to the special case&lt;/p&gt;

&lt;p&gt;( a + bi )  /  di  = ( b / d ) - ( a / d ) i&lt;/p&gt;

&lt;p&gt;But the corresponding code is:&lt;/p&gt;

&lt;p&gt;if (c == 0.0) {
    return createComplex(imaginary/d, -real/c);
}&lt;/p&gt;

&lt;p&gt;The bug is the last division -real/c, which should obviously be -real/d.&lt;/p&gt;</description>
                <environment>&lt;p&gt;all&lt;/p&gt;</environment>
            <key id="12438998">MATH-306</key>
            <summary>Method &apos;divide&apos; in class &apos;Complex&apos; uses a false formula for a special case resulting in erroneous division by zero.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bowman2001">Joerg Huber</reporter>
                        <labels>
                    </labels>
                <created>Sat, 24 Oct 2009 14:23:13 +0000</created>
                <updated>Wed, 14 Apr 2010 00:05:17 +0000</updated>
                    <resolved>Tue, 27 Oct 2009 01:33:42 +0000</resolved>
                            <version>1.1</version>
                <version>1.2</version>
                <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12769657" author="bowman2001" created="Sat, 24 Oct 2009 14:31:19 +0000"  >&lt;p&gt;Other layout and an additional formula conversion for better readability&lt;/p&gt;</comment>
                    <comment id="12769670" author="psteitz" created="Sat, 24 Oct 2009 15:39:35 +0000"  >&lt;p&gt;Thanks for reviewing the code.&lt;/p&gt;

&lt;p&gt;The code is misleading, but should not lead to incorrect results.  The line you refer to above is actually in a block that will never get executed - so should be deleted.&lt;/p&gt;
 &lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.abs(c) &amp;lt; &lt;span class=&quot;code-object&quot;&gt;Math&lt;/span&gt;.abs(d)) {
            &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (d == 0.0) {  &amp;lt;---- impossible to have abs(c) &amp;lt; 0
                &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; createComplex(real/c, imaginary/c);
            }
            &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; q = c / d;
            &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; denominator = c * q + d;
            &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; createComplex((real * q + imaginary) / denominator,
                (imaginary * q - real) / denominator);
        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
            &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (c == 0.0) {  &amp;lt;-- to get here, we need c = d = 0,  but &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; is handled above.
                &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; createComplex(imaginary/d, -real/c);  &amp;lt;-- incorrect fmla is harmless because never executed.
            }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;Interesting that static analyzers did not catch this as dead code.  Unless I am missing something, both of the if(* == 0) tests in the block above can be removed (with no effect on results).&lt;/p&gt;

&lt;p&gt;Appreciate comments on this, but leaning toward code cleanup and closing as invalid.&lt;/p&gt;</comment>
                    <comment id="12769675" author="bowman2001" created="Sat, 24 Oct 2009 16:15:18 +0000"  >&lt;p&gt;Yes, it looks like a twofold check for an already solved problem. By splitting the code up for the two cases&lt;br/&gt;
1. Math.abs(c) &amp;lt; Math.abs(d) &lt;br/&gt;
2. the other way around&lt;br/&gt;
the denominator of q is always non-zero, which would habe been a problem and may have been the reason to apply those extra checks.&lt;/p&gt;

&lt;p&gt;The special cases c = 0 and d = 0 lead always to q = 0, in the respective code parts. &lt;br/&gt;
Which is no problem, because there is no division by q. &lt;br/&gt;
Effective code, if the extra checks are omitted.&lt;/p&gt;

&lt;p&gt;Thank you Phil, I encourage the code cleanup you proposed.&lt;/p&gt;</comment>
                    <comment id="12769679" author="psteitz" created="Sat, 24 Oct 2009 17:10:21 +0000"  >&lt;p&gt;Thanks, and thanks again for reviewing the code.   We really appreciate that.&lt;/p&gt;</comment>
                    <comment id="12770352" author="psteitz" created="Tue, 27 Oct 2009 01:33:42 +0000"  >&lt;p&gt;Removed dead code in r830044.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 24 Oct 2009 15:39:35 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-305] NPE in  KMeansPlusPlusClusterer unittest</title>
                <link>https://issues.apache.org/jira/browse/MATH-305</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When running this unittest, I am facing this NPE:&lt;br/&gt;
java.lang.NullPointerException&lt;br/&gt;
	at org.apache.commons.math.stat.clustering.KMeansPlusPlusClusterer.assignPointsToClusters(KMeansPlusPlusClusterer.java:91)&lt;/p&gt;

&lt;p&gt;This is the unittest:&lt;/p&gt;


&lt;p&gt;package org.fao.fisheries.chronicles.calcuation.cluster;&lt;/p&gt;

&lt;p&gt;import static org.junit.Assert.assertEquals;&lt;br/&gt;
import static org.junit.Assert.assertTrue;&lt;/p&gt;

&lt;p&gt;import java.util.Arrays;&lt;br/&gt;
import java.util.List;&lt;br/&gt;
import java.util.Random;&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.stat.clustering.Cluster;&lt;br/&gt;
import org.apache.commons.math.stat.clustering.EuclideanIntegerPoint;&lt;br/&gt;
import org.apache.commons.math.stat.clustering.KMeansPlusPlusClusterer;&lt;br/&gt;
import org.fao.fisheries.chronicles.input.CsvImportProcess;&lt;br/&gt;
import org.fao.fisheries.chronicles.input.Top200Csv;&lt;br/&gt;
import org.junit.Test;&lt;/p&gt;

&lt;p&gt;public class ClusterAnalysisTest {&lt;/p&gt;


&lt;p&gt;	@Test&lt;br/&gt;
	public void testPerformClusterAnalysis2() {&lt;br/&gt;
		KMeansPlusPlusClusterer&amp;lt;EuclideanIntegerPoint&amp;gt; transformer = new KMeansPlusPlusClusterer&amp;lt;EuclideanIntegerPoint&amp;gt;(&lt;br/&gt;
				new Random(1746432956321l));&lt;br/&gt;
		EuclideanIntegerPoint[] points = new EuclideanIntegerPoint[] {&lt;br/&gt;
				new EuclideanIntegerPoint(new int[] { 1959, 325100 }),&lt;br/&gt;
				new EuclideanIntegerPoint(new int[] { 1960, 373200 }), };&lt;br/&gt;
		List&amp;lt;Cluster&amp;lt;EuclideanIntegerPoint&amp;gt;&amp;gt; clusters = transformer.cluster(Arrays.asList(points), 1, 1);&lt;br/&gt;
		assertEquals(1, clusters.size());&lt;/p&gt;

&lt;p&gt;	}&lt;/p&gt;

&lt;p&gt;}&lt;/p&gt;</description>
                <environment>&lt;p&gt;java 6, eclipse, apache commons math trunk&lt;/p&gt;</environment>
            <key id="12438781">MATH-305</key>
            <summary>NPE in  KMeansPlusPlusClusterer unittest</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="erikvaningen">Erik van Ingen</reporter>
                        <labels>
                    </labels>
                <created>Thu, 22 Oct 2009 06:35:08 +0000</created>
                <updated>Mon, 30 Nov 2009 08:12:50 +0000</updated>
                    <resolved>Fri, 27 Nov 2009 21:46:44 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                          <timeoriginalestimate seconds="14400">4h</timeoriginalestimate>
                    <timeestimate seconds="14400">4h</timeestimate>
                                  <comments>
                    <comment id="12783133" author="psteitz" created="Fri, 27 Nov 2009 16:57:43 +0000"  >&lt;p&gt;Thanks for reporting this. &lt;/p&gt;</comment>
                    <comment id="12783176" author="psteitz" created="Fri, 27 Nov 2009 21:46:44 +0000"  >&lt;p&gt;The problem was due to overflow in MathUtils.distance() due to bad typing.  Fixed in r885027.&lt;/p&gt;</comment>
                    <comment id="12783565" author="erikvaningen" created="Mon, 30 Nov 2009 08:12:50 +0000"  >&lt;p&gt;I have tested the fix and I can confirm that it is working in my environment. Thanks a lot!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 27 Nov 2009 16:57:43 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-302] Bugs in Simplex Implementation</title>
                <link>https://issues.apache.org/jira/browse/MATH-302</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Simplex routine may return infeasible solution:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;Bug1.java&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; java.util.ArrayList;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.linear.ArrayRealVector;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.GoalType;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.OptimizationException;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.linear.*;

&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; class Bug1 {
    
    &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt; void main(&lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;[] args) &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; OptimizationException {
        
        LinearObjectiveFunction c = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearObjectiveFunction(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[7], 0.0d);
        
        ArrayList&amp;lt;LinearConstraint&amp;gt; cnsts = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayList&amp;lt;LinearConstraint&amp;gt;(5);
        LinearConstraint cnst;
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {1.00d, 1.00d, 0.00d, 0.00d, 0.0d, 0.00d, 0.00d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 1.00d, 1.00d, 1.0d, 0.00d, 0.00d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 0.00d, 0.00d, 0.0d, 1.00d, 1.00d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.54d, 0.00d, 0.34d, 0.00d, 0.0d, 0.12d, 0.00d}, Relationship.EQ, 0.54d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.54d, 0.00d, 0.34d, 0.0d, 0.00d, 0.12d}, Relationship.EQ, 0.34d);
        cnsts.add(cnst);
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;Constraints:&quot;&lt;/span&gt;);
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;(LinearConstraint con : cnsts) {
            &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(con.getCoefficients().toString() + &lt;span class=&quot;code-quote&quot;&gt;&quot; &quot;&lt;/span&gt; + con.getRelationship() + &lt;span class=&quot;code-quote&quot;&gt;&quot; &quot;&lt;/span&gt; + con.getValue());
        }
        
        SimplexSolver simplex = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; SimplexSolver();
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] sol = simplex.optimize(c, cnsts, GoalType.MINIMIZE, &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;).getPointRef();
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;Solution:\n&quot;&lt;/span&gt; + &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(sol));
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;Third constraint is violated!&quot;&lt;/span&gt;);
    }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;or may find no solution where some exist:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;Bug1.java&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; java.util.ArrayList;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.linear.ArrayRealVector;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.GoalType;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.OptimizationException;
&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.optimization.linear.*;

&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; class Bug2 {
    
    &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt; void main(&lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;[] args) &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; OptimizationException {
        
        LinearObjectiveFunction c = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearObjectiveFunction(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[13], 0.0d);
        
        ArrayList&amp;lt;LinearConstraint&amp;gt; cnsts = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayList&amp;lt;LinearConstraint&amp;gt;(5);
        LinearConstraint cnst;
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {1.00d, 1.00d, 1.0d, 0.00d, 0.00d, 0.00d, 0.0d, 0.0d, 0.0d, 0.0d, 0.00d, 0.00d, 0.0d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 0.0d, 1.00d, 1.00d, 1.00d, 1.0d, 0.0d, 0.0d, 0.0d, 0.00d, 0.00d, 0.0d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 0.0d, 0.00d, 0.00d, 0.00d, 0.0d, 1.0d, 1.0d, 1.0d, 0.00d, 0.00d, 0.0d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 0.0d, 0.00d, 0.00d, 0.00d, 0.0d, 0.0d, 0.0d, 0.0d, 1.00d, 1.00d, 1.0d}, Relationship.EQ, 1.0d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.54d, 0.00d, 0.0d, 0.32d, 0.00d, 0.00d, 0.0d, 0.1d, 0.0d, 0.0d, 0.02d, 0.00d, 0.0d}, Relationship.EQ, 0.54d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.54d, 0.0d, 0.00d, 0.32d, 0.00d, 0.0d, 0.0d, 0.1d, 0.0d, 0.00d, 0.02d, 0.0d}, Relationship.EQ, 0.32d);
        cnsts.add(cnst);
        cnst = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {0.00d, 0.00d, 0.0d, 0.00d, 0.00d, 0.32d, 0.0d, 0.0d, 0.0d, 0.0d, 0.00d, 0.00d, 0.0d}, Relationship.EQ, 0.1d);
        cnsts.add(cnst);
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;Constraints:&quot;&lt;/span&gt;);
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;(LinearConstraint con : cnsts) {
            &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(con.getCoefficients().toString() + &lt;span class=&quot;code-quote&quot;&gt;&quot; &quot;&lt;/span&gt; + con.getRelationship() + &lt;span class=&quot;code-quote&quot;&gt;&quot; &quot;&lt;/span&gt; + con.getValue());
        }
        
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;verifying a known solution:&quot;&lt;/span&gt;);
        ArrayRealVector sol = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] {4.0d/9.0d, 5.0d/9.0d, 0.0d, 11.0d/16.0d, 0.0d, 5.0d/16.0d, 0.0d, 4.0d/5.0d, 0.0d, 1.0d/5.0d, 0.0d, 1.0d, 0.0d});
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;sol = &quot;&lt;/span&gt; + sol);
        &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;(LinearConstraint con : cnsts) {
            &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(sol.dotProduct(con.getCoefficients()) + &lt;span class=&quot;code-quote&quot;&gt;&quot; = &quot;&lt;/span&gt; + con.getValue());
        }
        
        SimplexSolver simplex = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; SimplexSolver();
        &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] newsol = simplex.optimize(c, cnsts, GoalType.MINIMIZE, &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;).getPointRef();
        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;Solution:\n&quot;&lt;/span&gt; + &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayRealVector(newsol));
    }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12438085">MATH-302</key>
            <summary>Bugs in Simplex Implementation</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="cwinter">Christian Winter</reporter>
                        <labels>
                    </labels>
                <created>Wed, 14 Oct 2009 13:58:15 +0000</created>
                <updated>Wed, 14 Apr 2010 00:09:59 +0000</updated>
                    <resolved>Thu, 15 Oct 2009 08:56:56 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12765730" author="bmccann" created="Wed, 14 Oct 2009 20:16:39 +0000"  >&lt;p&gt;These are likely bugs that have already been fixed in the Subversion repository.  Can you try again with the latest version compiled from SVN?&lt;/p&gt;

&lt;p&gt;I&apos;ve verified that the first problem gives valid output with the SVN version:&lt;br/&gt;
Constraints:&lt;br/&gt;
{1; 1; 0; 0; 0; 0; 0} = 1.0&lt;br/&gt;
{0; 0; 1; 1; 1; 0; 0} = 1.0&lt;br/&gt;
{0; 0; 0; 0; 0; 1; 1} = 1.0&lt;br/&gt;
{0.54; 0; 0.34; 0; 0; 0.12; 0} = 0.54&lt;br/&gt;
{0; 0.54; 0; 0.34; 0; 0; 0.12} = 0.34&lt;br/&gt;
Solution:&lt;/p&gt;
{0.37; 0.63; 0.65; 0; 0.35; 1; 0}


&lt;p&gt;I haven&apos;t completely checked the second one, but it appears to be correct as well with the SVN version:&lt;br/&gt;
Constraints:&lt;br/&gt;
{1; 1; 1; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0} = 1.0&lt;br/&gt;
{0; 0; 0; 1; 1; 1; 1; 0; 0; 0; 0; 0; 0} = 1.0&lt;br/&gt;
{0; 0; 0; 0; 0; 0; 0; 1; 1; 1; 0; 0; 0} = 1.0&lt;br/&gt;
{0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 1; 1; 1} = 1.0&lt;br/&gt;
{0.54; 0; 0; 0.32; 0; 0; 0; 0.1; 0; 0; 0.02; 0; 0} = 0.54&lt;br/&gt;
{0; 0.54; 0; 0; 0.32; 0; 0; 0; 0.1; 0; 0; 0.02; 0} = 0.32&lt;br/&gt;
{0; 0; 0; 0; 0; 0.32; 0; 0; 0; 0; 0; 0; 0} = 0.1&lt;br/&gt;
Solution:&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;0.3703703703703704, 0.5925925925925926, 0.037037037037037035, 0.6875, 0.0, 0.3125, 0.0, 0.9999999999999999, 0.0, 0.0, 1.0, 0.0, 0.0&amp;#93;&lt;/span&gt;&lt;/p&gt;</comment>
                    <comment id="12765952" author="cwinter" created="Thu, 15 Oct 2009 07:41:46 +0000"  >&lt;p&gt;Alright. It works with the version from SVN.&lt;br/&gt;
Thanks.&lt;/p&gt;</comment>
                    <comment id="12765979" author="luc" created="Thu, 15 Oct 2009 08:56:56 +0000"  >&lt;p&gt;Already fixed in subversion repository by previous changes.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 14 Oct 2009 20:16:39 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-301] Erf(z) should return 1.0 for z &apos;large&apos; but  fails with a MaxIterationsExceededException for z &gt; 26.0.</title>
                <link>https://issues.apache.org/jira/browse/MATH-301</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Erf(z) should return 1.0 for z &apos;large&apos; but fails with a MaxIterationsExceededException for z &amp;gt; 26.0.&lt;/p&gt;

&lt;p&gt;Sample code&lt;br/&gt;
-----------------&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.MathException;&lt;br/&gt;
import org.apache.commons.math.special.Erf;&lt;/p&gt;

&lt;p&gt;public class TestErf {&lt;/p&gt;

&lt;p&gt;    public TestErf() {&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;    public static void main(String[] args) {&lt;br/&gt;
        double z = Double.NEGATIVE_INFINITY;&lt;br/&gt;
        try {&lt;br/&gt;
            for(int i=0; i&amp;lt;100; i++) {
                z = i;
                System.out.println(&quot;z = &quot; + z + &quot;  erf(z) = &quot; + Erf.erf(z));
            }&lt;/p&gt;

&lt;p&gt;            System.out.flush();&lt;br/&gt;
        } catch (MathException mex) {
            System.out.println(&quot;z failed = &quot; + z);
            mex.printStackTrace();
        }&lt;br/&gt;
    }&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;Output&lt;br/&gt;
---------&lt;/p&gt;

&lt;p&gt;z = 0.0  erf(z) = 0.0&lt;br/&gt;
z = 1.0  erf(z) = 0.842700792949715&lt;br/&gt;
z = 2.0  erf(z) = 0.9953222650189528&lt;br/&gt;
z = 3.0  erf(z) = 0.9999779095030024&lt;br/&gt;
z = 4.0  erf(z) = 0.9999999845827416&lt;br/&gt;
z = 5.0  erf(z) = 0.9999999999984622&lt;br/&gt;
z = 6.0  erf(z) = 0.9999999999999997&lt;br/&gt;
z = 7.0  erf(z) = 1.000000000000001&lt;br/&gt;
z = 8.0  erf(z) = 0.9999999999999986&lt;br/&gt;
z = 9.0  erf(z) = 1.000000000000003&lt;br/&gt;
z = 10.0  erf(z) = 1.0000000000000115&lt;br/&gt;
z = 11.0  erf(z) = 1.0000000000000016&lt;br/&gt;
z = 12.0  erf(z) = 0.9999999999999941&lt;br/&gt;
z = 13.0  erf(z) = 0.9999999999999846&lt;br/&gt;
z = 14.0  erf(z) = 1.0000000000000024&lt;br/&gt;
z = 15.0  erf(z) = 0.9999999999999805&lt;br/&gt;
z = 16.0  erf(z) = 0.9999999999999988&lt;br/&gt;
z = 17.0  erf(z) = 0.9999999999999949&lt;br/&gt;
z = 18.0  erf(z) = 0.9999999999999907&lt;br/&gt;
z = 19.0  erf(z) = 0.9999999999999731&lt;br/&gt;
z = 20.0  erf(z) = 0.9999999999999862&lt;br/&gt;
z = 21.0  erf(z) = 0.9999999999999721&lt;br/&gt;
z = 22.0  erf(z) = 1.000000000000017&lt;br/&gt;
z = 23.0  erf(z) = 1.0000000000000577&lt;br/&gt;
z = 24.0  erf(z) = 1.000000000000054&lt;br/&gt;
z = 25.0  erf(z) = 1.0000000000000262&lt;br/&gt;
z = 26.0  erf(z) = 1.0000000000000735&lt;br/&gt;
z failed = 27.0&lt;br/&gt;
org.apache.commons.math.MaxIterationsExceededException: Maximal number of iterations (10,000) exceeded&lt;br/&gt;
        at org.apache.commons.math.special.Gamma.regularizedGammaP(Gamma.java:181)&lt;br/&gt;
        at org.apache.commons.math.special.Erf.erf(Erf.java:51)&lt;br/&gt;
        at org.fhcrc.math.minimization.TestErf.main(TestErf.java:23)&lt;/p&gt;</description>
                <environment>&lt;p&gt;MacOS and Linux&lt;/p&gt;</environment>
            <key id="12437655">MATH-301</key>
            <summary>Erf(z) should return 1.0 for z &apos;large&apos; but  fails with a MaxIterationsExceededException for z &gt; 26.0.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="milac">Tom Milac</reporter>
                        <labels>
                    </labels>
                <created>Thu, 8 Oct 2009 22:47:19 +0000</created>
                <updated>Thu, 9 Dec 2010 11:48:11 +0000</updated>
                    <resolved>Mon, 8 Mar 2010 22:59:28 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12771637" author="njawalkar" created="Thu, 29 Oct 2009 21:39:58 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Here&apos;s a patch that uses a different algorithm to calculate erf&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;. It&apos;s adapted from &quot;Handbook of Mathematical Functions: with Formulas, Graphs, and Mathematical Tables, by Milton Abramowitz and Irene A. Stegun&quot;.&lt;/p&gt;

&lt;p&gt;It no longer throws a MathException if x is too large or small. I&apos;ve added one test to check erf&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; for 20&amp;lt;=x&amp;lt;40, and all previous tests pass also.&lt;/p&gt;</comment>
                    <comment id="12833917" author="psteitz" created="Mon, 15 Feb 2010 18:41:32 +0000"  >&lt;p&gt;This issue and &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-282&quot; title=&quot;ChiSquaredDistributionImpl.cumulativeProbability &amp;gt; 1&quot;&gt;&lt;del&gt;MATH-282&lt;/del&gt;&lt;/a&gt; are both caused by problems handling extreme values in Gamma.&lt;/p&gt;</comment>
                    <comment id="12836187" author="psteitz" created="Sat, 20 Feb 2010 15:14:57 +0000"  >&lt;p&gt;From commons-user, another example of inaccurate results for extreme erf values:&lt;/p&gt;

&lt;p&gt;NormalDistribution normDist = new NormalDistributionImpl(40,1.5)&lt;br/&gt;
;&lt;br/&gt;
try{
System.out.println(&quot;cummulative probability::
&quot;+normDist.cumulativeProbability(0.908789));
}&lt;br/&gt;
catch(MathException e){
e.printStackTrace();
}&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Result:&lt;/b&gt;&lt;br/&gt;
cummulative probability:: &lt;b&gt;-8.104628079763643E-15&lt;/b&gt;&lt;/p&gt;</comment>
                    <comment id="12842837" author="psteitz" created="Mon, 8 Mar 2010 22:59:28 +0000"  >&lt;p&gt;Fixed in r920558.&lt;/p&gt;</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="10030">
                <name>Reference</name>
                                <outwardlinks description="relates to">
                            <issuelink>
            <issuekey id="12432549">MATH-282</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="12492820">MATH-456</issuekey>
        </issuelink>
                    </outwardlinks>
                                            </issuelinktype>
                    </issuelinks>
                <attachments>
                    <attachment id="12423626" name="erf.txt" size="3943" author="njawalkar" created="Thu, 29 Oct 2009 21:40:42 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 29 Oct 2009 21:39:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-299] SimplexSolver returns no feasible solution</title>
                <link>https://issues.apache.org/jira/browse/MATH-299</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I am trying to optimize this:&lt;/p&gt;

&lt;p&gt;maximize: v&lt;/p&gt;

&lt;p&gt;v &amp;lt;= a1*p1 + a2*p2 + a3*p3 + a4*p4&lt;br/&gt;
v &amp;lt;= b1*p1 + b2*p2 + b3*p3 + b4*p4&lt;br/&gt;
v &amp;lt;= c1*p1 + c2*p2 + c3*p3 + c4*p4&lt;br/&gt;
v &amp;lt;= d1*p1 + d2*p2 + d3*p3 + d4*p4&lt;/p&gt;

&lt;p&gt;p1 + p2 + p3 + p4 = 1&lt;/p&gt;

&lt;p&gt;where a1-d4 are constant specified below by the code (i didn&apos;t want to copy and paste them up here. you can look below to see what they are in the objective function). &lt;/p&gt;

&lt;p&gt;		LinearObjectiveFunction f = new LinearObjectiveFunction(		&lt;br/&gt;
				new double[] { 1,
						0, 
						0, 0, 0}, 0 );&lt;br/&gt;
		Collection&amp;lt;LinearConstraint&amp;gt;  constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt; ();&lt;/p&gt;


&lt;p&gt;		constraints.add(new LinearConstraint(new double[] { -1, 
				1.7316145027890766, 
				 1.3584341412980305,
				 0.9305633063383639,
				 1.687117394945513
		},&lt;br/&gt;
		Relationship.GEQ, 0));&lt;/p&gt;

&lt;p&gt;		constraints.add(new LinearConstraint(new double[] { -1, 
				0.6617060079461883, 
				 1.4862459822191323,
				 0.7692647272328988,
				 0.7329140944025636
		},&lt;br/&gt;
		Relationship.GEQ, 0));&lt;/p&gt;

&lt;p&gt;		constraints.add(new LinearConstraint(new double[] { -1, 
				1.3255966888982322, 
				286.21607948837584,
				1.135907611434458,
				0.9803367440299271
		},&lt;br/&gt;
		Relationship.GEQ, 0));&lt;/p&gt;

&lt;p&gt;		constraints.add(new LinearConstraint(new double[] { -1, 
				0.5428682596573682, 
				1.5745685116536952,
				1.4834419186882808,
				1.2884923232048968
		},&lt;br/&gt;
		Relationship.GEQ, 0));&lt;/p&gt;


&lt;p&gt;		constraints.add(new LinearConstraint(new double[] {0, 1, 1, 1, 1},&lt;br/&gt;
				Relationship.EQ, 1));&lt;br/&gt;
		RealPointValuePair solution = null;&lt;br/&gt;
		try {
		
			solution = new SimplexSolver().optimize(f, constraints,
					GoalType.MAXIMIZE, true);
		}&lt;br/&gt;
		catch (OptimizationException e) {
			e.printStackTrace();
		}&lt;/p&gt;

&lt;p&gt;I get this error back from the SimplexSolver.&lt;/p&gt;

&lt;p&gt;org.apache.commons.math.optimization.linear.NoFeasibleSolutionException: no feasible solution&lt;br/&gt;
	at org.apache.commons.math.optimization.linear.SimplexSolver.solvePhase1(SimplexSolver.java:177)&lt;br/&gt;
	at org.apache.commons.math.optimization.linear.SimplexSolver.doOptimize(SimplexSolver.java:187)&lt;br/&gt;
	at org.apache.commons.math.optimization.linear.AbstractLinearOptimizer.optimize(AbstractLinearOptimizer.java:106)&lt;br/&gt;
	at Runner.main(Runner.java:101)&lt;/p&gt;

&lt;p&gt;One interesting thing to note is that if you round all the numbers to the nearest 100&apos;s place, it works. If you keep it with the floating point precision shown here, it doesn&apos;t.&lt;/p&gt;
</description>
                <environment>&lt;p&gt;Windows XP commons Math 2.0 jre 1.6.0.16&lt;/p&gt;</environment>
            <key id="12436311">MATH-299</key>
            <summary>SimplexSolver returns no feasible solution</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="davidwilcox">David</reporter>
                        <labels>
                    </labels>
                <created>Tue, 22 Sep 2009 14:43:32 +0000</created>
                <updated>Wed, 14 Apr 2010 00:11:57 +0000</updated>
                    <resolved>Thu, 24 Sep 2009 22:36:26 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                          <timeoriginalestimate seconds="28800">8h</timeoriginalestimate>
                    <timeestimate seconds="28800">8h</timeestimate>
                                  <comments>
                    <comment id="12758353" author="luc" created="Tue, 22 Sep 2009 18:43:43 +0000"  >&lt;p&gt;I have tried to solve your problem with lp_solve to check whether it find a solution. Here is what I have set up using lp_solve lp format:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;math-299.lp&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;max: v;

-v + 1.7316145027890766 p1 +   1.3584341412980305 p2 + 0.9305633063383639 p3 + 1.687117394945513  p4 &amp;gt;= 0;
-v + 0.6617060079461883 p1 +   1.4862459822191323 p2 + 0.7692647272328988 p3 + 0.7329140944025636 p4 &amp;gt;= 0;
-v + 1.3255966888982322 p1 + 286.21607948837584   p2 + 1.135907611434458  p3 + 0.9803367440299271 p4 &amp;gt;= 0;
-v + 0.5428682596573682 p1 +   1.5745685116536952 p2 + 1.4834419186882808 p3 + 1.2884923232048968 p4 &amp;gt;= 0;

p1 + p2 + p3 + p4 = 1;

free p1, p2, p3, p4;

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Running lp_solve on this file returns the following error message:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;%  lp_solve &amp;lt; math-299.lp
This problem is unbounded
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Could you check the constants and check if the problem really has a feasible finite solution ?&lt;/p&gt;</comment>
                    <comment id="12758444" author="bmccann" created="Tue, 22 Sep 2009 21:21:14 +0000"  >&lt;p&gt;We might be better than lp_solve on this one!  This worked fine for me and gave me the same answer as Lindo (1.398257)&lt;br/&gt;
David, did you use Commons Math 2.0?  The seemed to work fine for me when I used Commons Math compiled from the Subversion repository.  I&apos;d recommend using the Subversion version because we&apos;ve fixed numerous bugs that were present in the 2.0 release.&lt;/p&gt;

&lt;p&gt;    @Test&lt;br/&gt;
    public void testMath299() throws OptimizationException {&lt;br/&gt;
        LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1, 0, 0, 0, 0}, 0 );&lt;br/&gt;
        Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt; ();&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { -1, 1.7316145027890766, 1.3584341412980305, 0.9305633063383639, 1.687117394945513 }, Relationship.GEQ, 0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { -1, 0.6617060079461883, 1.4862459822191323, 0.7692647272328988, 0.7329140944025636 }, Relationship.GEQ, 0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { -1, 1.3255966888982322, 286.21607948837584, 1.135907611434458, 0.9803367440299271 }, Relationship.GEQ, 0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { -1, 0.5428682596573682, 1.5745685116536952, 1.4834419186882808, 1.2884923232048968 }, Relationship.GEQ, 0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] {0, 1, 1, 1, 1}, Relationship.EQ, 1));&lt;br/&gt;
        RealPointValuePair solution = new SimplexSolver().optimize(f, constraints, GoalType.MAXIMIZE, true);&lt;br/&gt;
        Assert.assertEquals(1.398257, solution.getValue(), .0001);&lt;br/&gt;
    }&lt;/p&gt;</comment>
                    <comment id="12759200" author="luc" created="Thu, 24 Sep 2009 18:15:53 +0000"  >&lt;p&gt;David, do you consider the version in the subversion repository fixes this bug ?&lt;br/&gt;
Can we change its state to resolved ?&lt;/p&gt;</comment>
                    <comment id="12759214" author="davidwilcox" created="Thu, 24 Sep 2009 19:01:21 +0000"  >&lt;p&gt;I changed to the subversion repository and it seems fixed.&lt;/p&gt;

</comment>
                    <comment id="12759292" author="luc" created="Thu, 24 Sep 2009 22:36:26 +0000"  >&lt;p&gt;already fixed in subversion by previous changes&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 22 Sep 2009 18:43:43 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-298] EmpiriicalDisributionImpl.getUpperBounds does not return upper bounds on data bins</title>
                <link>https://issues.apache.org/jira/browse/MATH-298</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Per the javadoc, the getUpperBounds method in the EmpiricalDistribution should return upper bounds for the bins used in computing the empirical distribution and the bin statistics.  What the method actually returns is the upper bounds of the subintervals of &lt;span class=&quot;error&quot;&gt;&amp;#91;0,1&amp;#93;&lt;/span&gt; used in generating data following the empirical distribution.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12436158">MATH-298</key>
            <summary>EmpiriicalDisributionImpl.getUpperBounds does not return upper bounds on data bins</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="psteitz">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 20 Sep 2009 14:46:42 +0000</created>
                <updated>Wed, 14 Apr 2010 00:12:54 +0000</updated>
                    <resolved>Mon, 21 Sep 2009 01:32:21 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                <version>1.2</version>
                <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12757779" author="psteitz" created="Mon, 21 Sep 2009 01:32:21 +0000"  >&lt;p&gt;Fixed in r817128.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-297] Eigenvector computation incorrectly returning vectors of NaNs</title>
                <link>https://issues.apache.org/jira/browse/MATH-297</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;As reported by Axel Kramer on commons-dev, the following test case succeeds, but should fail:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; void testEigenDecomposition() {
    &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[][] m = { { 0.0, 1.0, -1.0 }, { 1.0, 1.0, 0.0 }, { -1.0,0.0, 1.0 } };
    RealMatrix rm = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Array2DRowRealMatrix(m);
    assertEquals(rm.toString(),
        &lt;span class=&quot;code-quote&quot;&gt;&quot;Array2DRowRealMatrix{{0.0,1.0,-1.0},{1.0,1.0,0.0},{-1.0,0.0,1.0}}&quot;&lt;/span&gt;);
    EigenDecompositionImpl ed = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; EigenDecompositionImpl(rm,
        MathUtils.SAFE_MIN);
    RealVector rv0 = ed.getEigenvector(0);
    assertEquals(rv0.toString(), &lt;span class=&quot;code-quote&quot;&gt;&quot;{(NaN); (NaN); (NaN)}&quot;&lt;/span&gt;);
  }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;ed.getRealEigenvalues() returns the correct eigenvalues (2, 1, -1), but all three eigenvectors contain only NaNs.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12436157">MATH-297</key>
            <summary>Eigenvector computation incorrectly returning vectors of NaNs</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="psteitz">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 20 Sep 2009 14:33:07 +0000</created>
                <updated>Wed, 14 Apr 2010 00:16:55 +0000</updated>
                    <resolved>Mon, 25 Jan 2010 17:58:04 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                                                    <comments>
                    <comment id="12767159" author="billbarker" created="Sun, 18 Oct 2009 23:33:05 +0000"  >&lt;p&gt;This is now fixed as of R826550.  Unfortunately, I lack karma to resolve this issue, so will have to hope that somebody else will resolve it for me.&lt;/p&gt;</comment>
                    <comment id="12767433" author="axelclk" created="Mon, 19 Oct 2009 18:14:23 +0000"  >&lt;p&gt;If I&apos;m expanding my testcase to the snippet below, I&apos;m  now getting an eigenvector with all &quot;negative values&quot; at index 1.&lt;br/&gt;
I think this should be avoided. &lt;br/&gt;
See also the solution computed by Ted Dunning on the mailing list: &lt;br/&gt;
&lt;a href=&quot;http://www.mail-archive.com/dev@commons.apache.org/msg12038.html&quot;&gt;http://www.mail-archive.com/dev@commons.apache.org/msg12038.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;    double[][] m = { { 0.0, 1.0, -1.0 }, { 1.0, 1.0, 0.0 }, { -1.0, 0.0, 1.0 } };&lt;br/&gt;
    RealMatrix rm = new Array2DRowRealMatrix(m);&lt;br/&gt;
    assertEquals(rm.toString(),&lt;br/&gt;
        &quot;Array2DRowRealMatrix{{0.0,1.0,-1.0},{1.0,1.0,0.0},{-1.0,0.0,1.0}}&quot;);&lt;br/&gt;
    EigenDecompositionImpl ed = new EigenDecompositionImpl(rm,&lt;br/&gt;
        MathUtils.SAFE_MIN);&lt;br/&gt;
    RealVector rv0 = ed.getEigenvector(0);&lt;br/&gt;
    RealVector rv1 = ed.getEigenvector(1);&lt;br/&gt;
    RealVector rv2 = ed.getEigenvector(2);&lt;br/&gt;
    assertEquals(rv0.toString(), &quot;{0,58; 0,58; -0,58}&quot;);&lt;br/&gt;
    assertEquals(rv1.toString(), &quot;{-0; -0,71; -0,71}&quot;);&lt;br/&gt;
    assertEquals(rv2.toString(), &quot;{0,82; -0,41; 0,41}&quot;);&lt;/p&gt;</comment>
                    <comment id="12770367" author="bjohnson" created="Tue, 27 Oct 2009 03:14:56 +0000"  >&lt;p&gt;There still seems to be a problem with the decomposition of some matrices.  For example, the decomposition of the identity matrix &lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; {{1,0},{0,1}}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;br/&gt;
 yields the correct eigenvalues, but NaN for all the eigenvector elements.&lt;br/&gt;
Crucially, the &quot;isIncludedColumn&quot; in the EigenDecompositionImplTest.java file always returns true (at least on my system) when the calculated eigenvectors have NaN elements, so is useless as a test for this problem.&lt;/p&gt;

&lt;p&gt;Also, I discovered this problem when getting NaN values doing an SVD of certain matrices (where each row has only one non-zero value).  Since the SVD algorithm uses the EigenDecompositionImpl code, this seems to be a result of this current  bug.  (And ironically, I just told my students that one reason people love the SVD is that it essentially never fails).&lt;/p&gt;




</comment>
                    <comment id="12770424" author="luc" created="Tue, 27 Oct 2009 08:43:22 +0000"  >&lt;p&gt;I will look at this issue one issu &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-308&quot; title=&quot;ArrayIndexOutOfBoundException in EigenDecompositionImpl&quot;&gt;&lt;del&gt;MATH-308&lt;/del&gt;&lt;/a&gt; has been solved.&lt;/p&gt;</comment>
                    <comment id="12770474" author="bjohnson" created="Tue, 27 Oct 2009 11:48:11 +0000"  >&lt;p&gt;Thanks.&lt;/p&gt;

&lt;p&gt;The problem seems to be a divide by zero error with the variable diP1 in the following code, but this is probably as far as I&apos;ll get in debugging it:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;   private void stationaryQuotientDifferenceWithShift(final double[] d, final double[] l,
                                                       final double lambda) {
        final int nM1 = d.length - 1;
        double si = -lambda;
        for (int i = 0, sixI = 0; i &amp;lt; nM1; ++i, sixI += 6) {
            final double di   = d[i];
            final double li   = l[i];
            final double diP1 = di + si;
            final double liP1 = li * di / diP1;
            work[sixI]        = si;
            work[sixI + 1]    = diP1;
            work[sixI + 2]    = liP1;
            si = li * liP1 * si - lambda;
        }
        work[6 * nM1 + 1] = d[nM1] + si;
        work[6 * nM1]     = si;
    }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="12770601" author="bjohnson" created="Tue, 27 Oct 2009 18:39:01 +0000"  >&lt;p&gt;..., and I note that what I presume to be the original Fortran code (in dlar1v.f of LAPACK) has several sections of code marked:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Runs a slower version of the above loop if a NaN is detected&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Hope this helps in resolving the issue,&lt;/p&gt;

&lt;p&gt;Bruce&lt;/p&gt;</comment>
                    <comment id="12772913" author="jake.mannix" created="Tue, 3 Nov 2009 07:23:23 +0000"  >&lt;p&gt;Doing the most trivial fix possible (dividing by the SAFE_MIN if diPl == 0)  on the line which leads to NaN appears to correctly fix this for the particular case of decomposing diagonal matrices (at least for 2x2 and 3x3 cases I checked with a unit test). &lt;/p&gt;

&lt;p&gt;I&apos;m not sure if this &quot;fixes&quot; the problem, because I&apos;m not sure if I really grok the algorithm&apos;s implementation in this code.&lt;/p&gt;

&lt;p&gt;We could see better if I knew how often this pops up (any matrix whose tri-diagonal form is actually diagonal?)...&lt;/p&gt;</comment>
                    <comment id="12772924" author="jake.mannix" created="Tue, 3 Nov 2009 07:42:24 +0000"  >&lt;p&gt;Ok, well sadly it&apos;s easy to find an example which &lt;b&gt;isn&apos;t&lt;/b&gt; fixed by just removing that one divide-by-zero: &lt;br/&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;{ {0, 1, 0}, {1, 0, 0}, {0, 0, 1} }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; leads to perfectly reasonable eigenvalues (1, 1, -1), but NaN again rears its ugly head because findEigenVectors() assumes that, among other things, that the main diagonal does not start with a zero, and then divides by it.&lt;/p&gt;

&lt;p&gt;Not sure what the proper solution is to this, but a non-shifted LDL^t decomposition is a lot easier to understand to me than the other place where the NaN pops up, so maybe I can figure this one out on the plane ride down to ApacheCon tomorrow.&lt;/p&gt;</comment>
                    <comment id="12783480" author="luc" created="Sun, 29 Nov 2009 21:27:31 +0000"  >&lt;p&gt;Another step towards the solution has been checked in as of r885268.&lt;br/&gt;
Just as Bruce noticed one month ago (thanks), there was an improvement in dstqds and dqds algorithms implemented in DLAR1V that are not in Dhillon&apos;s thesis.&lt;br/&gt;
The problem is still not completely solved as for example in dimension 3 the decomposition of identity leads to 3 times the same&lt;br/&gt;
vector (0, 0, 1) instead of giving (1, 0, 0), (0, 1, 0) and (0, 0, 1).&lt;/p&gt;</comment>
                    <comment id="12804619" author="luc" created="Mon, 25 Jan 2010 17:58:04 +0000"  >&lt;p&gt;The original issue as been solved 2009-11-29 as of r885268.&lt;br/&gt;
The remaining problem identified in the last comments has been moved in a separate JIRA issue: &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-333&quot; title=&quot;eigenvectors computation is wrong when several vectors share the same eigenvalue&quot;&gt;&lt;del&gt;MATH-333&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 18 Oct 2009 23:33:05 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-296] LoessInterpolator.smooth() not working correctly</title>
                <link>https://issues.apache.org/jira/browse/MATH-296</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I have been comparing LoessInterpolator.smooth output with the loessFit output from R (R-project.org, probably the most widely used loess implementation) and have had strangely different numbers. I have created a small set to test the difference and something seems to be wrong with the smooth method but I do no know what and I do not understand the code.&lt;br/&gt;
&lt;b&gt;Example 1&lt;/b&gt;&lt;/p&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;x-input: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 3.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 8&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 12&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;13&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 22&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 24&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;28&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;31&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;y-input: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.4&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.2&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;Output LoessInterpolator.smooth():&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;Output from loessFit() from R: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.191178027520974&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.0407201231474037&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.7089538903778636&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.7450823274490297&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;4.388011000549519&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;4.60078952381848&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.2988217587114805&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.867536388457898&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.7797794777879705&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.444888598397342&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;&lt;b&gt;Example 2 (same x-values, y-values just floored)&lt;/b&gt;&lt;/p&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;x-input: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 3.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 8&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 12&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;13&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 22&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 24&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;28&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;31&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;y-input: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;Output LoessInterpolator.smooth(): &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.9999999999999005&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.0000000000001705&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.999999999999972&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.999999999999967&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;Output from loessFit() from R: &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.091423927353068&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.9411521572524237&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.60967950675505&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.7421759322272248&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;4.382996912300442&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;4.646774316632562&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.225153658563424&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;5.768301917477015&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.637079139313073&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.270482144410326&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;As you see the output is practically the replicated y-input.&lt;br/&gt;
At this point this funtionality is critical for us but I could not find any other suitable java-implementation. Help. Maybe this strange behaviour gives someone a clue?&lt;/p&gt;
</description>
                <environment>&lt;p&gt;Java 1.6 on Vista&lt;/p&gt;</environment>
            <key id="12435875">MATH-296</key>
            <summary>LoessInterpolator.smooth() not working correctly</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="romeop">Romeo P</reporter>
                        <labels>
                    </labels>
                <created>Wed, 16 Sep 2009 21:14:20 +0000</created>
                <updated>Wed, 14 Apr 2010 00:18:11 +0000</updated>
                    <resolved>Tue, 26 Jan 2010 21:54:45 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                                                    <comments>
                    <comment id="12757189" author="luc" created="Fri, 18 Sep 2009 14:52:52 +0000"  >&lt;p&gt;What are your settings for bandwidth and robustness iterations ?&lt;br/&gt;
I have tried your examples and the first one doesn&apos;t lead to NaN with the default settings for me.&lt;/p&gt;</comment>
                    <comment id="12757216" author="romeop" created="Fri, 18 Sep 2009 15:54:31 +0000"  >&lt;p&gt;My settings are 0.3 and 4 (these are used as defaults in R). &lt;br/&gt;
If I use the standard values I still get:&lt;/p&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.100000000000003&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;6.099999999999999&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.0999999999999996&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;NaN&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;7.85&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;Here is my test code for a quick look:&lt;/p&gt;

&lt;p&gt;public void testLoessInterpolator() throws MathException{&lt;br/&gt;
		dataX = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;10&amp;#93;&lt;/span&gt;;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; = 1.5;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; = 3.0;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; = 6;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; = 8;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; = 12;		&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; = 13;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; = 22;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;7&amp;#93;&lt;/span&gt; = 24;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt; = 28;&lt;br/&gt;
		dataX&lt;span class=&quot;error&quot;&gt;&amp;#91;9&amp;#93;&lt;/span&gt; = 31;&lt;/p&gt;


&lt;p&gt;		dataY = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;10&amp;#93;&lt;/span&gt;;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; = 3.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; = 6.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; = 3.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; = 2.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; = 1.4;		&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; = 5.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; = 5.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;7&amp;#93;&lt;/span&gt; = 6.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt; = 7.1;&lt;br/&gt;
		dataY&lt;span class=&quot;error&quot;&gt;&amp;#91;9&amp;#93;&lt;/span&gt; = 7.2;&lt;/p&gt;

&lt;p&gt;		LoessInterpolator li = new LoessInterpolator();&lt;br/&gt;
		double[] ly = li.smooth(dataX, dataY);&lt;/p&gt;

&lt;p&gt;		for (int i = 0; i &amp;lt; ly.length; i++) {
			System.out.println(ly[i]);
		}		&lt;br/&gt;
	}&lt;/p&gt;

&lt;p&gt;Is there any obvious error which I do not see? Is it possible (although highely unlikely) that some java floating point operations are broken on Vista64 (which I am using)?&lt;br/&gt;
Can you show your results?&lt;/p&gt;</comment>
                    <comment id="12757338" author="luc" created="Fri, 18 Sep 2009 18:45:17 +0000"  >&lt;p&gt;OK. I reproduce exactly your results on a Linux computer with openJDK 1.6 on an AMD64 processor.&lt;br/&gt;
I&apos;ll have a look at this issue.&lt;/p&gt;</comment>
                    <comment id="12757396" author="luc" created="Fri, 18 Sep 2009 20:31:12 +0000"  >&lt;p&gt;The math-296-test.patch is a set of two test cases that reproduce the problem.&lt;/p&gt;

&lt;p&gt;Running the first test shows that at the end of iteration 0, the weights for points at indices 4 and 5 are set to 0. At iteration 1, when computing point i=4, the bandwidth is such that ileft=3 and iright=4. For k=3, we get w=0 because dist=4 and denom=1/4. For k=4 and k=5, we get w=0 because robustness&lt;span class=&quot;error&quot;&gt;&amp;#91;k&amp;#93;&lt;/span&gt;=0. So all w are 0, sumWeights=0 and since it is used in some divisions, NaN appears.&lt;/p&gt;

&lt;p&gt;I think their should be some protection against this case somewhere. I&apos;ll ask the author of the original contribution about this.&lt;/p&gt;</comment>
                    <comment id="12758165" author="jkff" created="Tue, 22 Sep 2009 07:49:22 +0000"  >&lt;p&gt;Thanks for reporting the problem, Romeo. Actually, I did not compare the results of my implementation with those of R&apos;s: I purely implemented the algorithm described in the paper, and checked that the results are sensible. Unfortunately I will most probably not have time to debug the issue until weekend, but I can provide explanations to you about the code in case the issue is so critical for you that you urge to fix it yourself &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12759203" author="romeop" created="Thu, 24 Sep 2009 18:22:55 +0000"  >&lt;p&gt;Eugene, that is great news. I already tried to fix it but did not get very far. &lt;br/&gt;
First of all, please ignore the sample values that are supposed to be from loessFit in the example above, they are not. I have reviewed my code and I can not reproduce those values. Sorry for that. When I try the examples again I get hardly any changes except for the NaN values (perhaps due to the fact that the values are not very close together?). The testcases should be deleted/changed to reflect this  I have compiled a more appropriate testcase:&lt;/p&gt;

&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;xval&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.2&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.4&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.7&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.8&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.9&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.1&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.2&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.3&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.4&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.5&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.6&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.7&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.8&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.9&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;yval&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.47&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.48&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.55&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.56&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.08&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.04&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.07&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.07&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.56&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.46&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.56&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.52&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.03&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.08&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.09&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.04&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.54&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.46&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.36&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.35&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;result&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.46076343001050907&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.49997135715509317&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.5429801876574236&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.3191000440696382&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.17824135321363765&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.03999999999999973&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.0699999999999999&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.21301261447145203&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.3260295715150817&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.45999999999999996&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.560000000000002&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-1.4961752602921834&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-2.1317826106042093&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.0799999999999965&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.089999999999987&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.6229499113916326&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.9970283360414918&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.450011252797152&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.3907474604481567&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.336774229999947&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;loessFit&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.4609008580907899&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.4985267031275769&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.5408291873645029&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.308077939113221&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.1754074466314782&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.0419929152622151&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.07205683451999362&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.19661654144034335&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.31073415047540565&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.44615854234427305&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.5567051673879394&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-1.4972970376332615&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-2.1330233520442317&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.08&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.0900000000000043&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.6208045742447532&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.9823842010251099&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.449395357814414&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.389793487936696&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.3359749840089385&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;weight(see below)&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;loessFit with weights&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.4780117093745368&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.4924876444111407&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.48398021996388496&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.3201446090891406&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.17880078999161195&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.003305611690841502&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.08829472923805592&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.20902549447499932&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.3267558674057103&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.45542226638134214&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.518369970805548&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-0.5365908808969353&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-1.492628917733731&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-2.1151751796193703&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.09&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-3.0400000000000005&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-2.9899999999999998&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;0.15500000000000005&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;1.7524999999999986&lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;3.3499999999999996&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;


&lt;p&gt;The results do not differ very much and there are no NaN, if the values are close together. Can this be explained by a slightly different algorithm in R?&lt;/p&gt;

&lt;p&gt;For easy copy and paste:&lt;br/&gt;
double[] yval={0.47, 0.48, 0.55, 0.56,-0.08,-0.04,-0.07,-0.07,-0.56,-0.46,-0.56,-0.52,-3.03,-3.08,-3.09,-3.04, 3.54, 3.46, 3.36, 3.35};&lt;br/&gt;
double[] xval={0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2.0};&lt;br/&gt;
double[] weights = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1};&lt;br/&gt;
LoessInterpolator li = new LoessInterpolator(0.3,4);&lt;br/&gt;
result = li.smooth(xval, yval);&lt;/p&gt;


&lt;p&gt;Another related thing. A very common use of the R-function is with weights (that is how we use it as well): &lt;br/&gt;
&lt;b&gt;loessFit(yValues, xValues, weights)&lt;/b&gt;&lt;br/&gt;
where weights are the values 0 or 1, I dont know if some are using weights between 0 and 1 &lt;br/&gt;
If a spot has weight 0 it still gets loessfitted but does not affect his neighbours. This way you can specifiy more relevant points and have the complete data set interpolate around these.&lt;/p&gt;

&lt;p&gt;In your implementation you use robustnessWeights and set them initially to 1. Do I understand this correctly that these are actually the same weights as the ones mentioned above?&lt;br/&gt;
Would it be possible to add a function with a third parameter and have the weights provided by the user? I tried just passing them trough as a parameter instead of initializing with 1 but it did not do the trick.&lt;/p&gt;</comment>
                    <comment id="12759623" author="jkff" created="Fri, 25 Sep 2009 16:56:11 +0000"  >&lt;p&gt;Romeo,&lt;br/&gt;
Here is a patch that implements the weighted loess fit (the results agree reasonably with R&apos;s implementation).&lt;br/&gt;
Also, the patch fixes some numeric instability by introducing an &apos;accuracy&apos; parameter.&lt;/p&gt;

&lt;p&gt;Luc,&lt;br/&gt;
Could you please review the patch and probably apply it?&lt;/p&gt;</comment>
                    <comment id="12759682" author="luc" created="Fri, 25 Sep 2009 18:35:08 +0000"  >&lt;p&gt;solved in subversion repository as of r818942.&lt;br/&gt;
patch applied with slight changes&lt;br/&gt;
thanks for the report and thanks for the patch&lt;/p&gt;</comment>
                    <comment id="12760030" author="romeop" created="Sun, 27 Sep 2009 14:12:39 +0000"  >&lt;p&gt;Eugene, Luc, thanks. Great news. I have been testing this with some bigger real-life datasets (~800 points) and the results seem to be very close to R).&lt;br/&gt;
There is one more problem though but I think I have already found the fix. You can still get NaN-results. &lt;br/&gt;
The reason is that sumWeights can become 0 and there are a couple of divisions with sumWeights. This multiplies to the degree that the complete result set is an array of NaN.&lt;br/&gt;
I think (but am not sure) that this happens if you have a long series of 0-weights which is bigger then the amount of points you get through the bandwidth.&lt;/p&gt;

&lt;p&gt;I have just added the following lines after these sumWeights divisions:&lt;br/&gt;
after: &lt;b&gt;double meanXSquared = sumXSquared / sumWeights;&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;                if(sumWeights==0){
                	meanX=0;
                	meanY=0;
                	meanXY=0;
                	meanXSquared=0;
                }&lt;br/&gt;
That did the trick for me and the results seem accurate. I will test more during the next week with even more datasets. I hope I do not make any fundamental thinking error.&lt;/p&gt;

&lt;p&gt;If you think this is correct please add it to the code.&lt;/p&gt;</comment>
                    <comment id="12760921" author="jkff" created="Wed, 30 Sep 2009 14:25:04 +0000"  >&lt;p&gt;Romeo, I am not sure about whether this behavior should be considered correct. &lt;br/&gt;
It essentially means that there is no data inside an approximation window at all, so why should we make the data appear to be zero? &lt;br/&gt;
How about a variant &quot;express the approximation window in terms of the number of points with non-zero weights&quot;?&lt;/p&gt;</comment>
                    <comment id="12761022" author="romeop" created="Wed, 30 Sep 2009 22:13:24 +0000"  >&lt;p&gt;Sorry, maybe I was a little unclear in my explanation. &lt;br/&gt;
Actually there is data, there are just no weights in the approximation window. Lets say we have 300 point and the first 100 are weighted 0, the others are weighted 1, they are still valid data points. Being weighted 0 does not mean the data point can be deleted, it just means it does not affect his neighbours in terms of normalization (that is how the concept of normalization weights was explained to me)&lt;br/&gt;
What happens currently is the first ones become NaN and their neighbours become NaN to the point that &lt;b&gt;all&lt;/b&gt; points become NaN. This shouldn&apos;t happen.&lt;br/&gt;
But do not misunderstand me, I am just assuming that the reason is because of the bandwidth as my dataset has this structure, I am not really sure about it. &lt;br/&gt;
I have done some debugging on the code but there are really a lot of loops so I could not pinpoint when and why exactly this is starting to happen as it is not right from the beginning.&lt;/p&gt;</comment>
                    <comment id="12761237" author="jkff" created="Thu, 1 Oct 2009 15:00:27 +0000"  >&lt;p&gt;Romeo, have I understood you correctly that you&apos;d like the data points with zero weights to not influence the approximation &lt;b&gt;coefficients&lt;/b&gt; at all, but to still have computed approximation &lt;b&gt;values&lt;/b&gt; for them?&lt;/p&gt;</comment>
                    <comment id="12763126" author="romeop" created="Wed, 7 Oct 2009 16:58:56 +0000"  >&lt;p&gt;Yes. I think that is correct. No influence on the approximation coefficients but still getting normalized (getting approximation values). &lt;/p&gt;

&lt;p&gt;Here is an except from the userguide for the R-limma package, which uses the loessFit function for some operations:&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;Any spot quality weights found in RG will be used in the normalization by default. This means for example that spots with zero weight (flagged out) will not influence the normalization of other spots. The use of spot quality weights will not however result in any spots being removed from the data object. Even spots with zero weight will be normalized and will appear in the output object, such spots will simply not have any influence on the other spots.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;However I am not sure how to handle the bandwidth. Example: if you have a bandwidth of 0.3, how do you compute the relevant points?&lt;br/&gt;
1. Find the 30% in the complete set and the use only the weighted ones inside this set&lt;br/&gt;
2. Look at all weighted ones and use 30% of them&lt;/p&gt;

&lt;p&gt;To me the first one sounds like the logical one but I am not sure.&lt;/p&gt;</comment>
                    <comment id="12767886" author="jkff" created="Tue, 20 Oct 2009 17:45:19 +0000"  >&lt;p&gt;Sorry for the delay again: I just forgot about the issue. Don&apos;t hesitate to ping me, I am not a very organized person.&lt;/p&gt;

&lt;p&gt;Adding zero-weighted points &lt;b&gt;must not&lt;/b&gt; change the result in non-zero-weighted points and the approximation coefficients.&lt;br/&gt;
Thus, zero-weighted points must not participate in computing the bandwidth, and generally in computing anything at all: that is the &lt;b&gt;second&lt;/b&gt; approach.&lt;/p&gt;

&lt;p&gt;However, seems like R takes the &lt;b&gt;first&lt;/b&gt; one, because I&apos;ve implemented the second one and results disagreed with R on the testcase above.&lt;/p&gt;

&lt;p&gt;Are you OK with having a more logical implementation that disagrees with R? &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12793869" author="psteitz" created="Wed, 23 Dec 2009 01:19:41 +0000"  >&lt;p&gt;Eugene&apos;s reasoning sounds correct to me.  I am inclined to say we document carefully and resolve this issue.  Any objections?&lt;/p&gt;</comment>
                    <comment id="12794171" author="luc" created="Wed, 23 Dec 2009 19:21:29 +0000"  >&lt;p&gt;I agree, but would like to know what R produces when a large (read larger than bandwidth) chunk of zero weights occurs.&lt;/p&gt;</comment>
                    <comment id="12804620" author="luc" created="Mon, 25 Jan 2010 18:07:44 +0000"  >&lt;p&gt;Coming back to this issue.&lt;br/&gt;
Eugene, as you said you implemented the second approach and people agree with your reasoning,&lt;br/&gt;
could you provide a patch using this second approach so we can apply it ?&lt;/p&gt;</comment>
                    <comment id="12805039" author="jkff" created="Tue, 26 Jan 2010 14:27:21 +0000"  >&lt;p&gt;Here is the patch.&lt;/p&gt;</comment>
                    <comment id="12805227" author="luc" created="Tue, 26 Jan 2010 21:54:45 +0000"  >&lt;p&gt;second patch applied as of r903440&lt;br/&gt;
thanks for the patch&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12431424" name="MATH-296.2.patch" size="7096" author="jkff" created="Tue, 26 Jan 2010 14:27:21 +0000" />
                    <attachment id="12420070" name="math-296-test.patch" size="2192" author="luc" created="Fri, 18 Sep 2009 20:31:12 +0000" />
                    <attachment id="12420572" name="math-296.patch" size="12945" author="jkff" created="Fri, 25 Sep 2009 16:56:11 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 18 Sep 2009 14:52:52 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-294] RandomDataImpl.nextPoisson fails for means in range 6.0 - 19.99</title>
                <link>https://issues.apache.org/jira/browse/MATH-294</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;math.random.RandomDataImpl.nextPoisson(double mean) fails frequently (but not always) for values of mean between 6.0 and 19.99 inclusive. For values below 6.0 (where I see there is a branch in the logic) and above 20.0 it seems to be okay (though I&apos;ve only randomly sampled the space and run a million trials for the values I&apos;ve tried)&lt;/p&gt;

&lt;p&gt;When it fails, the exception is as follows (this for a mean of 6.0)&lt;/p&gt;

&lt;p&gt;org.apache.commons.math.MathRuntimeException$4: must have n &amp;gt;= 0 for n!, got n = -2&lt;br/&gt;
	at org.apache.commons.math.MathRuntimeException.createIllegalArgumentException(MathRuntimeException.java:282)&lt;br/&gt;
	at org.apache.commons.math.util.MathUtils.factorialLog(MathUtils.java:561)&lt;br/&gt;
	at org.apache.commons.math.random.RandomDataImpl.nextPoisson(RandomDataImpl.java:434) &lt;/p&gt;

&lt;p&gt;ie MathUtils.factorialLog is being called with a negative input&lt;/p&gt;

&lt;p&gt;To reproduce:&lt;/p&gt;

&lt;p&gt;    JDKRandomGenerator random = new JDKRandomGenerator();&lt;br/&gt;
    random.setSeed(123456);&lt;br/&gt;
    RandomData randomData = new RandomDataImpl(random);&lt;/p&gt;

&lt;p&gt;    for (int i=0; i&amp;lt; 1000000; i++){
        randomData.nextPoisson(6.0);
    }&lt;/p&gt;</description>
                <environment>&lt;p&gt;Java 1.6 on mac osX&lt;/p&gt;</environment>
            <key id="12435449">MATH-294</key>
            <summary>RandomDataImpl.nextPoisson fails for means in range 6.0 - 19.99</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mcfall">Jason McFall</reporter>
                        <labels>
                    </labels>
                <created>Fri, 11 Sep 2009 17:34:29 +0000</created>
                <updated>Wed, 14 Apr 2010 00:20:03 +0000</updated>
                    <resolved>Mon, 12 Oct 2009 02:08:12 +0000</resolved>
                            <version>1.2</version>
                <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12754704" author="luc" created="Sun, 13 Sep 2009 14:45:08 +0000"  >&lt;p&gt;The failure seems to be related with a wrong detection of out of bound cases.&lt;br/&gt;
In the example given the failure occurs at iteration 125 on my computer (Open JDK 1.6, Linux, 64bits). At the beginning of the loop, the u = nextUniform(0.0, c) random drawing leads to a value u smaller than c1. So the first branch of the if is taken and another random drawing is done : z = nextGaussian(0.0, 1.0) which leads to a value for x far below mu (x = -8, mu = 2).&lt;/p&gt;

&lt;p&gt;This is detected as w is set to positive infinity, but in fact this is not sufficient. The &quot;accept&quot; boolean is still computed despite it will always be false.&lt;/p&gt;

&lt;p&gt;The attached patch is an attempt to compute &quot;accept&quot; only in some cases and to force it to &quot;false&quot; in other cases without computation.&lt;/p&gt;

&lt;p&gt;I did &lt;b&gt;not&lt;/b&gt; check this in subversion because I would like some other people to have a look at it. I am not sure it does work properly because when I compute for example the mean of 200, 100000, 1000000 or 10000000 calls to nextPoisson(6.0), I always get values between 14.7 and 15.2. I have seen the variance of a Poisson distribution is the same as its mean and so could expect a large value, but this still looked strange to me.&lt;/p&gt;</comment>
                    <comment id="12755314" author="psteitz" created="Tue, 15 Sep 2009 02:30:11 +0000"  >&lt;p&gt;Lets hold on the patch for now.  We need to understand why the rejection algorithm is failing.  Based on a quick review of the reference in the javadoc (p. 511, X.3), it looks like the following line in the u &amp;lt; c_1 case should not be subtracting 1.0 at the end.&lt;/p&gt;

&lt;p&gt;y = -Math.abs(z) * Math.sqrt(mu) - 1.0;&lt;/p&gt;

&lt;p&gt;I have not tested the effect dropping the -1 here as I am still working through the algorithm.&lt;/p&gt;</comment>
                    <comment id="12760210" author="psteitz" created="Mon, 28 Sep 2009 10:45:17 +0000"  >&lt;p&gt;In r819492, I committed a goodness of fit test (testNextPoissionConistency) for the values generated by nextPoisson.  Currently, it tests only values up to 5.  When this issue is resolved, the upper bound in the test needs to be increased.&lt;/p&gt;

&lt;p&gt;I have not been able to rectify the current code so that it succeeds for all values and passes the test.  The implementation does not match the reference in the javadoc and the reference appears to contain errors.  If someone does not beat me to it or supply a patch that passes the test, I will find and implement a different version of the rejection algorithm for means &amp;gt; 6.&lt;/p&gt;</comment>
                    <comment id="12764528" author="psteitz" created="Mon, 12 Oct 2009 02:08:12 +0000"  >&lt;p&gt;Fixed in r824214&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12419421" name="math-294.patch" size="2530" author="luc" created="Sun, 13 Sep 2009 14:45:08 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 13 Sep 2009 14:45:08 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-293] Matrix&apos;s &quot;OutOfBoundException&quot; in SimplexSolver</title>
                <link>https://issues.apache.org/jira/browse/MATH-293</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Hi all,&lt;br/&gt;
This bug is somehow related to incident &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt;, but not necessarily...&lt;/p&gt;

&lt;p&gt;Let&apos;s say I have an LP and I solve it using SimplexSolver. Then I create a second LP similar to the first one, but with &quot;stronger&quot; constraints. The second LP has the following properties:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;the only point in the feasible region for the second LP is the solution returned for the first LP&lt;/li&gt;
	&lt;li&gt;the solution returned for the first LP is also the (only possible) solution to the second LP&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This shows the problem:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-style: solid;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;LinearObjectiveFunction f = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearObjectiveFunction(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.8, 0.2, 0.7, 0.3, 0.4, 0.6}, 0 );
Collection&amp;lt;LinearConstraint&amp;gt; constraints = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayList&amp;lt;LinearConstraint&amp;gt;();
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 1, 0, 1, 0, 1, 0 }, Relationship.EQ, 30.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0, 1, 0, 1, 0, 1 }, Relationship.EQ, 30.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.8, 0.2, 0.0, 0.0, 0.0, 0.0 }, Relationship.GEQ, 10.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.0, 0.0, 0.7, 0.3, 0.0, 0.0 }, Relationship.GEQ, 10.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.0, 0.0, 0.0, 0.0, 0.4, 0.6 }, Relationship.GEQ, 10.0));

RealPointValuePair solution = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; SimplexSolver().optimize(f, constraints, GoalType.MAXIMIZE, &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;);

&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; valA = 0.8 * solution.getPoint()[0] + 0.2 * solution.getPoint()[1];
&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; valB = 0.7 * solution.getPoint()[2] + 0.3 * solution.getPoint()[3];
&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; valC = 0.4 * solution.getPoint()[4] + 0.6 * solution.getPoint()[5];

f = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearObjectiveFunction(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.8, 0.2, 0.7, 0.3, 0.4, 0.6}, 0 );
constraints = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArrayList&amp;lt;LinearConstraint&amp;gt;();
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 1, 0, 1, 0, 1, 0 }, Relationship.EQ, 30.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0, 1, 0, 1, 0, 1 }, Relationship.EQ, 30.0));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.8, 0.2, 0.0, 0.0, 0.0, 0.0 }, Relationship.GEQ, valA));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.0, 0.0, 0.7, 0.3, 0.0, 0.0 }, Relationship.GEQ, valB));
constraints.add(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LinearConstraint(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;[] { 0.0, 0.0, 0.0, 0.0, 0.4, 0.6 }, Relationship.GEQ, valC));

solution = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; SimplexSolver().optimize(f, constraints, GoalType.MAXIMIZE, &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;);&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;Instead of returning the solution, SimplexSolver throws an Exception:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; Exception in thread &quot;main&quot; org.apache.commons.math.linear.MatrixIndexException: no entry at indices (0, 7) in a 6x7 matrix
	at org.apache.commons.math.linear.Array2DRowRealMatrix.getEntry(Array2DRowRealMatrix.java:356)
	at org.apache.commons.math.optimization.linear.SimplexTableau.getEntry(SimplexTableau.java:408)
	at org.apache.commons.math.optimization.linear.SimplexTableau.getBasicRow(SimplexTableau.java:258)
	at org.apache.commons.math.optimization.linear.SimplexTableau.getSolution(SimplexTableau.java:336)
	at org.apache.commons.math.optimization.linear.SimplexSolver.doOptimize(SimplexSolver.java:182)
	at org.apache.commons.math.optimization.linear.AbstractLinearOptimizer.optimize(AbstractLinearOptimizer.java:106)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;I was too optimistic with the bug &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt; &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;java 1.6 on Windows XP 32-Bit&lt;/p&gt;</environment>
            <key id="12435216">MATH-293</key>
            <summary>Matrix&apos;s &quot;OutOfBoundException&quot; in SimplexSolver</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ciaccia">Andrea</reporter>
                        <labels>
                    </labels>
                <created>Wed, 9 Sep 2009 14:07:53 +0000</created>
                <updated>Wed, 14 Apr 2010 00:21:37 +0000</updated>
                    <resolved>Thu, 10 Sep 2009 08:23:11 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12753207" author="bmccann" created="Wed, 9 Sep 2009 18:39:26 +0000"  >&lt;p&gt;Here&apos;s the standard LP description of the problem:&lt;br/&gt;
max .8 x0 + .2 x1 + .7 x2 + .3 x3 + .4 x4 + .6 x5&lt;br/&gt;
s.t.&lt;br/&gt;
x0 + x2 + x4 = 30&lt;br/&gt;
x1 + x3 + x5 = 30&lt;br/&gt;
.8 x0 + .2 x1 &amp;gt;= 10&lt;br/&gt;
.7 x2 + .3 x3 &amp;gt;= 10&lt;br/&gt;
.4 x4 + .6 x5 &amp;gt;= 10&lt;/p&gt;</comment>
                    <comment id="12753213" author="ciaccia" created="Wed, 9 Sep 2009 19:00:50 +0000"  >&lt;p&gt;Hi Ben,&lt;br/&gt;
Just to be clear, the first LP is solved correctly with the following solution:&lt;/p&gt;

&lt;p&gt;Value: 40.57142857142857&lt;/p&gt;

&lt;p&gt;x0: 15.714285714285714&lt;br/&gt;
x1: 0.0&lt;br/&gt;
x2: 14.285714285714286&lt;br/&gt;
x3: 0.0&lt;br/&gt;
x4: 0.0&lt;br/&gt;
x5: 30.0&lt;/p&gt;

&lt;p&gt;Then I create new constraints that are satisfied by the solution here above:&lt;br/&gt;
c3: 0.8 * x0 + 0.2 * x1 &amp;gt;= 0.8 * 15.714285714285714 ( = 12.571428571428571)&lt;br/&gt;
c4: 0.7 * x2 + 0.3 * x3 &amp;gt;= 0.7 * 14.285714285714286 ( = 10.0)&lt;br/&gt;
c5: 0.4 * x4 + 0.6 * x5 &amp;gt;= 0.6 * 30.0 ( = 18.0)&lt;/p&gt;

&lt;p&gt;Note that by its construction, the solution above satisfies the constraints c3, c4, and c5.&lt;/p&gt;

&lt;p&gt;If I try to solve the new LP, a &quot;OutOfBoundException&quot; is thrown...&lt;/p&gt;</comment>
                    <comment id="12753475" author="bmccann" created="Thu, 10 Sep 2009 07:28:17 +0000"  >&lt;p&gt;Thanks for the bug report Andrea.  I was expecting this problem when I submitted the patch for &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt;, but didn&apos;t have a good test case to work against and verify the fix.  This is largely what I was thinking of when I mentioned we should test some more, but didn&apos;t think you&apos;d beat me to it in finding a good example to work off of :o)  When I changed the columns being dropped in the patch for &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt; it meant there wasn&apos;t always a way to always tell which variable each column of the tableau represented.  This patch creates a mapping between column index and variable label so that when we can read the final solution out of the tableau.  I feel much better about this now.  Thanks!&lt;/p&gt;</comment>
                    <comment id="12753500" author="luc" created="Thu, 10 Sep 2009 08:23:11 +0000"  >&lt;p&gt;patch applied in subversion repository as of r813301&lt;br/&gt;
thanks to Andrea and Ben&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12419148" name="SimplexSolverTest.patch" size="3388" author="bmccann" created="Thu, 10 Sep 2009 07:28:17 +0000" />
                    <attachment id="12419147" name="SimplexTableau.patch" size="4339" author="bmccann" created="Thu, 10 Sep 2009 07:28:17 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 9 Sep 2009 18:39:26 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-292] TestUtils.assertRelativelyEquals() generates misleading error on failure</title>
                <link>https://issues.apache.org/jira/browse/MATH-292</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;TestUtils.assertRelativelyEquals() generates misleading error on failure.&lt;/p&gt;

&lt;p&gt;For example:&lt;/p&gt;

&lt;p&gt;TestUtils.assertRelativelyEquals(1.0, 0.10427661385154971, 1.0e-9)&lt;/p&gt;

&lt;p&gt;generates the error message:&lt;/p&gt;

&lt;p&gt;junit.framework.AssertionFailedError: expected:&amp;lt;0.0&amp;gt; but was:&amp;lt;0.8957233861484503&amp;gt;&lt;/p&gt;

&lt;p&gt;which is not very helpful.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12434957">MATH-292</key>
            <summary>TestUtils.assertRelativelyEquals() generates misleading error on failure</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sun, 6 Sep 2009 22:04:34 +0000</created>
                <updated>Wed, 14 Apr 2010 00:25:38 +0000</updated>
                    <resolved>Wed, 9 Sep 2009 10:12:01 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12752132" author="sebb@apache.org" created="Mon, 7 Sep 2009 13:20:02 +0000"  >&lt;p&gt;Possible fix which converts the relative error to an absolute error.&lt;/p&gt;</comment>
                    <comment id="12752229" author="luc" created="Mon, 7 Sep 2009 18:03:07 +0000"  >&lt;p&gt;The patch seems good to me.&lt;br/&gt;
+1 to commit it&lt;/p&gt;</comment>
                    <comment id="12753012" author="sebb@apache.org" created="Wed, 9 Sep 2009 10:12:01 +0000"  >&lt;p&gt;URL: &lt;a href=&quot;http://svn.apache.org/viewvc?rev=812871&amp;amp;view=rev&quot;&gt;http://svn.apache.org/viewvc?rev=812871&amp;amp;view=rev&lt;/a&gt;&lt;br/&gt;
Log:&lt;br/&gt;
&lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-292&quot; title=&quot;TestUtils.assertRelativelyEquals() generates misleading error on failure&quot;&gt;&lt;del&gt;MATH-292&lt;/del&gt;&lt;/a&gt; TestUtils.assertRelativelyEquals() generates misleading error on failure&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12418802" name="MATH-292.patch" size="713" author="sebb@apache.org" created="Mon, 7 Sep 2009 13:20:02 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 7 Sep 2009 18:03:07 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-290] NullPointerException in SimplexTableau.initialize</title>
                <link>https://issues.apache.org/jira/browse/MATH-290</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;SimplexTableau throws a NullPointerException when no solution can be found instead of a NoFeasibleSolutionException&lt;/p&gt;

&lt;p&gt;Here is the code that causes the NullPointerException:&lt;/p&gt;

&lt;p&gt;LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1, 5 }, 0 );&lt;br/&gt;
Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 2, 0 }, Relationship.GEQ, -1.0));&lt;/p&gt;

&lt;p&gt;RealPointValuePair solution = new SimplexSolver().optimize(f, constraints, GoalType.MINIMIZE, true);&lt;/p&gt;

&lt;p&gt;Note: Tested both with Apache Commons Math 2.0 release and SVN trunk&lt;/p&gt;</description>
                <environment>&lt;p&gt;Java 1.6.0_13 on Windows XP 32-bit &lt;/p&gt;</environment>
            <key id="12433932">MATH-290</key>
            <summary>NullPointerException in SimplexTableau.initialize</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ciaccia">Andrea</reporter>
                        <labels>
                    </labels>
                <created>Tue, 25 Aug 2009 10:53:33 +0000</created>
                <updated>Wed, 14 Apr 2010 00:27:17 +0000</updated>
                    <resolved>Thu, 27 Aug 2009 08:08:17 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12747629" author="bmccann" created="Tue, 25 Aug 2009 20:43:17 +0000"  >&lt;p&gt;Thanks for the bug report.  I&apos;m glad to be finding these bugs (hopefully the last of them :o)  That was the point in open sourcing this, so looks like that was a good decision!&lt;br/&gt;
Problem here was that when the constraint&apos;s right hand side is negative, we need to flip the constraint around so that it is positive.  We were doing that too late during the initialization and it should have been done at the very beginning, so that we only deal with the normalized version instead of both versions.&lt;/p&gt;</comment>
                    <comment id="12747692" author="bmccann" created="Tue, 25 Aug 2009 22:28:29 +0000"  >&lt;p&gt;The original patch is sufficient, but I&apos;m attaching a new one that also cleans up some code formatting (weird spacing in SimplexTableau) and also provides a little bit better test.&lt;br/&gt;
Andrea, the correct solution for the example you provided is 0.  You restricted the variables to be non-negative and are trying to minimize the objective function, so the best you can do is make both variables 0 for an objective function value of 0.&lt;/p&gt;</comment>
                    <comment id="12747797" author="ciaccia" created="Wed, 26 Aug 2009 06:35:11 +0000"  >&lt;p&gt;Hi Ben, what you say in your last comment is not true. There is no feasible solution to my problem...&lt;br/&gt;
Maybe I should have expressed it in &quot;human&quot; readable format:&lt;/p&gt;

&lt;p&gt;min: 1 x + 5 y;&lt;br/&gt;
r1: 2 x + 0 y &amp;lt;= -1;&lt;br/&gt;
x &amp;gt;= 0;&lt;br/&gt;
y &amp;gt;= 0;&lt;/p&gt;

&lt;p&gt;x = 0 and y = 0 is not a valid solution since 2 * 0 + 0 * 0 (=0) is not &amp;lt;= -1...&lt;/p&gt;

&lt;p&gt;The &quot;trick&quot; is that there will be never non-negative variables (in this case &lt;span class=&quot;error&quot;&gt;&amp;#91;x, y&amp;#93;&lt;/span&gt;) that multiplied with non-negative coefficients (here &lt;span class=&quot;error&quot;&gt;&amp;#91;2, 0&amp;#93;&lt;/span&gt;) will produce a negative result.&lt;/p&gt;

&lt;p&gt;Do you agree?&lt;/p&gt;</comment>
                    <comment id="12747993" author="bmccann" created="Wed, 26 Aug 2009 15:49:31 +0000"  >&lt;p&gt;You originally wrote &amp;gt;= in the constraint and now you&apos;re writing &amp;lt;=.  Perhaps that&apos;s where the confusion is?  The answer is 0 when you use &amp;lt;=.&lt;/p&gt;</comment>
                    <comment id="12747996" author="ciaccia" created="Wed, 26 Aug 2009 15:56:42 +0000"  >&lt;p&gt;Ops... I found the bug with the &amp;lt;= but then I transcribed it wrongly... Sorry.&lt;/p&gt;

&lt;p&gt;Another thing I found that is not related to this bug, are the comments in the SimplexTableau. JavaDoc for divideRow was copied from substractRow without being changed &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12748296" author="luc" created="Thu, 27 Aug 2009 08:08:17 +0000"  >&lt;p&gt;fixed in subversion repository as of r808313&lt;br/&gt;
latest version of patch applied and two tests used (one with &amp;lt;= as the constraint and one with &amp;gt;= as the constraint)&lt;br/&gt;
thanks to Andrea for the report&lt;br/&gt;
thanks to Ben for the patch&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12417671" name="SimplexSolverTest.patch" size="4049" author="bmccann" created="Tue, 25 Aug 2009 22:28:29 +0000" />
                    <attachment id="12417670" name="SimplexTableau.patch" size="8240" author="bmccann" created="Tue, 25 Aug 2009 22:28:29 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 25 Aug 2009 20:43:17 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-288] SimplexSolver not working as expected 2</title>
                <link>https://issues.apache.org/jira/browse/MATH-288</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;SimplexSolver didn&apos;t find the optimal solution.&lt;/p&gt;

&lt;p&gt;Program for Lpsolve:&lt;br/&gt;
=====================&lt;br/&gt;
/* Objective function */&lt;br/&gt;
max: 7 a 3 b;&lt;/p&gt;

&lt;p&gt;/* Constraints */&lt;br/&gt;
R1: +3 a -5 c &amp;lt;= 0;&lt;br/&gt;
R2: +2 a -5 d &amp;lt;= 0;&lt;br/&gt;
R3: +2 b -5 c &amp;lt;= 0;&lt;br/&gt;
R4: +3 b -5 d &amp;lt;= 0;&lt;br/&gt;
R5: +3 a +2 b &amp;lt;= 5;&lt;br/&gt;
R6: +2 a +3 b &amp;lt;= 5;&lt;/p&gt;

&lt;p&gt;/* Variable bounds */&lt;br/&gt;
a &amp;lt;= 1;&lt;br/&gt;
b &amp;lt;= 1;&lt;br/&gt;
=====================&lt;br/&gt;
Results(correct): a = 1, b = 1, value = 10&lt;/p&gt;


&lt;p&gt;Program for SimplexSolve:&lt;br/&gt;
=====================&lt;br/&gt;
LinearObjectiveFunction kritFcia = new LinearObjectiveFunction(new double[]{7, 3, 0, 0}, 0);&lt;br/&gt;
Collection&amp;lt;LinearConstraint&amp;gt; podmienky = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{1, 0, 0, 0}, Relationship.LEQ, 1));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{0, 1, 0, 0}, Relationship.LEQ, 1));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{3, 0, -5, 0}, Relationship.LEQ, 0));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{2, 0, 0, -5}, Relationship.LEQ, 0));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{0, 2, -5, 0}, Relationship.LEQ, 0));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{0, 3, 0, -5}, Relationship.LEQ, 0));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{3, 2, 0, 0}, Relationship.LEQ, 5));&lt;br/&gt;
podmienky.add(new LinearConstraint(new double[]{2, 3, 0, 0}, Relationship.LEQ, 5));&lt;br/&gt;
SimplexSolver solver = new SimplexSolver();&lt;br/&gt;
RealPointValuePair result = solver.optimize(kritFcia, podmienky, GoalType.MAXIMIZE, true);&lt;br/&gt;
=====================&lt;br/&gt;
Results(incorrect): a = 1, b = 0.5, value = 8.5&lt;/p&gt;

&lt;p&gt;P.S. I used the latest software from the repository (including &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt; fix).&lt;/p&gt;</description>
                <environment>&lt;p&gt;Java 1.6.0_13 on Windows XP 32-bit &lt;/p&gt;</environment>
            <key id="12433883">MATH-288</key>
            <summary>SimplexSolver not working as expected 2</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="kefa">Stefan Radacovsky</reporter>
                        <labels>
                    </labels>
                <created>Mon, 24 Aug 2009 22:31:11 +0000</created>
                <updated>Wed, 14 Apr 2010 00:30:17 +0000</updated>
                    <resolved>Tue, 25 Aug 2009 18:10:08 +0000</resolved>
                            <version>2.1</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                          <timeoriginalestimate seconds="28800">8h</timeoriginalestimate>
                    <timeestimate seconds="28800">8h</timeestimate>
                                  <comments>
                    <comment id="12747167" author="bmccann" created="Tue, 25 Aug 2009 01:06:07 +0000"  >&lt;p&gt;Thanks for the bug report.  I&apos;ve confirmed this is an issue.&lt;/p&gt;

&lt;p&gt;Here&apos;s a slightly smaller version of the problem that causes the same bug, which might be easier for debugging:&lt;/p&gt;

&lt;p&gt;MAX 7 a + 3 b&lt;br/&gt;
s.t.&lt;br/&gt;
3 a -5 c &amp;lt;= 0&lt;br/&gt;
2 a -5 d &amp;lt;= 0&lt;br/&gt;
3 b -5 d &amp;lt;= 0&lt;br/&gt;
a &amp;lt;= 1&lt;br/&gt;
b &amp;lt;= 1&lt;/p&gt;

&lt;p&gt;        LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 7, 3, 0, 0 }, 0 );&lt;br/&gt;
        Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 3, 0, -5, 0 }, Relationship.LEQ, 0.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 2, 0, 0, -5 }, Relationship.LEQ, 0.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 0, 3, 0, -5 }, Relationship.LEQ, 0.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0 }, Relationship.LEQ, 1.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0 }, Relationship.LEQ, 1.0));&lt;/p&gt;

&lt;p&gt;        SimplexSolver solver = new SimplexSolver();&lt;br/&gt;
        RealPointValuePair solution = solver.optimize(f, constraints, GoalType.MAXIMIZE, true);&lt;br/&gt;
        assertEquals(10.0, solution.getValue(), .0000001);&lt;/p&gt;</comment>
                    <comment id="12747192" author="bmccann" created="Tue, 25 Aug 2009 02:17:05 +0000"  >&lt;p&gt;Patch attached.  It was a 1 character bug.  I was saying to only do the minimum ratio test if the entry is &amp;gt;= 0, but it should have been &amp;gt; 0 (dividing by 0 is never good :o)&lt;br/&gt;
Thanks again for the bug report.&lt;/p&gt;</comment>
                    <comment id="12747531" author="luc" created="Tue, 25 Aug 2009 18:10:08 +0000"  >&lt;p&gt;resolved in subversion repository as of r807738&lt;br/&gt;
patch applied (except for debug print function)&lt;br/&gt;
thanks for the repoart and thanks for the patch&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12417557" name="SimplexSolver.patch" size="822" author="bmccann" created="Tue, 25 Aug 2009 02:17:05 +0000" />
                    <attachment id="12417558" name="SimplexSolverTest.patch" size="3232" author="bmccann" created="Tue, 25 Aug 2009 02:17:05 +0000" />
                    <attachment id="12417559" name="SimplexTableau.patch" size="1877" author="bmccann" created="Tue, 25 Aug 2009 02:17:05 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 25 Aug 2009 01:06:07 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-286] SimplexSolver not working as expected?</title>
                <link>https://issues.apache.org/jira/browse/MATH-286</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I guess (but I could be wrong) that SimplexSolver does not always return the optimal solution, nor satisfies all the constraints...&lt;/p&gt;

&lt;p&gt;Consider this LP:&lt;/p&gt;

&lt;p&gt;max: 0.8 x0 + 0.2 x1 + 0.7 x2 + 0.3 x3 + 0.6 x4 + 0.4 x5;&lt;br/&gt;
r1: x0 + x2 + x4 = 23.0;&lt;br/&gt;
r2: x1 + x3 + x5 = 23.0;&lt;br/&gt;
r3: x0 &amp;gt;= 10.0;&lt;br/&gt;
r4: x2 &amp;gt;= 8.0;&lt;br/&gt;
r5: x4 &amp;gt;= 5.0;&lt;/p&gt;

&lt;p&gt;LPSolve returns 25.8, with x0 = 10.0, x1 = 0.0, x2 = 8.0, x3 = 0.0, x4 = 5.0, x5 = 23.0;&lt;/p&gt;

&lt;p&gt;The same LP expressed in Apache commons math is:&lt;/p&gt;

&lt;p&gt;LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 0.8, 0.2, 0.7, 0.3, 0.6, 0.4 }, 0 );&lt;br/&gt;
Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 1, 0, 1, 0, 1, 0 }, Relationship.EQ, 23.0));&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 1, 0, 1 }, Relationship.EQ, 23.0));&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0 }, Relationship.GEQ, 10.0));&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0 }, Relationship.GEQ, 8.0));&lt;br/&gt;
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0 }, Relationship.GEQ, 5.0));&lt;/p&gt;

&lt;p&gt;RealPointValuePair solution = new SimplexSolver().optimize(f, constraints, GoalType.MAXIMIZE, true);&lt;/p&gt;

&lt;p&gt;that returns 22.20, with x0 = 15.0, x1 = 23.0, x2 = 8.0, x3 = 0.0, x4 = 0.0, x5 = 0.0;&lt;/p&gt;

&lt;p&gt;Is it possible SimplexSolver is buggy that way? The returned value is 22.20 instead of 25.8, and the last constraint (x4 &amp;gt;= 5.0) is not satisfied...&lt;/p&gt;

&lt;p&gt;Am I using the interface wrongly?&lt;/p&gt;</description>
                <environment>&lt;p&gt;Java 1.6.0_13 on  Windows XP 32-bit&lt;/p&gt;</environment>
            <key id="12433578">MATH-286</key>
            <summary>SimplexSolver not working as expected?</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ciaccia">Andrea</reporter>
                        <labels>
                    </labels>
                <created>Thu, 20 Aug 2009 15:04:09 +0000</created>
                <updated>Wed, 14 Apr 2010 00:30:57 +0000</updated>
                    <resolved>Thu, 10 Sep 2009 08:22:11 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12746199" author="bmccann" created="Fri, 21 Aug 2009 20:25:41 +0000"  >&lt;p&gt;I have confirmed this is an issue.&lt;/p&gt;</comment>
                    <comment id="12746207" author="bmccann" created="Fri, 21 Aug 2009 20:38:24 +0000"  >&lt;p&gt;Here&apos;s a smaller version of the problem that also fails:&lt;/p&gt;

&lt;p&gt;max 0.8 x0 + 0.2 x1 + 0.7 x2 + 0.3 x3&lt;br/&gt;
s.t. &lt;br/&gt;
x0 + x2 = 23.0&lt;br/&gt;
x1 + x3 = 23.0&lt;/p&gt;

&lt;p&gt;    @Test&lt;br/&gt;
    public void testMath268() throws OptimizationException {&lt;br/&gt;
      LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 0.8, 0.2, 0.7, 0.3 }, 0 );&lt;br/&gt;
      Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
      constraints.add(new LinearConstraint(new double[] { 1, 0, 1, 0 }, Relationship.EQ, 23.0));&lt;br/&gt;
      constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 1 }, Relationship.EQ, 23.0));&lt;/p&gt;

&lt;p&gt;      SimplexSolver solver = new SimplexSolver();&lt;br/&gt;
      RealPointValuePair solution = solver.optimize(f, constraints, GoalType.MINIMIZE, true);&lt;br/&gt;
      assertEquals(25.3, solution.getValue(), .0000001);&lt;br/&gt;
    }&lt;/p&gt;
</comment>
                    <comment id="12746219" author="bmccann" created="Fri, 21 Aug 2009 20:50:06 +0000"  >&lt;p&gt;And a yet smaller version that is failing:&lt;/p&gt;

&lt;p&gt;max 0.2 x1 + 0.3 x3&lt;br/&gt;
s.t. &lt;br/&gt;
x1 + x3 = 23.0&lt;/p&gt;

&lt;p&gt;    @Test&lt;br/&gt;
    public void testMath268() throws OptimizationException {&lt;br/&gt;
      LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 0.2, 0.3 }, 0 );&lt;br/&gt;
      Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
      constraints.add(new LinearConstraint(new double[] { 1, 1 }, Relationship.EQ, 23.0));&lt;/p&gt;

&lt;p&gt;      SimplexSolver solver = new SimplexSolver();&lt;br/&gt;
      RealPointValuePair solution = solver.optimize(f, constraints, GoalType.MINIMIZE, true);&lt;br/&gt;
      assertEquals(6.9, solution.getValue(), .0000001);&lt;br/&gt;
    }&lt;/p&gt;</comment>
                    <comment id="12746223" author="ciaccia" created="Fri, 21 Aug 2009 21:06:31 +0000"  >&lt;p&gt;Hi Ben,&lt;br/&gt;
Your test here above is wrong, the GoalType should be MAXIMIZE and not MINIMIZE...&lt;br/&gt;
The MINIMIZE returns 4.6 which is the expected value.&lt;/p&gt;</comment>
                    <comment id="12746242" author="bmccann" created="Fri, 21 Aug 2009 21:32:00 +0000"  >&lt;p&gt;Whoops, right you are.  Thanks for catching that.&lt;br/&gt;
This should be a better example for debugging:&lt;/p&gt;

&lt;p&gt;max 0.2 x1 + 0.3 x3&lt;br/&gt;
s.t.&lt;br/&gt;
x1 + x3 = 23.0&lt;/p&gt;

&lt;p&gt;    @Test&lt;br/&gt;
    public void testMath268() throws OptimizationException {&lt;br/&gt;
      LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 0.2, 0.3 }, 0 );&lt;br/&gt;
      Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
      constraints.add(new LinearConstraint(new double[] { 1, 1 }, Relationship.EQ, 23.0));&lt;/p&gt;

&lt;p&gt;      RealPointValuePair solution = new SimplexSolver().optimize(f, constraints, GoalType.MAXIMIZE, true);&lt;br/&gt;
      assertEquals(6.9, solution.getValue(), .0000001);&lt;br/&gt;
    }&lt;/p&gt;
</comment>
                    <comment id="12746245" author="bmccann" created="Fri, 21 Aug 2009 21:38:32 +0000"  >&lt;p&gt;The solution is being calculated correctly, but the wrong thing is being returned.  The bug is in SimplexTableau.getSolution()&lt;/p&gt;</comment>
                    <comment id="12746285" author="bmccann" created="Fri, 21 Aug 2009 22:11:56 +0000"  >&lt;p&gt;Here&apos;s the fix.&lt;br/&gt;
Note that the test case I posted in the comment was named dyslexically.  It should be math286 not math268.&lt;/p&gt;</comment>
                    <comment id="12746350" author="luc" created="Fri, 21 Aug 2009 23:09:57 +0000"  >&lt;p&gt;Fixed in subversion repository as of r806753.&lt;br/&gt;
Patch applied.&lt;br/&gt;
Thanks to Andrea for the report and thanks to Ben for the fix&lt;/p&gt;</comment>
                    <comment id="12748826" author="ciaccia" created="Fri, 28 Aug 2009 14:12:43 +0000"  >&lt;p&gt;Hi all,&lt;br/&gt;
Maybe I&apos;m doing something wrong extracting the latest version from the SVN repository, but the original issue is still not working on my apache commons math working copy &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;Here is what I did:&lt;br/&gt;
-I extracted the latest version from the SVN repository&lt;br/&gt;
-I executed the original problematic LP for this bug and it still fails. Anyway, the simplified version (but maybe incompatible) succeeds...&lt;/p&gt;

&lt;p&gt;Could please anyone look at that?&lt;br/&gt;
Thanks&lt;br/&gt;
Andrea&lt;/p&gt;</comment>
                    <comment id="12749538" author="bmccann" created="Mon, 31 Aug 2009 16:41:43 +0000"  >&lt;p&gt;Yes, there is still an error with this example. The bug for the smaller example was fixed, but there&apos;s something still affecting the larger one. I haven&apos;t been able to figure it out yet, but here&apos;s another smaller example that is also failing:&lt;/p&gt;

&lt;p&gt;    @Test&lt;br/&gt;
    public void testMath286Reopened() throws OptimizationException {&lt;br/&gt;
        LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 0.8, 0.7 }, 0 );&lt;br/&gt;
        Collection&amp;lt;LinearConstraint&amp;gt; constraints = new ArrayList&amp;lt;LinearConstraint&amp;gt;();&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 1, 1 }, Relationship.LEQ, 18.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 1, 0 }, Relationship.GEQ, 10.0));&lt;br/&gt;
        constraints.add(new LinearConstraint(new double[] { 0, 1 }, Relationship.GEQ, 8.0));&lt;/p&gt;

&lt;p&gt;        SimplexSolver solver = new SimplexSolver();&lt;br/&gt;
        RealPointValuePair solution = solver.optimize(f, constraints, GoalType.MAXIMIZE, true);&lt;br/&gt;
        assertEquals(13.6, solution.getValue(), .0000001);&lt;br/&gt;
    } &lt;/p&gt;</comment>
                    <comment id="12749548" author="bmccann" created="Mon, 31 Aug 2009 17:24:04 +0000"  >&lt;p&gt;Here are the corresponding Simplex tableaus.  Let me know if you spot the error.&lt;/p&gt;</comment>
                    <comment id="12749580" author="ciaccia" created="Mon, 31 Aug 2009 19:11:24 +0000"  >&lt;p&gt;Hi all,&lt;br/&gt;
What I wrote before doesn&apos;t really make sense... &lt;/p&gt;

&lt;p&gt;Look at this LP simplex solver:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.phpsimplex.com/simplex/page2.php?objetivo=max&amp;amp;x1=0.8&amp;amp;x2=0.7&amp;amp;restricciones=3&amp;amp;variables=2&amp;amp;l=en&amp;amp;x11=1&amp;amp;x12=1&amp;amp;desigualdad1=-1&amp;amp;y1=18&amp;amp;x21=1&amp;amp;x22=0&amp;amp;desigualdad2=1&amp;amp;y2=10&amp;amp;x31=0&amp;amp;x32=1&amp;amp;desigualdad3=1&amp;amp;y3=8&amp;amp;Submit=Continue&quot;&gt;http://www.phpsimplex.com/simplex/page2.php?objetivo=max&amp;amp;x1=0.8&amp;amp;x2=0.7&amp;amp;restricciones=3&amp;amp;variables=2&amp;amp;l=en&amp;amp;x11=1&amp;amp;x12=1&amp;amp;desigualdad1=-1&amp;amp;y1=18&amp;amp;x21=1&amp;amp;x22=0&amp;amp;desigualdad2=1&amp;amp;y2=10&amp;amp;x31=0&amp;amp;x32=1&amp;amp;desigualdad3=1&amp;amp;y3=8&amp;amp;Submit=Continue&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;why after the first phase is over the coefficients for x1 and x2 are set to 0.8 and 0.7 while here they are 0? Couldn&apos;t be the SimplexTableau&apos;s discardArtificialVariables doesn&apos;t do everything correct?&lt;/p&gt;

&lt;p&gt;Just guessing...&lt;/p&gt;</comment>
                    <comment id="12749762" author="bmccann" created="Tue, 1 Sep 2009 05:09:24 +0000"  >&lt;p&gt;If I remember correctly phpsimplex formed the tableau a bit differently.  Instead of creating the tableau from the beginning with two objective functions, they only use one at the beginning, and then insert the phase 2 objective function later.  As a result, the tableaus aren&apos;t directly comparable.&lt;br/&gt;
I emailed Professor Chinneck at Carleton University for some help because I retaught myself a lot of this using a draft of a book he&apos;s working on.  He suggested looking into ways to deal with degenerate solutions, so I&apos;ll see if I can read up on that a bit:&lt;br/&gt;
&quot;You&apos;ve hit a degeneracy (which means that there are multiple solutions with the same value of objective function). The problem came when, in your second tableau, you pivoted on the third row (corresponding to s1) instead of the last row (corresponding to a2). Understandable since the minimum ratio test came out tied.&quot;&lt;/p&gt;</comment>
                    <comment id="12750120" author="bmccann" created="Tue, 1 Sep 2009 21:39:58 +0000"  >&lt;p&gt;phpsimplex said that when there&apos;s a tie, they make the artificial variable leave the basis, which we&apos;re not doing and would solve the problem in this case:&lt;br/&gt;
&lt;a href=&quot;http://www.phpsimplex.com/en/simplex_method_theory.htm#anomalous&quot;&gt;http://www.phpsimplex.com/en/simplex_method_theory.htm#anomalous&lt;/a&gt;&lt;br/&gt;
i&apos;ll try putting together a patch, likely this weekend, to do that&lt;/p&gt;</comment>
                    <comment id="12752288" author="bmccann" created="Tue, 8 Sep 2009 00:16:06 +0000"  >&lt;p&gt;Happy Labor Day!  To celebrate, here&apos;s a new set of patches that adds the ability to deal with degeneracy in the SimplexTableau.&lt;br/&gt;
The test includes four tests: the two bugs in &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-286&quot; title=&quot;SimplexSolver not working as expected?&quot;&gt;&lt;del&gt;MATH-286&lt;/del&gt;&lt;/a&gt;, the bug from &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-288&quot; title=&quot;SimplexSolver not working as expected 2&quot;&gt;&lt;del&gt;MATH-288&lt;/del&gt;&lt;/a&gt;, and the bug from &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-290&quot; title=&quot;NullPointerException in SimplexTableau.initialize&quot;&gt;&lt;del&gt;MATH-290&lt;/del&gt;&lt;/a&gt;.  I think they should all go in to prevent a regression in the future.  They all run very quickly and there are a lot of edge cases in the Simplex algorithm, so I&apos;d prefer to be safe.&lt;/p&gt;</comment>
                    <comment id="12752387" author="luc" created="Tue, 8 Sep 2009 08:42:51 +0000"  >&lt;p&gt;resolved in subversion repository as of r812390&lt;br/&gt;
Benjamin&apos;s patches from 2009-09-07 have been committed with very slight changes&lt;br/&gt;
(an == test between Integer instances replaced by a call to equals)&lt;br/&gt;
thanks for the patches&lt;/p&gt;</comment>
                    <comment id="12752393" author="ciaccia" created="Tue, 8 Sep 2009 08:51:14 +0000"  >&lt;p&gt;Hi all,&lt;br/&gt;
I&apos;m still not convinced the original problem is correct... Could you please try?&lt;/p&gt;

&lt;p&gt;I would add the original LP with 6 variables and 5 restrictions to the test cases, since I&apos;m not completely sure the &quot;smaller examples&quot; address exactly the same problem I posted weeks ago.&lt;/p&gt;</comment>
                    <comment id="12752662" author="bmccann" created="Tue, 8 Sep 2009 18:24:28 +0000"  >&lt;p&gt;Wow, sorry, I&apos;ll take another look and make sure to test against the original problem this time as well.&lt;/p&gt;</comment>
                    <comment id="12752797" author="bmccann" created="Tue, 8 Sep 2009 22:35:56 +0000"  >&lt;p&gt;The problem still exists when we are dropping columns moving between phase 1 and phase 2.  I was pointed towards this book for possible solutions (p80-82):&lt;br/&gt;
&lt;a href=&quot;http://www.amazon.com/Linear-Programming-Introduction-Operations-Engineering/dp/0387948333#reader&quot;&gt;http://www.amazon.com/Linear-Programming-Introduction-Operations-Engineering/dp/0387948333#reader&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="12752862" author="bmccann" created="Wed, 9 Sep 2009 01:54:40 +0000"  >&lt;p&gt;Here&apos;s a patch that correctly solves the problem Andrea posted (sorry for not completely fixing the problem with my earlier patches.)  It&apos;s mostly refactoring to make the solution easier, which was to drop positive cost non-artificial variables and nonbasic artificial variables at the end of phase 1 instead of all artificial variables.&lt;br/&gt;
There are some practical problems with degeneracy and redundant constraints that were not obvious to me from the theory when I first started working on this.  We should really test this a bit more with constraints outnumbering variables and redundant constraints to really be comfortable that all the issues are addressed, but we&apos;re certainly pretty close now if not there yet.&lt;br/&gt;
Andrea, thanks for the reports and validating fixes (or lack there of).  Luc, thanks for quickly getting these into SVN and letting me know about the problems.&lt;/p&gt;</comment>
                    <comment id="12752986" author="luc" created="Wed, 9 Sep 2009 08:55:25 +0000"  >&lt;p&gt;The patch from 2009-09-08 has been applied in subversion repository as of r812831.&lt;/p&gt;

&lt;p&gt;After the patch, an existing test (SimplexTableauTest.testdiscardArtificialVariables) failed, so I had to update the expected matrix to prevent this failure. &lt;b&gt;This should be validated&lt;/b&gt; as I really don&apos;t know if the failure were expected after the change or if something wrong occurred. Ben, could you have a look at this ?&lt;/p&gt;

&lt;p&gt;This time, I&apos;m not marking the issue as resolved, Andrea I&apos;ll wait until you consider it solved by yourself.&lt;/p&gt;

&lt;p&gt;Thanks to everybody for their time on this issue, I&apos;m sure we are gradually improving things.&lt;/p&gt;</comment>
                    <comment id="12753053" author="ciaccia" created="Wed, 9 Sep 2009 12:08:22 +0000"  >&lt;p&gt;Hi Luc, hi Ben,&lt;br/&gt;
This time I can confirm Ben&apos;s patch fixes the original problem. &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;If I find something else related to this bug (or not) I will let you know, but I&apos;m pretty sure this time the SimplexSolver is much more robust it was a couple of weeks ago!&lt;/p&gt;

&lt;p&gt;I &quot;improved&quot; the JUnit test case for this bug, I attach the patch to this message. There are 5 new assertions that check all the constraints are really satisfied.&lt;/p&gt;

&lt;p&gt;Thanks again for all the commitment&lt;br/&gt;
Andrea&lt;/p&gt;

&lt;p&gt;PS: I don&apos;t know if this is somehow related, but I found another bug &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-293&quot; title=&quot;Matrix&amp;#39;s &amp;quot;OutOfBoundException&amp;quot; in SimplexSolver&quot;&gt;&lt;del&gt;MATH-293&lt;/del&gt;&lt;/a&gt;... Ben, please look at that as well.&lt;/p&gt;</comment>
                    <comment id="12753057" author="luc" created="Wed, 9 Sep 2009 12:25:07 +0000"  >&lt;p&gt;I applied Andrea&apos;s patch in subversion as of r812921, thanks for providing it.&lt;br/&gt;
I&apos;ll wait for Ben&apos;s acknowledgement about the changes I&apos;ve made in SimplexTableauTest.testdiscardArtificialVariables before marking the issue as resolved.&lt;/p&gt;</comment>
                    <comment id="12753153" author="bmccann" created="Wed, 9 Sep 2009 16:38:28 +0000"  >&lt;p&gt;Thanks Luc.  You can close this issue.  A note, we might want to rename testdiscardArtificialVariables to testDropPhase1Objective to match the updated method name.  I overlooked this earlier.  I look at &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-293&quot; title=&quot;Matrix&amp;#39;s &amp;quot;OutOfBoundException&amp;quot; in SimplexSolver&quot;&gt;&lt;del&gt;MATH-293&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="12753498" author="luc" created="Thu, 10 Sep 2009 08:22:11 +0000"  >&lt;p&gt;fixed now (we hope)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12418860" name="SimplexSolver.patch" size="5698" author="bmccann" created="Tue, 8 Sep 2009 00:16:06 +0000" />
                    <attachment id="12419049" name="SimplexSolverTest-Andrea.patch" size="914" author="ciaccia" created="Wed, 9 Sep 2009 12:08:22 +0000" />
                    <attachment id="12418861" name="SimplexSolverTest.patch" size="4713" author="bmccann" created="Tue, 8 Sep 2009 00:16:06 +0000" />
                    <attachment id="12417328" name="SimplexSolverTest.patch" size="1121" author="bmccann" created="Fri, 21 Aug 2009 22:11:56 +0000" />
                    <attachment id="12418862" name="SimplexTableau.patch" size="4286" author="bmccann" created="Tue, 8 Sep 2009 00:16:06 +0000" />
                    <attachment id="12417327" name="SimplexTableau.patch" size="4060" author="bmccann" created="Fri, 21 Aug 2009 22:11:56 +0000" />
                    <attachment id="12419011" name="patch.zip" size="4378" author="bmccann" created="Wed, 9 Sep 2009 01:54:40 +0000" />
                    <attachment id="12418165" name="simplex.txt" size="2859" author="bmccann" created="Mon, 31 Aug 2009 17:24:04 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>8.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 21 Aug 2009 20:25:41 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-283] MultiDirectional optimzation loops forver if started at the correct solution</title>
                <link>https://issues.apache.org/jira/browse/MATH-283</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;MultiDirectional.iterateSimplex loops forever if the starting point is the correct solution.&lt;/p&gt;

&lt;p&gt;see the attached test case (testMultiDirectionalCorrectStart) as an example.&lt;/p&gt;</description>
                <environment>&lt;p&gt;none specific for the issue (it&apos;s a programming bug)&lt;/p&gt;</environment>
            <key id="12432884">MATH-283</key>
            <summary>MultiDirectional optimzation loops forver if started at the correct solution</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="1" iconUrl="https://issues.apache.org/jira/images/icons/priority_blocker.gif">Blocker</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="michael.nischt">Michael Nischt</reporter>
                        <labels>
                    </labels>
                <created>Wed, 12 Aug 2009 14:51:15 +0000</created>
                <updated>Wed, 14 Apr 2010 00:32:33 +0000</updated>
                    <resolved>Fri, 14 Aug 2009 19:25:15 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                          <timeoriginalestimate seconds="86400">24h</timeoriginalestimate>
                    <timeestimate seconds="86400">24h</timeestimate>
                                  <comments>
                    <comment id="12742395" author="michael.nischt" created="Wed, 12 Aug 2009 15:02:33 +0000"  >&lt;p&gt;the failing unit test&lt;/p&gt;</comment>
                    <comment id="12743378" author="luc" created="Fri, 14 Aug 2009 19:25:15 +0000"  >&lt;p&gt;fixed in subversion repository as of r804328&lt;br/&gt;
thanks for the report and the fix suggestion&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12416328" name="MultiDirectionalCorrectStartTest.java" size="2851" author="michael.nischt" created="Wed, 12 Aug 2009 15:02:33 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 14 Aug 2009 19:25:15 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-282] ChiSquaredDistributionImpl.cumulativeProbability &gt; 1</title>
                <link>https://issues.apache.org/jira/browse/MATH-282</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Calling &lt;br/&gt;
new ChiSquaredDistributionImpl(1.0).cumulativeProbability(66.41528551683048)&lt;/p&gt;

&lt;p&gt;returns 1.000000000000004, which is bogus (should never be &amp;gt; 1)&lt;/p&gt;</description>
                <environment>&lt;p&gt;called from Scala code&lt;/p&gt;</environment>
            <key id="12432549">MATH-282</key>
            <summary>ChiSquaredDistributionImpl.cumulativeProbability &gt; 1</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="psteitz">Phil Steitz</assignee>
                                <reporter username="akiezun">Adam Kiezun</reporter>
                        <labels>
                    </labels>
                <created>Fri, 7 Aug 2009 18:24:07 +0000</created>
                <updated>Tue, 13 Apr 2010 10:26:15 +0000</updated>
                    <resolved>Mon, 8 Mar 2010 23:00:26 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                <version>1.2</version>
                <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12740905" author="luc" created="Sat, 8 Aug 2009 16:05:08 +0000"  >&lt;p&gt;The problem seems to be related to numerical accuracy.&lt;br/&gt;
The computation here involves lots of iterations in the Gamma.regularizedGammaP method (115 iterations on my computer) and the final expression involves several transcendant functions (exp, log and logGamma).&lt;/p&gt;

&lt;p&gt;The proposed patch simply filters out the values exceeding 1.0 in the gamma distribution implementation which is used by Chi squared distribution.&lt;/p&gt;

&lt;p&gt;I am not sure this is the best fix to this issue, so I won&apos;t commit it myself. I prefer someone else could verify it.&lt;/p&gt;</comment>
                    <comment id="12741113" author="psteitz" created="Sun, 9 Aug 2009 18:07:36 +0000"  >&lt;p&gt;I am working on getting a bound in terms of the arguments for the Gamma distribution similar to what we do for the Normal distribution, so we can return 1 when we know that the tail probability is going to be bounded above by a sufficiently small number - say, 10E-20.   &lt;/p&gt;</comment>
                    <comment id="12741161" author="psteitz" created="Mon, 10 Aug 2009 01:20:00 +0000"  >&lt;p&gt;Unfortunately, from R and &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;, it looks like the value in the issue report should be ~ 1 - 10^-13, and I don&apos;t like the idea of top-coding with such a tight bound. Need to look at the regularized gamma approximation.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &quot;The Moment Bound Is Tighter Than Chernoff&apos;s Bound for Positive Tail Probabilities&quot;, Thomas K Philips, Randolph Nelson,  American Statistician 1995 vol. 49 (May, 1995) pp. 175-178&lt;/p&gt;</comment>
                    <comment id="12764514" author="psteitz" created="Sun, 11 Oct 2009 21:53:35 +0000"  >&lt;p&gt;The problem in Gamma.regularizedGammaP reported here is also causing incorrect results from PoissonDistributionImpl#cumulativeProbability.  The (currently disabled) test case, testCumulativeProbabilitySpecial() in PoissonDistributionTest illustrates the problem.  For some (not all) large lambda and some (not all) x in (0.9 * lambda, lambda), NaN or zero cumulative probabilities are returned.&lt;/p&gt;</comment>
                    <comment id="12836590" author="psteitz" created="Mon, 22 Feb 2010 12:04:27 +0000"  >&lt;p&gt;I have narrowed this down to two issues in Gamma&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;choice of when to use the series expansion vs continued fraction in computing the regularized gamma functions - changing from (a &amp;gt;= 1.0 &amp;amp;&amp;amp; x &amp;gt; a) to (x &amp;gt; a + 1) as criteria for when to use continued fraction reduces incidence of NaN values returned and improves accuracy for some arguments.&lt;/li&gt;
	&lt;li&gt;handling the case when the continued fraction diverges.  I am still working on convincing myself that divergence is expected in failing test cases, in which case, logic can be changed to catch the continued fraction divergence and fall back to the series approximation in that case.  This will require refactoring the regularizedGammaP and Q functions to encapsulate the series / fraction computation instead of calling one another based on argument test.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12839654" author="psteitz" created="Mon, 1 Mar 2010 11:50:49 +0000"  >&lt;p&gt;The attached patch resolves this issue as well as &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-301&quot; title=&quot;Erf(z) should return 1.0 for z &amp;#39;large&amp;#39; but  fails with a MaxIterationsExceededException for z &amp;gt; 26.0.&quot;&gt;&lt;del&gt;MATH-301&lt;/del&gt;&lt;/a&gt; and the problems described above with the Poisson distribution.  The patch bundles quite a few changes, some of which are not strictly necessary to resolve these issues.  The following is a summary.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;BrentSolver has been changed to expose its configured absolute accuracy.   This solver is used by the default inverse cum implementation in AbstractContinuousDistribution and the hard-coded setting (1E-6) was limiting accuracy in inverse cumulative probability estimates.  AbstractContinuousDistribution was changed to allow distributions to set this value and NormalDistributionImpl was changed to set it to 1E-9 by default and allow users to configure it via a constructor argument.   If all are happy with this change, I will similarly change other distributions to override the new getSolverAbsoluteAccuracy method and add constructors to configure the value.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;AbstractContinuousDistribution and AbstractIntegerDistribution inverseCumulativeProbability methods have been modified to check for NaN values returned by cumulativeProbability and throw MathExceptions when this happens.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;The criteria for choosing between the Lanczos series and continued fraction expansion when computing regularized gamma functions has been changed to (x &amp;gt;= a + 1).  When using the series approximation (regularizedGammaP), divergence to infinity is checked and when this happens, 1 is returned.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;When scaling continued fractions to (try to) avoid divergence to infinity, the larger of a and b is used as a scale factor and the attempt to scale is repeated up to 5 times, using successive powers of the scale factor.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;The maximum number of iterations used in estimating cumulative probabilities for PoissonDistributionImpl has been decreased from Integer.MAX_VALUE to 10000000 and made configurable.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Review and comment much appreciated.  One thing that I would like improve is to get decent top-coding in place in terms of the arguments to the regularized gamma functions.  The Poisson inverse cum tests take a very long time now because for very large values of x, the continued fractions are taking a long time to converge.  This is needless computation, as the value returned is 1.  We should be able to analytically determine bounds here.&lt;/p&gt;</comment>
                    <comment id="12839809" author="luc" created="Mon, 1 Mar 2010 19:25:39 +0000"  >&lt;p&gt;This looks fine to me (congrats for the error messages translations).&lt;br/&gt;
I am a little puzzled by the MathException thrown in some methods to be caught in the same method and wrapped in a FunctionEvaluationException. Could the MathException be a FunctionEvaluationException from the start (even if other MathException can be thrown and need to be wrapped by themselves) ?&lt;/p&gt;</comment>
                    <comment id="12839839" author="psteitz" created="Mon, 1 Mar 2010 20:18:25 +0000"  >&lt;p&gt;Thanks, Luc! &lt;/p&gt;

&lt;p&gt;Here is the perhaps strange logic explaining the odd exception nesting that you pointed out.  When a cumulativeProbability function returns NaN in the context of estimating inverse cum, the immediate exception is really a bad-value-returned exception, not a FunctionEvaluationException - there is no exception encountered evaluating the function, it just returns a bad value - so I code it as MathException.  The exception that the caller gets is FunctionEvaluationException, because there is in fact an error evaluating the inverse cum.  Wrapped inside is the MathException with the message indicating that NaN was returned by a cum activation.   &lt;/p&gt;

&lt;p&gt;I guess it comes down to how we view FunctionEvaluationException and in particular is it appropriate to throw when NaN is returned by a method that logically should not return NaNs.  Thinking some more about this, I think so, so I will change the patch to throw FunctionEvaluationException in the first incidence.&lt;/p&gt;

&lt;p&gt;Thanks again for looking at this carefully.  I am glad I got the translations right - the one I was worried about was as much English as French - &quot;diverge to NaN&quot; makes me cringe a little &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12842838" author="psteitz" created="Mon, 8 Mar 2010 23:00:26 +0000"  >&lt;p&gt;Fixed in r920558&lt;/p&gt;</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="10030">
                <name>Reference</name>
                                                <inwardlinks description="is related to">
                            <issuelink>
            <issuekey id="12437655">MATH-301</issuekey>
        </issuelink>
                    </inwardlinks>
                            </issuelinktype>
                    </issuelinks>
                <attachments>
                    <attachment id="12437474" name="distributions.patch" size="25526" author="psteitz" created="Mon, 1 Mar 2010 11:50:49 +0000" />
                    <attachment id="12415937" name="math-282.patch" size="1898" author="luc" created="Sat, 8 Aug 2009 16:05:08 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 8 Aug 2009 16:05:08 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-281] RealMatrix.subtract javadoc typo</title>
                <link>https://issues.apache.org/jira/browse/MATH-281</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I think the javadoc for RealMatrix.subtract is wrong.  It says &quot;@return this + m&quot;, which perhaps should be &quot;@return this - m&quot;&lt;/p&gt;

&lt;p&gt;Index: src/main/java/org/apache/commons/math/linear/RealMatrix.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; src/main/java/org/apache/commons/math/linear/RealMatrix.java	(revision 799902)&lt;br/&gt;
+++ src/main/java/org/apache/commons/math/linear/RealMatrix.java	(working copy)&lt;br/&gt;
@@ -60,7 +60,7 @@&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Compute this minus m.&lt;br/&gt;
      *&lt;/li&gt;
	&lt;li&gt;@param m    matrix to be subtracted&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* @return     this + m&lt;br/&gt;
+     * @return     this - m&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;@throws  IllegalArgumentException if m is not the same size as this&lt;br/&gt;
      */&lt;br/&gt;
     RealMatrix subtract(RealMatrix m) throws IllegalArgumentException;&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="12431966">MATH-281</key>
            <summary>RealMatrix.subtract javadoc typo</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="ashuang">Albert Huang</reporter>
                        <labels>
                    </labels>
                <created>Sat, 1 Aug 2009 17:45:29 +0000</created>
                <updated>Fri, 7 Aug 2009 09:19:02 +0000</updated>
                    <resolved>Sat, 1 Aug 2009 19:03:01 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12737935" author="luc" created="Sat, 1 Aug 2009 19:03:00 +0000"  >&lt;p&gt;fixed in subversion repository as of r799906&lt;br/&gt;
thanks for the report&lt;/p&gt;</comment>
                    <comment id="12740475" author="luc" created="Fri, 7 Aug 2009 09:19:02 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 1 Aug 2009 19:03:00 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-280] bug in inverseCumulativeProbability() for Normal Distribution</title>
                <link>https://issues.apache.org/jira/browse/MATH-280</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>
&lt;ul&gt;
	&lt;li&gt;@version $Revision: 617953 $ $Date: 2008-02-02 22:54:00 -0700 (Sat, 02 Feb 2008) $&lt;br/&gt;
 */&lt;br/&gt;
public class NormalDistributionImpl extends AbstractContinuousDistribution &lt;/li&gt;
&lt;/ul&gt;



&lt;ul&gt;
	&lt;li&gt;@version $Revision: 506600 $ $Date: 2007-02-12 12:35:59 -0700 (Mon, 12 Feb 2007) $&lt;br/&gt;
 */&lt;br/&gt;
public abstract class AbstractContinuousDistribution&lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt;This code:&lt;/p&gt;

&lt;p&gt;        	DistributionFactory factory = app.getDistributionFactory();&lt;br/&gt;
        	NormalDistribution normal = factory.createNormalDistribution(0,1);&lt;br/&gt;
        	double result = normal.inverseCumulativeProbability(0.9772498680518209);&lt;/p&gt;

&lt;p&gt;gives the exception below. It should return (approx) 2.0000...&lt;/p&gt;

&lt;p&gt;normal.inverseCumulativeProbability(0.977249868051820); works fine&lt;/p&gt;

&lt;p&gt;These also give errors:&lt;br/&gt;
0.9986501019683698 (should return 3.0000...)&lt;br/&gt;
0.9999683287581673 (should return 4.0000...)&lt;/p&gt;

&lt;p&gt;org.apache.commons.math.MathException: Number of iterations=1, maximum iterations=2,147,483,647, initial=1, lower bound=0, upper bound=179,769,313,486,231,570,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000, final a value=0, final b value=2, f(a)=-0.477, f(b)=0&lt;br/&gt;
	at org.apache.commons.math.distribution.AbstractContinuousDistribution.inverseCumulativeProbability(AbstractContinuousDistribution.java:103)&lt;br/&gt;
	at org.apache.commons.math.distribution.NormalDistributionImpl.inverseCumulativeProbability(NormalDistributionImpl.java:145)&lt;/p&gt;

</description>
                <environment>&lt;p&gt;Java 1.5&lt;/p&gt;</environment>
            <key id="12429647">MATH-280</key>
            <summary>bug in inverseCumulativeProbability() for Normal Distribution</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="murkle">Michael Borcherds</reporter>
                        <labels>
                    </labels>
                <created>Mon, 6 Jul 2009 21:26:57 +0000</created>
                <updated>Fri, 7 Aug 2009 09:18:40 +0000</updated>
                    <resolved>Tue, 7 Jul 2009 09:21:22 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12728000" author="luc" created="Tue, 7 Jul 2009 09:21:22 +0000"  >&lt;p&gt;fixed in subversion repository as of r791766&lt;br/&gt;
thanks for the report&lt;/p&gt;</comment>
                    <comment id="12740474" author="luc" created="Fri, 7 Aug 2009 09:18:40 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 7 Jul 2009 09:21:22 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-279] MultipleLinearRegression - test for minimum number of samples</title>
                <link>https://issues.apache.org/jira/browse/MATH-279</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;It&apos;s currently possible to pass in so few rows (samples) that there isn&apos;t a row for each column (predictor).  Does this look like the right thing to do?&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;Index: AbstractMultipleLinearRegression.java
===================================================================
--- AbstractMultipleLinearRegression.java       (revision 786758)
+++ AbstractMultipleLinearRegression.java       (working copy)
@@ -91,6 +91,9 @@
                   &lt;span class=&quot;code-quote&quot;&gt;&quot;dimension mismatch {0} != {1}&quot;&lt;/span&gt;,
                   (x == &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) ? 0 : x.length,
                   (y == &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) ? 0 : y.length);
+        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (x[0].length &amp;gt; x.length){
+            &lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; MathRuntimeException.createIllegalArgumentException(
+                    &lt;span class=&quot;code-quote&quot;&gt;&quot;not enough data (&quot;&lt;/span&gt; + x.length + &lt;span class=&quot;code-quote&quot;&gt;&quot; rows) &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; many predictors (&quot;&lt;/span&gt; + x[0].length + &lt;span class=&quot;code-quote&quot;&gt;&quot; predictors)&quot;&lt;/span&gt;);
         }
     }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
</description>
                <environment></environment>
            <key id="12428442">MATH-279</key>
            <summary>MultipleLinearRegression - test for minimum number of samples</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="mbjorkegren">Michael Bjorkegren</reporter>
                        <labels>
                    </labels>
                <created>Sat, 20 Jun 2009 07:13:00 +0000</created>
                <updated>Fri, 7 Aug 2009 09:18:13 +0000</updated>
                    <resolved>Sun, 5 Jul 2009 13:31:29 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                          <timeoriginalestimate seconds="600">10m</timeoriginalestimate>
                    <timeestimate seconds="600">10m</timeestimate>
                                  <comments>
                    <comment id="12727333" author="luc" created="Sun, 5 Jul 2009 13:31:29 +0000"  >&lt;p&gt;fixed in subversion repository as of r791244&lt;br/&gt;
patch was only slightly modified to avoid a NPE&lt;br/&gt;
thanks for the patch&lt;/p&gt;</comment>
                    <comment id="12740473" author="luc" created="Fri, 7 Aug 2009 09:18:13 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 5 Jul 2009 13:31:29 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-274] testing for symmetric positive definite matrix in CholeskyDecomposition</title>
                <link>https://issues.apache.org/jira/browse/MATH-274</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I used this matrix:&lt;/p&gt;

&lt;p&gt;        double[][] cv = {&lt;br/&gt;
            {0.40434286, 0.09376327, 0.30328980, 0.04909388},&lt;br/&gt;
            {0.09376327, 0.10400408, 0.07137959, 0.04762857},&lt;br/&gt;
            {0.30328980, 0.07137959, 0.30458776, 0.04882449},&lt;br/&gt;
            {0.04909388, 0.04762857, 0.04882449, 0.07543265}&lt;br/&gt;
        };&lt;br/&gt;
&lt;br/&gt;
And it works fine, because it is symmetric positive definite&lt;br/&gt;
&lt;br/&gt;
I tried this matrix:&lt;br/&gt;
&lt;br/&gt;
        double[][] cv = {&lt;br/&gt;
            {0.40434286, -0.09376327, 0.30328980, 0.04909388},&lt;br/&gt;
            {-0.09376327, 0.10400408, 0.07137959, 0.04762857},&lt;br/&gt;
            {0.30328980, 0.07137959, 0.30458776, 0.04882449},&lt;/p&gt;
            {0.04909388, 0.04762857, 0.04882449, 0.07543265}
&lt;p&gt;        };&lt;/p&gt;

&lt;p&gt;And it should throw an exception but it does not.  I tested the matrix in R and R&apos;s cholesky decomposition method returns that the matrix is not symmetric positive definite.&lt;/p&gt;

&lt;p&gt;Obviously your code is not catching this appropriately.&lt;/p&gt;

&lt;p&gt;By the way (in my opinion) the use of exceptions to check these conditions is not the best design or use for exceptions.  If you are going to force the use to try and catch these exceptions at least provide methods  to test the conditions prior to the possibility of the exception.  &lt;/p&gt;
</description>
                <environment>&lt;p&gt;Mac OS X, NetBeans&lt;/p&gt;</environment>
            <key id="12427143">MATH-274</key>
            <summary>testing for symmetric positive definite matrix in CholeskyDecomposition</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="rossetti">Manuel Rossetti</reporter>
                        <labels>
                    </labels>
                <created>Thu, 4 Jun 2009 19:24:12 +0000</created>
                <updated>Fri, 7 Aug 2009 09:16:16 +0000</updated>
                    <resolved>Thu, 4 Jun 2009 20:11:26 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12716383" author="luc" created="Thu, 4 Jun 2009 20:11:26 +0000"  >&lt;p&gt;fixed in subversion repository as of r 781845&lt;br/&gt;
Concerning the exception, it is not possible to check the matrix without trying to decompose it, so providing an external check would be a waste as it would already do almost everything. In fact, it was exactly the reason for the bug: the check was done too early on the raw matrix, not on the matrix after some changes have been made to its elements.&lt;br/&gt;
thanks for the report&lt;/p&gt;</comment>
                    <comment id="12716402" author="rossetti" created="Thu, 4 Jun 2009 20:57:10 +0000"  >&lt;p&gt;Luc,&lt;/p&gt;

&lt;p&gt;Thanks for fixing the error.&lt;/p&gt;

&lt;p&gt;You are missing my point.  You should provide the user the opportunity  &lt;br/&gt;
to check the condition, rather than having to rely on exceptions.  The  &lt;br/&gt;
client can make the decision whether it is a waste or not.&lt;/p&gt;

&lt;p&gt;And, we will agree to disagree on how the library is using exceptions.&lt;/p&gt;

&lt;p&gt;Regards,&lt;br/&gt;
Manuel&lt;/p&gt;



&lt;p&gt;-----------------------------------------------------&lt;br/&gt;
Manuel D. Rossetti, Ph.D., P.E.&lt;br/&gt;
Associate Professor of Industrial Engineering&lt;br/&gt;
University of Arkansas&lt;br/&gt;
Department of Industrial Engineering&lt;br/&gt;
4207 Bell Engineering Center&lt;br/&gt;
Fayetteville, AR 72701&lt;br/&gt;
Phone: (479) 575-6756&lt;br/&gt;
Fax: (479) 575-8431&lt;br/&gt;
email: rossetti@uark.edu&lt;br/&gt;
www: www.uark.edu/~rossetti&lt;/p&gt;


</comment>
                    <comment id="12740469" author="luc" created="Fri, 7 Aug 2009 09:16:16 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 4 Jun 2009 20:11:26 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-273] Basic variable is not found correctly in simplex tableau</title>
                <link>https://issues.apache.org/jira/browse/MATH-273</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The last patch to SimplexTableau caused an automated test suite I&apos;m running at work to go down a new code path and uncover what is hopefully the last bug remaining in the Simplex code.&lt;br/&gt;
SimplexTableau was assuming an entry in the tableau had to be nonzero to indicate a basic variable, which is incorrect - the entry should have a value equal to 1.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12426998">MATH-273</key>
            <summary>Basic variable is not found correctly in simplex tableau</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="bmccann">Benjamin McCann</reporter>
                        <labels>
                    </labels>
                <created>Wed, 3 Jun 2009 05:11:34 +0000</created>
                <updated>Fri, 7 Aug 2009 09:15:43 +0000</updated>
                    <resolved>Wed, 3 Jun 2009 09:07:06 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12715805" author="bmccann" created="Wed, 3 Jun 2009 05:12:13 +0000"  >&lt;p&gt;Here&apos;s the patch.&lt;/p&gt;</comment>
                    <comment id="12715875" author="luc" created="Wed, 3 Jun 2009 09:07:06 +0000"  >&lt;p&gt;fixed in subversion repository as of r781304&lt;br/&gt;
patch applied&lt;br/&gt;
thanks&lt;/p&gt;</comment>
                    <comment id="12740468" author="luc" created="Fri, 7 Aug 2009 09:15:43 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12409728" name="SimplexSolverTest.patch" size="1047" author="bmccann" created="Wed, 3 Jun 2009 05:12:13 +0000" />
                    <attachment id="12409727" name="SimplexTableau.patch" size="887" author="bmccann" created="Wed, 3 Jun 2009 05:12:13 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 3 Jun 2009 09:07:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-272] Simplex Solver arrives at incorrect solution</title>
                <link>https://issues.apache.org/jira/browse/MATH-272</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I have reduced the problem reported to me down to a minimal test case which I will attach.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12426720">MATH-272</key>
            <summary>Simplex Solver arrives at incorrect solution</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="bmccann">Benjamin McCann</reporter>
                        <labels>
                    </labels>
                <created>Sat, 30 May 2009 01:01:37 +0000</created>
                <updated>Fri, 7 Aug 2009 09:15:24 +0000</updated>
                    <resolved>Tue, 2 Jun 2009 19:38:46 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12714641" author="bmccann" created="Sat, 30 May 2009 01:02:41 +0000"  >&lt;p&gt;Test case to be added to SimplexSolverTest.  It is currently failing and should be fixed.&lt;/p&gt;</comment>
                    <comment id="12714661" author="bmccann" created="Sat, 30 May 2009 03:12:31 +0000"  >&lt;p&gt;Previously, there was a bug where we could set one of a number of variables equal to some value.  We were setting all the variables instead of choosing one.  When I patched that bug, I did it incorrectly.  This is a correct implementation, which causes the old bug and the attached test to both pass.&lt;/p&gt;</comment>
                    <comment id="12715641" author="luc" created="Tue, 2 Jun 2009 19:38:46 +0000"  >&lt;p&gt;fixed in subversion repository as of r781135&lt;br/&gt;
patch applied&lt;br/&gt;
thanks&lt;/p&gt;</comment>
                    <comment id="12715648" author="bmccann" created="Tue, 2 Jun 2009 19:53:09 +0000"  >&lt;p&gt;Thanks!&lt;/p&gt;


</comment>
                    <comment id="12740467" author="luc" created="Fri, 7 Aug 2009 09:15:24 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12409441" name="SimplexSolvetTest.txt" size="939" author="bmccann" created="Sat, 30 May 2009 01:02:41 +0000" />
                    <attachment id="12409449" name="SimplexTableau.patch" size="2879" author="bmccann" created="Sat, 30 May 2009 03:12:31 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 2 Jun 2009 19:38:46 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-267] Need a digamma function</title>
                <link>https://issues.apache.org/jira/browse/MATH-267</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>
&lt;p&gt;A mahout summer of code student needed a digamma function with Apache permissions so I wrote one.  It includes test cases, correct copyright and seems to work well.  I don&apos;t know where in commons math this would go so I figured I would post this and ask for advice.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12426209">MATH-267</key>
            <summary>Need a digamma function</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tdunning">Ted Dunning</reporter>
                        <labels>
                    </labels>
                <created>Sat, 23 May 2009 23:40:41 +0000</created>
                <updated>Fri, 7 Aug 2009 09:15:01 +0000</updated>
                    <resolved>Mon, 25 May 2009 13:22:22 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                                                    <comments>
                    <comment id="12712474" author="tdunning" created="Sat, 23 May 2009 23:41:49 +0000"  >&lt;p&gt;Source code for implementation.&lt;/p&gt;</comment>
                    <comment id="12712486" author="psteitz" created="Sun, 24 May 2009 02:45:14 +0000"  >&lt;p&gt;Thanks!  Have a look at the o.a.c.m.special package,  There is a Gamma class there that could use this,&lt;/p&gt;</comment>
                    <comment id="12712503" author="tdunning" created="Sun, 24 May 2009 04:37:57 +0000"  >&lt;p&gt;Here is a patch that integrates the digamma function into the normal commons math structure.&lt;/p&gt;</comment>
                    <comment id="12712504" author="tdunning" created="Sun, 24 May 2009 04:40:00 +0000"  >
&lt;p&gt;I have left this open rather than resolve it because I don&apos;t see a &quot;patch available&quot; state such as I am used to on Hadoop and related projects.&lt;/p&gt;

&lt;p&gt;The patch is available and should be ready for committing (subject to committers approving, of course).&lt;/p&gt;</comment>
                    <comment id="12712511" author="psteitz" created="Sun, 24 May 2009 06:05:02 +0000"  >&lt;p&gt;Patch applied in r778091 with only minor changes. thanks!&lt;/p&gt;</comment>
                    <comment id="12712518" author="tdunning" created="Sun, 24 May 2009 06:37:12 +0000"  >&lt;p&gt;The previous patch lost some comments from my original.&lt;/p&gt;

&lt;p&gt;Also, I added a trigramma function.  &lt;/p&gt;</comment>
                    <comment id="12712519" author="tdunning" created="Sun, 24 May 2009 06:39:08 +0000"  >&lt;p&gt;I improved the javadoc and added a trigamma function with associated tests.&lt;/p&gt;

&lt;p&gt;This patch is relative to current trunk which already contains the digamma function that Phil just committed. &lt;/p&gt;</comment>
                    <comment id="12712718" author="psteitz" created="Mon, 25 May 2009 13:22:22 +0000"  >&lt;p&gt;Second patch applied.  I made a few small changes to the javadoc to match the style of &lt;span class=&quot;error&quot;&gt;&amp;#91;math&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;Thanks!&lt;/p&gt;</comment>
                    <comment id="12740466" author="luc" created="Fri, 7 Aug 2009 09:15:01 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12408900" name="Adds_digamma_function.patch" size="4950" author="tdunning" created="Sun, 24 May 2009 04:37:57 +0000" />
                    <attachment id="12408901" name="Adds_trigamma_function,_improves_comments.patch" size="5777" author="tdunning" created="Sun, 24 May 2009 06:39:07 +0000" />
                    <attachment id="12408892" name="digamma.tgz" size="12482" author="tdunning" created="Sat, 23 May 2009 23:41:49 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 24 May 2009 02:45:14 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-260] Inconsistent API in Frequency</title>
                <link>https://issues.apache.org/jira/browse/MATH-260</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The overloaded Frequency methods are not consistent in the parameter types that they handle.&lt;/p&gt;

&lt;p&gt;addValue() has an Integer version which converts the parameter to a Long, and then calls addValue(Object).&lt;/p&gt;

&lt;p&gt;The various getxxx() methods all handle Integer parameters as an Object.&lt;/p&gt;

&lt;p&gt;Seems to me that it would be better to treat Integer consistently.&lt;/p&gt;

&lt;p&gt;But perhaps there is a good reason for having an addValue(Integer) method but no getxxx(Integer) methods?&lt;br/&gt;
If so, then it would be helpful to document this.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422791">MATH-260</key>
            <summary>Inconsistent API in Frequency</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Tue, 14 Apr 2009 13:38:52 +0000</created>
                <updated>Wed, 14 Apr 2010 00:39:55 +0000</updated>
                    <resolved>Wed, 30 Dec 2009 20:12:52 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.1</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12699011" author="psteitz" created="Wed, 15 Apr 2009 01:14:36 +0000"  >&lt;p&gt;the getXxx methods handle Integer arguments by converting them to longs.  See, eg. the test case, testIntegerValues()&lt;/p&gt;</comment>
                    <comment id="12699141" author="sebb@apache.org" created="Wed, 15 Apr 2009 10:23:54 +0000"  >&lt;p&gt;Yes, I know that the getXXX(Object) methods handle Integer specially; but so does the addValue(Object) method - it has to, in case an Integer is passed as an Object.&lt;/p&gt;

&lt;p&gt;But why is there an addValue(Integer) method? What does it achieve?&lt;br/&gt;
There are no corresponding getXXX(Integer) methods.&lt;/p&gt;</comment>
                    <comment id="12794711" author="luc" created="Sun, 27 Dec 2009 17:56:28 +0000"  >&lt;p&gt;Note: the addValue(Object) has been deprecated as of 2.0 and replaced by addValue(Comparable).&lt;br/&gt;
I think we could also deprecate or even remove addValue(Integer) since addValue(Comparable) is sufficient for all purposes. Removing the method would probably not harm any users if they can recompile their code (but it would harm if they cannot recompile, of course).&lt;/p&gt;</comment>
                    <comment id="12795426" author="psteitz" created="Wed, 30 Dec 2009 20:12:52 +0000"  >&lt;p&gt;addValue(Integer) has been deprecated, marked for removal in 3.0&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 15 Apr 2009 01:14:36 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-259] Bugs in Frequency API</title>
                <link>https://issues.apache.org/jira/browse/MATH-259</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I think the existing Frequency API has some bugs in it.&lt;/p&gt;

&lt;p&gt;The addValue(Object v) method allows one to add a plain Object, but one cannot add anything further to the instance, as the second add fails with IllegalArgumentException.&lt;br/&gt;
In fact, the problem is with the first call to addValue(Object) which should not allow a plain Object to be added - it should only allow Comparable objects.&lt;br/&gt;
This could be fixed by checking that the object is Comparable.&lt;/p&gt;

&lt;p&gt;Similar considerations apply to the getCumFreq(Object) and getCumPct(Object) methods - they will only work with objects that implement Comparable.&lt;/p&gt;

&lt;p&gt;The getCount(Object) and getPct(Object) methods don&apos;t fail when given a non-Comparable object (because the class cast exception is caught), however they just return 0 as if the object was not present:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt; OBJ = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;();
        f.addValue(OBJ); &lt;span class=&quot;code-comment&quot;&gt;// This ought to fail, but doesn&apos;t, causing the unexpected behaviour below
&lt;/span&gt;        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(f.getCount(OBJ)); &lt;span class=&quot;code-comment&quot;&gt;// 0
&lt;/span&gt;        &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(f.getPct(OBJ)); &lt;span class=&quot;code-comment&quot;&gt;// 0.0&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Rather than adding extra checks for Comparable, it seems to me that the API would be much improved by using Comparable instead of Object.&lt;br/&gt;
Also, it should make it easier to implement generics.&lt;/p&gt;

&lt;p&gt;However, this would cause compilation failures for some programs that pass Object rather than Comparable to the class.&lt;br/&gt;
These would need recoding, but I think they would continue to run OK against the new API.&lt;/p&gt;

&lt;p&gt;It would also affect the run-time behaviour slightly, as the first attempt to add a non-Comparable object would fail, rather than the second add of a possibly valid object.&lt;br/&gt;
But is that a viable program? It can only add one object, and any attempt to get statistics will either return 0 or an Exception, and applying the instanceof fix would also cause it to fail.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422113">MATH-259</key>
            <summary>Bugs in Frequency API</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Mon, 6 Apr 2009 13:16:51 +0000</created>
                <updated>Fri, 7 Aug 2009 09:12:49 +0000</updated>
                    <resolved>Sat, 25 Apr 2009 17:52:18 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12699014" author="psteitz" created="Wed, 15 Apr 2009 01:20:49 +0000"  >&lt;p&gt;I am OK with adding a check and throwing illegalArgumentExeption if an object that does not implement Comparable is supplied to these methods (as indicated in the javadoc), but not keen on introducing the compatibility issue.&lt;/p&gt;</comment>
                    <comment id="12700183" author="sebb@apache.org" created="Fri, 17 Apr 2009 13:55:10 +0000"  >&lt;p&gt;See:&lt;/p&gt;

&lt;p&gt;URL: &lt;a href=&quot;http://svn.apache.org/viewvc?rev=765996&amp;amp;view=rev&quot;&gt;http://svn.apache.org/viewvc?rev=765996&amp;amp;view=rev&lt;/a&gt;&lt;br/&gt;
Log:&lt;br/&gt;
&lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-259&quot; title=&quot;Bugs in Frequency API&quot;&gt;&lt;del&gt;MATH-259&lt;/del&gt;&lt;/a&gt; - check for Comparable when adding values&lt;/p&gt;

&lt;p&gt;I overlooked the change of Exception, so there&apos;s also:&lt;/p&gt;

&lt;p&gt;URL: &lt;a href=&quot;http://svn.apache.org/viewvc?rev=766003&amp;amp;view=rev&quot;&gt;http://svn.apache.org/viewvc?rev=766003&amp;amp;view=rev&lt;/a&gt;&lt;br/&gt;
Log:&lt;br/&gt;
&lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-259&quot; title=&quot;Bugs in Frequency API&quot;&gt;&lt;del&gt;MATH-259&lt;/del&gt;&lt;/a&gt; - throw IllegalArgument rather than ClassCast to better retain original behaviour&lt;/p&gt;

&lt;p&gt;==&lt;/p&gt;

&lt;p&gt;I added a new method&lt;/p&gt;

&lt;p&gt;   public void addValue(Comparable&amp;lt;?&amp;gt; v)&lt;/p&gt;

&lt;p&gt;which is called from&lt;/p&gt;

&lt;p&gt;   public void addValue(Object v)&lt;/p&gt;

&lt;p&gt;which I took the liberty of deprecating, so the compiler will warn users about non-Comparable objects.&lt;br/&gt;
Hope that&apos;s OK.&lt;/p&gt;

&lt;p&gt;Note that it&apos;s still possible for mutually non-Comparable values to be added, because the code does not check comparisons both ways, it relies on HashMap to do so.&lt;/p&gt;

&lt;p&gt;I.e. if B.compareTo(A) is OK, but A.compareTo(B) does not exist, then it is possible to add A, then B without any complaints.&lt;br/&gt;
This later causes a ClassCastException in some of the getXXX() methods.&lt;br/&gt;
However this is not a valid Comparable implementation, as they are supposed to be symmetric.&lt;/p&gt;</comment>
                    <comment id="12702738" author="sebb@apache.org" created="Sat, 25 Apr 2009 17:52:18 +0000"  >&lt;p&gt;API now tidied up as far as possible whilst still being compatible.&lt;/p&gt;</comment>
                    <comment id="12740460" author="luc" created="Fri, 7 Aug 2009 09:12:49 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="10030">
                <name>Reference</name>
                                <outwardlinks description="relates to">
                            <issuelink>
            <issuekey id="12422817">MATH-261</issuekey>
        </issuelink>
                    </outwardlinks>
                                            </issuelinktype>
                    </issuelinks>
                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 15 Apr 2009 01:20:49 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-258] Frequency class Javadoc is ambiguous; need more tests</title>
                <link>https://issues.apache.org/jira/browse/MATH-258</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;Extracted from mailing list so it does not get lost&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;The Javadoc is ambiguous - can one add both int and char to the same instance of Frequency?&lt;/p&gt;

&lt;p&gt;Depending on how one reads the class Javadoc, this should be allowed,&lt;br/&gt;
as one can compare &quot;int&quot; and &quot;char&quot; in the same way that one can&lt;br/&gt;
compare &quot;int&quot; and &quot;long&quot; - i.e. both are &quot;comparable&quot;. Now &quot;int&quot; and&lt;br/&gt;
&quot;char&quot; are not Comparable, but then neither are &quot;int&quot; and &quot;long&quot;.&lt;/p&gt;

&lt;p&gt;I think the Javadoc needs to make the intention clear, and then the&lt;br/&gt;
tests can be enhanced to enforce the documented behaviour.&lt;/p&gt;

&lt;p&gt;At present, there&apos;s no check to show what happens when int and char are mixed.&lt;/p&gt;

&lt;p&gt;There are other tests that should be added, to show what is expected when mixing different Comparable classes.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422095">MATH-258</key>
            <summary>Frequency class Javadoc is ambiguous; need more tests</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Mon, 6 Apr 2009 08:55:42 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:21 +0000</updated>
                    <resolved>Sun, 12 Apr 2009 19:33:58 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12698260" author="psteitz" created="Sun, 12 Apr 2009 19:33:58 +0000"  >&lt;p&gt;Fixed in r764316&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 12 Apr 2009 19:33:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-257] FastFourierTransformer.MultiDimensionalComplexMatrix.get() not consistent with FastFourierTransformer.MultiDimensionalComplexMatrix.set()</title>
                <link>https://issues.apache.org/jira/browse/MATH-257</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;FastFourierTransformer.MultiDimensionalComplexMatrix.get() is not consistent with FastFourierTransformer.MultiDimensionalComplexMatrix.set().&lt;/p&gt;

&lt;p&gt;The set() method does not allow a null parameter to get past the first check.&lt;/p&gt;

&lt;p&gt;The get() method allows a null parameter provided dimensionSize.length &amp;lt;= 1.&lt;/p&gt;

&lt;p&gt;This seems wrong, both because it is inconsistent and because it may allow an NPE later if dimensionSize.length == 1&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422072">MATH-257</key>
            <summary>FastFourierTransformer.MultiDimensionalComplexMatrix.get() not consistent with FastFourierTransformer.MultiDimensionalComplexMatrix.set()</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sun, 5 Apr 2009 17:35:07 +0000</created>
                <updated>Sun, 14 Mar 2010 01:42:39 +0000</updated>
                    <resolved>Sun, 5 Apr 2009 18:43:21 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12695887" author="luc" created="Sun, 5 Apr 2009 18:43:21 +0000"  >&lt;p&gt;fixed in subversion repository as of r762131.&lt;br/&gt;
I took the opportunity to also simplify the initialization of the dimensionSize array, using a two passes algorithm.&lt;br/&gt;
The inconsistency by itself was removed by having bot set and get be no-op for null vectors&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 5 Apr 2009 18:43:21 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-255] MessagesResources_fr has package-protected mutable static array; should be made private</title>
                <link>https://issues.apache.org/jira/browse/MATH-255</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;MessagesResources_fr has package-protected mutable static array; this should be made private.&lt;/p&gt;

&lt;p&gt;It does not appear to be accessed outside the class, and anyway the getContents() method provides safe access to a clone of the array.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422055">MATH-255</key>
            <summary>MessagesResources_fr has package-protected mutable static array; should be made private</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sat, 4 Apr 2009 21:28:30 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:21 +0000</updated>
                    <resolved>Sun, 5 Apr 2009 14:37:08 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12695863" author="luc" created="Sun, 5 Apr 2009 14:37:08 +0000"  >&lt;p&gt;fixed in subversion repository as of r762096&lt;br/&gt;
thanks for the report&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 5 Apr 2009 14:37:08 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-254] UnivariateRealSolverUtils.factory is a mutable static field which is not initialised safely.</title>
                <link>https://issues.apache.org/jira/browse/MATH-254</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;UnivariateRealSolverUtils.factory is a mutable static field which is not initialised safely.&lt;/p&gt;

&lt;p&gt;Suggest using IODH (init on demand holder) idiom for this, else use synchronized getInstance().&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422054">MATH-254</key>
            <summary>UnivariateRealSolverUtils.factory is a mutable static field which is not initialised safely.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sat, 4 Apr 2009 21:24:02 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:21 +0000</updated>
                    <resolved>Sun, 5 Apr 2009 15:18:18 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12695865" author="luc" created="Sun, 5 Apr 2009 15:18:18 +0000"  >&lt;p&gt;fixed in subversion repository as of r762102&lt;br/&gt;
thanks for the report and the suggestion. IODH is a pattern I really appreciate, it is neat and elegant.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 5 Apr 2009 15:18:18 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-253] MathRuntimeException and MathException are both thread-hostile.</title>
                <link>https://issues.apache.org/jira/browse/MATH-253</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;MathRuntimeException and MathException are both thread-hostile.&lt;/p&gt;

&lt;p&gt;They have a mutable static field cachedResources which is used in performing translations.&lt;/p&gt;

&lt;p&gt;If two threads use different locales - which is highly likely in the case of non-US locales, as some methods use Locale.US - then they may get corrupt or incorrect output.&lt;/p&gt;

&lt;p&gt;If a cache is really desired, it could either be ThreadLocal, or volatile, but it that case the translate method needs to fetch the value once (and update it once if necessary).&lt;/p&gt;

&lt;p&gt;As it stands, the method can check the resource, find it is OK, then fetch it again to use it, by which time it might have changed. Further, one thread may set the variable, and another thread may see a partially constructed Resources object (it&apos;s not final).&lt;/p&gt;</description>
                <environment></environment>
            <key id="12422053">MATH-253</key>
            <summary>MathRuntimeException and MathException are both thread-hostile.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sat, 4 Apr 2009 21:22:53 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Sun, 5 Apr 2009 15:37:33 +0000</resolved>
                                            <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12695866" author="luc" created="Sun, 5 Apr 2009 15:37:33 +0000"  >&lt;p&gt;fixed in subversion repository as of r762107.&lt;br/&gt;
The cache has been removed completely, so the bundle is retrieved and used at each request.&lt;br/&gt;
Since this is only used when errors are triggered, there should not be any noticeable drop in performance.&lt;br/&gt;
thanks fo the report.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 5 Apr 2009 15:37:33 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-252] Fraction.comparTo returns 0 for some differente fractions</title>
                <link>https://issues.apache.org/jira/browse/MATH-252</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;If two different fractions evaluate to the same double due to limited precision,&lt;br/&gt;
the compareTo methode returns 0 as if they were identical.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-comment&quot;&gt;// value is roughly PI - 3.07e-18
&lt;/span&gt;Fraction pi1 = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Fraction(1068966896, 340262731);

&lt;span class=&quot;code-comment&quot;&gt;// value is roughly PI + 1.936e-17
&lt;/span&gt;Fraction pi2 = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Fraction( 411557987, 131002976);

&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(pi1.doubleValue() - pi2.doubleValue()); &lt;span class=&quot;code-comment&quot;&gt;// exactly 0.0 due to limited IEEE754 precision
&lt;/span&gt;&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(pi1.compareTo(pi2)); &lt;span class=&quot;code-comment&quot;&gt;// display 0 instead of a negative value&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12421502">MATH-252</key>
            <summary>Fraction.comparTo returns 0 for some differente fractions</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Sun, 29 Mar 2009 16:50:35 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Sun, 29 Mar 2009 16:52:34 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12693586" author="luc" created="Sun, 29 Mar 2009 16:52:34 +0000"  >&lt;p&gt;fixed in subversion as of r759725&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-244] Website SVN instructions refer to nonexistent branch</title>
                <link>https://issues.apache.org/jira/browse/MATH-244</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;On the Source Repository page on the Math website:&lt;br/&gt;
&lt;a href=&quot;http://commons.apache.org/math/source-repository.html&quot;&gt;http://commons.apache.org/math/source-repository.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The SVN checkout instructions refer to the MATH_2_0 branch, which doesn&apos;t exist. I substituted the trunk instead.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12413112">MATH-244</key>
            <summary>Website SVN instructions refer to nonexistent branch</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jparker">Joel Parker</reporter>
                        <labels>
                    </labels>
                <created>Fri, 23 Jan 2009 17:28:38 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Fri, 23 Jan 2009 19:43:43 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12666670" author="luc" created="Fri, 23 Jan 2009 19:43:43 +0000"  >&lt;p&gt;Fixed in subversion as of r737149.&lt;br/&gt;
The site has been regenerated, it should be put online in a few hours.&lt;br/&gt;
Thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 23 Jan 2009 19:43:43 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-243] MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE</title>
                <link>https://issues.apache.org/jira/browse/MATH-243</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The gcd method should throw an Exception for gcd(Integer.MIN_VALUE, 0), like for gcd(Integer.MIN_VALUE, Integer.MIN_VALUE). The method should only return nonnegative results.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12412941">MATH-243</key>
            <summary>MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chsemrau">Christian Semrau</reporter>
                        <labels>
                    </labels>
                <created>Wed, 21 Jan 2009 21:15:30 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Sat, 21 Feb 2009 13:55:19 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12665978" author="chsemrau" created="Wed, 21 Jan 2009 21:50:48 +0000"  >&lt;p&gt;Attached is a patch for gcd, and also for lcm, which failed for some special cases: lcm failed for (0,0) and for (Integer.MIN_VALUE, power of 2).&lt;/p&gt;

&lt;p&gt;I also added Javadoc for special cases.&lt;/p&gt;</comment>
                    <comment id="12675561" author="luc" created="Sat, 21 Feb 2009 13:55:19 +0000"  >&lt;p&gt;Fixed in trunk as of r746511.&lt;br/&gt;
Thanks for the patch&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12398432" name="gcdPatch.txt" size="6345" author="chsemrau" created="Wed, 21 Jan 2009 21:50:48 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 21 Feb 2009 13:55:19 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-241] MathUtils.binomialCoefficient(n,k) fails for large results</title>
                <link>https://issues.apache.org/jira/browse/MATH-241</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Probably due to rounding errors, MathUtils.binomialCoefficient(n,k) fails for results near Long.MAX_VALUE.&lt;/p&gt;

&lt;p&gt;The existence of failures can be demonstrated by testing the recursive property:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;         assertEquals(MathUtils.binomialCoefficient(65,32) + MathUtils.binomialCoefficient(65,33),
                 MathUtils.binomialCoefficient(66,33));
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Or by directly using the (externally calculated and hopefully correct) expected value:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;         assertEquals(7219428434016265740L, MathUtils.binomialCoefficient(66,33));
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I suggest a nonrecursive test implementation along the lines of&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-style: solid;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;border-bottom-style: solid;&quot;&gt;&lt;b&gt;MathUtilsTest.java&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/**
     * Exact implementation using BigInteger and the explicit formula
     * (n, k) == ((k-1)*...*n) / (1*...*(n-k))
     */
	&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt; binomialCoefficient(&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; n, &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; k) {
		&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (k == 0 || k == n)
			&lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; 1;
		BigInteger result = BigInteger.ONE;
		&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; i = k + 1; i &amp;lt;= n; i++) {
			result = result.multiply(BigInteger.valueOf(i));
		}
		&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; i = 1; i &amp;lt;= n - k; i++) {
			result = result.divide(BigInteger.valueOf(i));
		}
		&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (result.compareTo(BigInteger.valueOf(&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt;.MAX_VALUE)) &amp;gt; 0) {
			&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArithmeticException(
                                &lt;span class=&quot;code-quote&quot;&gt;&quot;Binomial coefficient overflow: &quot;&lt;/span&gt; + n + &lt;span class=&quot;code-quote&quot;&gt;&quot;, &quot;&lt;/span&gt; + k);
		}
		&lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; result.longValue();
	}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;Which would allow you to test the expected values directly:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;         assertEquals(binomialCoefficient(66,33), MathUtils.binomialCoefficient(66,33));
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12412642">MATH-241</key>
            <summary>MathUtils.binomialCoefficient(n,k) fails for large results</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="psteitz">Phil Steitz</assignee>
                                <reporter username="chsemrau">Christian Semrau</reporter>
                        <labels>
                    </labels>
                <created>Fri, 16 Jan 2009 23:34:23 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Mon, 19 Jan 2009 23:53:48 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12665187" author="psteitz" created="Mon, 19 Jan 2009 18:40:57 +0000"  >&lt;p&gt;First, thanks for reporting this.  Due to log/exp rounding and double/long conversion, the current code returns bad values for many long-representable values, starting as low as n = 48.  The returned value can be off by as much as 200,000.  The error in binomial(66, 29) is 214,880.  All b(n,k) for n &amp;lt; 48 are exact.&lt;/p&gt;

&lt;p&gt;Attached is a patch that ensures accuracy up to n = 200 (specified as a constant) and allows the user to force exact computation for values beyond this if desired.  For n &amp;lt;= 200, the implementation works like an unwound recursive implementation.   I also improved the accuracy of the double-valued and log versions.   The latter perform better than the current implementations, but the long-valued version is approximately 8x slower than the current version.  I did not benchmark the BigInteger version, but suspect that would be slower still.  The most accurate (for n &amp;lt;= 200) non-recursive formula that I could find is the one that I implemented in the double version.&lt;/p&gt;

&lt;p&gt;I also investigated overflow behavior and added tests to confirm correctness.  As stated in the API doc, overflows start at n = 67.  For n = 200,  values of k less than 14 or greater than 186 can still be computed without overflow; but all others throw ArithmeticException.&lt;/p&gt;

&lt;p&gt;I would appreciate feedback on the patch and any better ideas on how to fix the problem.&lt;/p&gt;</comment>
                    <comment id="12665249" author="chsemrau" created="Mon, 19 Jan 2009 22:05:59 +0000"  >&lt;p&gt;Attached is my version of a new binomialCoefficient function.&lt;/p&gt;</comment>
                    <comment id="12665253" author="chsemrau" created="Mon, 19 Jan 2009 22:16:06 +0000"  >&lt;p&gt;I think the recursive computation of Pascal&apos;s triangle (even with caching or dynamic programming) is unnecessarily complicated except to ensure correct values.&lt;/p&gt;

&lt;p&gt;The attached patch ensures accuracy for all values that can be represented as a long integer, with a running time proportional to k*log(k) (assuming gcd(i,j) takes log(j) steps). It should be faster than the current version for n &amp;lt;= 61, but for n &amp;gt; 61 my version computes as much as k different gcd values, which might be slower.&lt;/p&gt;

&lt;p&gt;I did not modify the double and log version, but your patch can be applied to these.&lt;/p&gt;</comment>
                    <comment id="12665284" author="psteitz" created="Mon, 19 Jan 2009 23:53:48 +0000"  >&lt;p&gt;Applied second patch along with changes to double, log versions from first patch in r735879.  Many thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12398252" name="binomialPatch.txt" size="15426" author="psteitz" created="Mon, 19 Jan 2009 18:40:57 +0000" />
                    <attachment id="12398265" name="binomialPatch_cs.txt" size="7965" author="chsemrau" created="Mon, 19 Jan 2009 22:05:59 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 19 Jan 2009 18:40:57 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-240] MathUtils.factorial(n) fails for n &gt;= 17</title>
                <link>https://issues.apache.org/jira/browse/MATH-240</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The result of MathUtils.factorial( n ) for n = 17, 18, 19 is wrong, probably because of rounding errors in the double calculations.&lt;/p&gt;

&lt;p&gt;Replace the first line of MathUtilsTest.testFactorial() by&lt;/p&gt;

&lt;p&gt;        for (int i = 1; i &amp;lt;= 20; i++) {&lt;/p&gt;

&lt;p&gt;to check all valid arguments for the long result and see the failure.&lt;/p&gt;

&lt;p&gt;I suggest implementing a simple loop to multiply the long result - or even using a precomputed long[] - instead of adding logarithms.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12412638">MATH-240</key>
            <summary>MathUtils.factorial(n) fails for n &gt;= 17</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="psteitz">Phil Steitz</assignee>
                                <reporter username="chsemrau">Christian Semrau</reporter>
                        <labels>
                    </labels>
                <created>Fri, 16 Jan 2009 22:43:04 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Mon, 19 Jan 2009 19:43:52 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12665204" author="psteitz" created="Mon, 19 Jan 2009 19:43:52 +0000"  >&lt;p&gt;Thanks for reporting this.  Fixed in r735781.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 19 Jan 2009 19:43:52 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-238] MathUtils.gcd(u, v) fails when u and v both contain a high power of 2</title>
                <link>https://issues.apache.org/jira/browse/MATH-238</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The test at the beginning of MathUtils.gcd(u, v) for arguments equal to zero fails when u and v contain high enough powers of 2 so that their product overflows to zero.&lt;/p&gt;

&lt;p&gt;        assertEquals(3 * (1&amp;lt;&amp;lt;15), MathUtils.gcd(3 * (1&amp;lt;&amp;lt;20), 9 * (1&amp;lt;&amp;lt;15)));&lt;/p&gt;

&lt;p&gt;Fix: Replace the test at the start of MathUtils.gcd()&lt;/p&gt;

&lt;p&gt;        if (u * v == 0) {&lt;/p&gt;

&lt;p&gt;by&lt;/p&gt;

&lt;p&gt;        if (u == 0 || v == 0) {&lt;/p&gt;</description>
                <environment></environment>
            <key id="12412633">MATH-238</key>
            <summary>MathUtils.gcd(u, v) fails when u and v both contain a high power of 2</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chsemrau">Christian Semrau</reporter>
                        <labels>
                    </labels>
                <created>Fri, 16 Jan 2009 22:24:24 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:20 +0000</updated>
                    <resolved>Fri, 16 Jan 2009 23:07:17 +0000</resolved>
                            <version>2.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12664729" author="luc" created="Fri, 16 Jan 2009 23:07:17 +0000"  >&lt;p&gt;fixed in trunk as of r73517&lt;/p&gt;

&lt;p&gt;thanks for the report&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 16 Jan 2009 23:07:17 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-227] denominatorDegreeOfFreedom in FDistribution leads to IllegalArgumentsException in UnivariateRealSolverUtils.bracket</title>
                <link>https://issues.apache.org/jira/browse/MATH-227</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;We are using the FDistributionImpl from the commons.math project to do&lt;br/&gt;
some statistical calculations, namely receiving the upper and lower&lt;br/&gt;
boundaries of a confidence interval. Everything is working fine and the&lt;br/&gt;
results are matching our reference calculations.&lt;/p&gt;

&lt;p&gt;However, the FDistribution behaves strange if a&lt;br/&gt;
denominatorDegreeOfFreedom of 2 is used, with an alpha-value of 0.95.&lt;br/&gt;
This results in an IllegalArgumentsException, stating:&lt;/p&gt;

&lt;p&gt;Invalid endpoint parameters:  lowerBound=0.0 initial=Infinity&lt;br/&gt;
upperBound=1.7976931348623157E308&lt;/p&gt;

&lt;p&gt;coming from&lt;br/&gt;
org.apache.commons.math.analysis.UnivariateRealSolverUtils.bracket&lt;/p&gt;

&lt;p&gt;The problem is the &apos;initial&apos; parameter to that function, wich is&lt;br/&gt;
POSITIVE_INFINITY and therefore not within the boundaries. I already&lt;br/&gt;
pinned down the problem to the FDistributions getInitialDomain()-method,&lt;br/&gt;
wich goes like:&lt;/p&gt;

&lt;p&gt;        return getDenominatorDegreesOfFreedom() /&lt;br/&gt;
                    (getDenominatorDegreesOfFreedom() - 2.0);&lt;/p&gt;

&lt;p&gt;Obviously, in case of denominatorDegreesOfFreedom == 2, this must lead&lt;br/&gt;
to a division-by-zero, resulting in POSTIVE_INFINITY. The result of this&lt;br/&gt;
operation is then directly passed into the&lt;br/&gt;
UnivariateRealSolverUtils.bracket() - method as second argument.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Java 1.5.0_15, Linux&lt;/p&gt;</environment>
            <key id="12405126">MATH-227</key>
            <summary>denominatorDegreeOfFreedom in FDistribution leads to IllegalArgumentsException in UnivariateRealSolverUtils.bracket</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="brentworden">Brent Worden</assignee>
                                <reporter username="joerx">Joerg Henning</reporter>
                        <labels>
                    </labels>
                <created>Thu, 25 Sep 2008 08:23:07 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:19 +0000</updated>
                    <resolved>Fri, 26 Sep 2008 03:11:58 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>Nightly Builds</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12634738" author="brentworden" created="Fri, 26 Sep 2008 03:11:58 +0000"  >&lt;p&gt;SVN 699157.  fixed in trunk.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 26 Sep 2008 03:11:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-226] CorrelatedRandomVectorGenerator generates invariant samples</title>
                <link>https://issues.apache.org/jira/browse/MATH-226</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;For the following code sample, the output is:&lt;br/&gt;
1.0,3.9432161557722925,16.66859790068678,1.0743673824292688,&lt;br/&gt;
1.0,-1.4103098147521094,-2.670854139636077,1.8368602953644368,&lt;br/&gt;
1.0,0.230029048125738,12.67864233710285,0.1124537698401884,&lt;/p&gt;

&lt;p&gt;Why is the first column of each row fixed at 1.0?&lt;/p&gt;

&lt;p&gt;Here is the code that generated this:&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.linear.RealMatrix;&lt;br/&gt;
import org.apache.commons.math.linear.RealMatrixImpl;&lt;br/&gt;
import org.apache.commons.math.random.CorrelatedRandomVectorGenerator;&lt;br/&gt;
import org.apache.commons.math.random.GaussianRandomGenerator;&lt;br/&gt;
import org.apache.commons.math.random.JDKRandomGenerator;&lt;/p&gt;

&lt;p&gt;public class TestMath {&lt;/p&gt;

&lt;p&gt;	public static void sampler(double[] mean, double[][] cov, double[][] s) {&lt;br/&gt;
		RealMatrix covRM = new RealMatrixImpl(cov);&lt;br/&gt;
		try {&lt;br/&gt;
			CorrelatedRandomVectorGenerator sg = new CorrelatedRandomVectorGenerator(&lt;br/&gt;
					mean, covRM, 0.00001, new GaussianRandomGenerator(&lt;br/&gt;
							new JDKRandomGenerator()));&lt;/p&gt;

&lt;p&gt;			for (int i = 0; i &amp;lt; s.length; i++) {
				s[i] = sg.nextVector();
			}&lt;br/&gt;
		} catch (Exception e) {
			e.printStackTrace();
			System.exit(-1);
		}&lt;/p&gt;

&lt;p&gt;	}&lt;/p&gt;

&lt;p&gt;	static void print(double[][] s) {&lt;br/&gt;
		for (int r = 0; r &amp;lt; s.length; r++) {
			for (int c = 0; c &amp;lt; s[r].length; c++)
				System.out.print(s[r][c] + &quot;,&quot;);
			System.out.println();

		}&lt;/p&gt;

&lt;p&gt;	}&lt;/p&gt;

&lt;p&gt;	public static void main(String[] args) {&lt;br/&gt;
		double[] mean = { 1, 1, 10, 1 };&lt;br/&gt;
		double[][] cov = { { 1, 3, 2, 6 }, { 3, 13, 16, 2 }, { 2, 16, 38, -1 },&lt;br/&gt;
				{ 6, 2, -1, 197 } };&lt;/p&gt;


&lt;p&gt;		double[][] s = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt;;&lt;/p&gt;

&lt;p&gt;		TestMath.sampler(mean, cov, s);&lt;br/&gt;
		TestMath.print(s);&lt;/p&gt;


&lt;p&gt;	}&lt;br/&gt;
}&lt;/p&gt;</description>
                <environment>&lt;p&gt;WIN32&lt;/p&gt;</environment>
            <key id="12404467">MATH-226</key>
            <summary>CorrelatedRandomVectorGenerator generates invariant samples</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ssiegel95">Stuart Siegel</reporter>
                        <labels>
                    </labels>
                <created>Tue, 16 Sep 2008 20:08:48 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:19 +0000</updated>
                    <resolved>Tue, 16 Sep 2008 21:05:59 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12631550" author="luc" created="Tue, 16 Sep 2008 21:05:59 +0000"  >&lt;p&gt;There was an error in the Choleski decomposition with rows reordering. The wrong permutation was used&lt;br/&gt;
(swap&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; instead of index&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; in the root matrix construction at the end of the decompose method).&lt;/p&gt;

&lt;p&gt;The problem is now fixed in subversion repository, in branch MATH_2_0 as of r696054, and a new test has been added using your data.&lt;/p&gt;

&lt;p&gt;Thanks for reporting the problem.&lt;/p&gt;</comment>
                    <comment id="12631578" author="ssiegel95" created="Tue, 16 Sep 2008 22:28:11 +0000"  >&lt;p&gt;Thanks for the very speedy reply and thanks for commons-math, it has proven to be very helpful.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 16 Sep 2008 21:05:59 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-221] Result of multiplying and equals for complex numbers is wrong</title>
                <link>https://issues.apache.org/jira/browse/MATH-221</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Hi.&lt;/p&gt;

&lt;p&gt;The bug relates on complex numbers.&lt;br/&gt;
The methods &quot;multiply&quot; and &quot;equals&quot; of the class Complex are involved.&lt;/p&gt;

&lt;p&gt;mathematic background:  (0,i) * (-1,0i) = (0,-i).&lt;/p&gt;

&lt;p&gt;little java program + output that shows the bug:&lt;br/&gt;
-----------------------------------------------------------------------&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; org.apache.commons.math.complex.*;
&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; class TestProg {
        &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt; void main(&lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;[] args) {

                ComplexFormat f = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ComplexFormat();
                Complex c1 = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Complex(0,1);
                Complex c2 = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Complex(-1,0);

                Complex res = c1.multiply(c2);
                Complex comp = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; Complex(0,-1);

                &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;res:  &quot;&lt;/span&gt;+f.format(res));
                &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;comp: &quot;&lt;/span&gt;+f.format(comp));

                &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;.out.println(&lt;span class=&quot;code-quote&quot;&gt;&quot;res=comp: &quot;&lt;/span&gt;+res.equals(comp));
        }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;-----------------------------------------------------------------------&lt;/p&gt;

&lt;p&gt;res:  -0 - 1i&lt;br/&gt;
comp: 0 - 1i&lt;br/&gt;
res=comp: false&lt;/p&gt;

&lt;p&gt;-----------------------------------------------------------------------&lt;/p&gt;

&lt;p&gt;I think the &quot;equals&quot; should return &quot;true&quot;.&lt;br/&gt;
The problem could either be the &quot;multiply&quot; method that gives (-0,-1i) instead of (0,-1i),&lt;br/&gt;
or if you think thats right, the equals method has to be modified.&lt;/p&gt;

&lt;p&gt;Good Luck&lt;br/&gt;
Dieter&lt;/p&gt;</description>
                <environment>&lt;p&gt;OS: Debian lenny&lt;br/&gt;
IDE: Eclipse; Version: 3.4.0; Build id: I20080617-2000&lt;br/&gt;
java.runtime.version=1.6.0_04-b12&lt;br/&gt;
java.vendor.url=&lt;a href=&quot;http://java.sun.com/&quot;&gt;http://java.sun.com/&lt;/a&gt;&lt;/p&gt;</environment>
            <key id="12403362">MATH-221</key>
            <summary>Result of multiplying and equals for complex numbers is wrong</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="news.dieter">Dieter Roth</reporter>
                        <labels>
                    </labels>
                <created>Fri, 29 Aug 2008 13:31:56 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:19 +0000</updated>
                    <resolved>Fri, 29 Aug 2008 15:52:38 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12627019" author="luc" created="Fri, 29 Aug 2008 15:52:38 +0000"  >&lt;p&gt;According to IEEE-754 (the standard that specifies double number representation), 0 is a signed value, so there are two different representations: +0 and -0, and there is a specific rule that say these two representations should always compare as equal.&lt;/p&gt;

&lt;p&gt;The fact the multiplication returns a real part as -0 is therefore correct behavior. The fact it is not equal to another value where +0 appears was an error in out implementation of the equal method.&lt;/p&gt;

&lt;p&gt;The problem has been fixed in the subversion repository (in branch 2.0) as of r690308.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 29 Aug 2008 15:52:38 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-214] fixed step Runge-Kutta integrators slightly change step size</title>
                <link>https://issues.apache.org/jira/browse/MATH-214</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When a fixed step Runge-Kutta integrator is used, it may slightly change the step size for all integration range.&lt;br/&gt;
This is due to a step recomputation feature which ensures the last step ends exactly at the end of the range.&lt;/p&gt;

&lt;p&gt;This feature should be removed, since it is unnatural and does not obey users choices.&lt;/p&gt;

&lt;p&gt;It should be replaced by the same kind of solution already adopted for discrete events: truncating only the last step.&lt;/p&gt;</description>
                <environment>&lt;p&gt;all&lt;/p&gt;</environment>
            <key id="12400013">MATH-214</key>
            <summary>fixed step Runge-Kutta integrators slightly change step size</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 Jul 2008 12:34:24 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:18 +0000</updated>
                    <resolved>Thu, 10 Jul 2008 12:43:08 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12612468" author="luc" created="Thu, 10 Jul 2008 12:43:08 +0000"  >&lt;p&gt;fixed as of r675552&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-209] RealMatrixImpl#operate gets result vector dimensions wrong</title>
                <link>https://issues.apache.org/jira/browse/MATH-209</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;&lt;tt&gt;org.apache.commons.math.linear.RealMatrixImpl#operate&lt;/tt&gt; tries to create a result vector that always has the same length as the input vector. This can result in runtime exceptions if the matrix is non-square and it always yields incorrect results if the matrix is non-square. The correct behaviour would of course be to create a vector with the same length as the row dimension of the matrix.&lt;/p&gt;

&lt;p&gt;Thus line 640 in RealMatrixImpl.java should read&lt;br/&gt;
  {{double[] out = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;nRows&amp;#93;&lt;/span&gt;;}}&lt;br/&gt;
instead of&lt;br/&gt;
  {{double[] out = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;v.length&amp;#93;&lt;/span&gt;;}}&lt;/p&gt;</description>
                <environment></environment>
            <key id="12398389">MATH-209</key>
            <summary>RealMatrixImpl#operate gets result vector dimensions wrong</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="murphy">Thomas Chust</reporter>
                        <labels>
                    </labels>
                <created>Tue, 17 Jun 2008 03:02:48 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:18 +0000</updated>
                    <resolved>Tue, 17 Jun 2008 19:10:53 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                          <timeoriginalestimate seconds="120">2m</timeoriginalestimate>
                    <timeestimate seconds="120">2m</timeestimate>
                                  <comments>
                    <comment id="12605695" author="luc" created="Tue, 17 Jun 2008 19:10:52 +0000"  >&lt;p&gt;Sorry for this dumb mistake.&lt;/p&gt;

&lt;p&gt;Fixed in 2.0 branch as of r668798.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 17 Jun 2008 19:10:52 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-207] Implementation of GeneticAlgorithm.nextGeneration() is wrong</title>
                <link>https://issues.apache.org/jira/browse/MATH-207</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The implementation of GeneticAlgorithm.nextGeneration() is wrong, since the only way how a Chromosome can get into the new generation is by mutation. &lt;/p&gt;

&lt;p&gt;Enclosed, I am sending a patch for this.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12396580">MATH-207</key>
            <summary>Implementation of GeneticAlgorithm.nextGeneration() is wrong</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="psteitz">Phil Steitz</assignee>
                                <reporter username="david.stefka">David Stefka</reporter>
                        <labels>
                    </labels>
                <created>Wed, 21 May 2008 21:50:37 +0000</created>
                <updated>Fri, 7 Aug 2009 09:20:08 +0000</updated>
                    <resolved>Tue, 30 Jun 2009 00:44:50 +0000</resolved>
                            <version>2.0</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                          <timeoriginalestimate seconds="600">10m</timeoriginalestimate>
                    <timeestimate seconds="600">10m</timeestimate>
                                  <comments>
                    <comment id="12598803" author="david.stefka" created="Wed, 21 May 2008 21:51:27 +0000"  >&lt;p&gt;Patch for the bug&lt;/p&gt;</comment>
                    <comment id="12635173" author="psteitz" created="Sat, 27 Sep 2008 18:09:43 +0000"  >&lt;p&gt;Patch applied to MATH_2_0 branch in r699704.&lt;/p&gt;

&lt;p&gt;Leaving open because I think we need to either make nextGeneration public or protected or make it configurable.  Interested in comments on this.&lt;/p&gt;</comment>
                    <comment id="12635347" author="david.stefka@gmail.com" created="Mon, 29 Sep 2008 11:05:45 +0000"  >&lt;p&gt;Dear Phil,&lt;/p&gt;

&lt;p&gt;if you are interested in the topic of genetic algorithms, I am sending a &lt;br/&gt;
simple implementation of GA using the commons-math framework. If you find any &lt;br/&gt;
of the ideas in it useful, you may use it.&lt;/p&gt;

&lt;p&gt;Best regards,&lt;br/&gt;
David Stefka&lt;/p&gt;


&lt;p&gt;&amp;#8211; &lt;br/&gt;
David Stefka&lt;br/&gt;
david.stefka@gmail.com (personal mail)&lt;/p&gt;
</comment>
                    <comment id="12677207" author="chengas123" created="Fri, 27 Feb 2009 02:07:51 +0000"  >&lt;p&gt;I think that making nextGeneration public would be reasonable.&lt;br/&gt;
A few other thoughts about the API:&lt;br/&gt;
All the setters should be changed to constructor arguments.  If you do not call each of the setters then you are in an illegal state.  You avoid the problem of having some call evolve before the mutation policy and crossover policy are set if you just make them required in the constructor.&lt;br/&gt;
For crossOverRate and mutationRate we should specify that the input is expected to be between 0 and 1 and throw an exception when given invalid input.  It&apos;s currently not clear in the javadocs what is expected.&lt;/p&gt;</comment>
                    <comment id="12677830" author="bmccann" created="Sun, 1 Mar 2009 19:41:20 +0000"  >&lt;p&gt;Patch to improve the API.&lt;/p&gt;</comment>
                    <comment id="12680229" author="bmccann" created="Mon, 9 Mar 2009 18:50:07 +0000"  >&lt;p&gt;Any thoughts on the patch submitted to clean up the API?&lt;/p&gt;</comment>
                    <comment id="12683007" author="david.stefka@gmail.com" created="Wed, 18 Mar 2009 12:50:10 +0000"  >&lt;p&gt;I think the ideas to clean up the API are okay. However, I don&apos;t know whether the patch is against the latest version. Things are starting to be a bit messy... &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12683283" author="psteitz" created="Thu, 19 Mar 2009 02:00:28 +0000"  >&lt;p&gt;Sorry for delay in reviewing these patches.  I like both the implementation (David&apos;s first patch) and the API improvements and will apply them both if I can get answers to the following.&lt;/p&gt;

&lt;p&gt;1) David - pls confirm that you can grant the code in your patch.  It is a borderline case whether or not we need a code grant.  Given that it just implements the commons-math ga framework, I think it is OK to commit without a grant; but since you did not include ASL license headers in the patch, I need you to confirm that you own the code and can freely contribute it under the terms of the Apache Contributor License Agreement.  If you don&apos;t mind, it would be good to file a CLA.&lt;/p&gt;

&lt;p&gt;2) David&apos;s patch looks like it has some JDK 1.6 dependencies.  Math 2.0 targets 1.5+, so these need to be removed.  I can do this; but a revised patch with these removed and ASL headers would be appreciated.&lt;/p&gt;

&lt;p&gt;3) Ben - why expose fields as protected?  &lt;/p&gt;

&lt;p&gt;Thanks for the patches!&lt;/p&gt;</comment>
                    <comment id="12683493" author="david.stefka@gmail.com" created="Thu, 19 Mar 2009 15:46:01 +0000"  >&lt;p&gt;ad 1) what do you mean by &quot;file a CLA&quot;? Should I include the license header (e.g. in GeneticAlgorithm.java) to every file in the framework? I do own the code and I agree with the Apache license (&lt;a href=&quot;http://www.apache.org/licenses/LICENSE-2.0&quot;&gt;http://www.apache.org/licenses/LICENSE-2.0&lt;/a&gt;)&lt;br/&gt;
ad 2) okay, i will try to make it Java 1.5+ compatible&lt;/p&gt;

&lt;p&gt;BTW, I am currently working on a better way of representing permutations, so do not include the original patch now. I will post here a revised version of the implementation in a week or so.&lt;/p&gt;</comment>
                    <comment id="12683597" author="psteitz" created="Thu, 19 Mar 2009 20:18:19 +0000"  >&lt;p&gt;Thanks, David!&lt;/p&gt;

&lt;p&gt;All files should include headers like what you see in GenericAlgorithm.java or any other apache java source file.  As long as you own the code and are willing to attach those headers, we should be OK.   A Contributors Licence Agreement (CLA) is a good thing to have on file and will be required in any case should you become a committer.  Have a look at the &quot;Contributor License Agreements&quot; section at &lt;a href=&quot;http://www.apache.org/licenses/&quot;&gt;http://www.apache.org/licenses/&lt;/a&gt; to find the form.  The form itself includes info on how to submit it.&lt;/p&gt;

&lt;p&gt;Thanks again for your conttribution.&lt;/p&gt;</comment>
                    <comment id="12689486" author="david.stefka@gmail.com" created="Thu, 26 Mar 2009 13:48:43 +0000"  >&lt;p&gt;Hi again,&lt;/p&gt;

&lt;p&gt;I have finished work on better representation of permutations in GA, so I am sending the implementation in a .zip file. The code includes:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;new implementation of RandomKey &amp;#8211; chromosome representing permutations; the old PermutationChromosome implementation has been removed&lt;/li&gt;
	&lt;li&gt;some minor improvements (chromosome&apos;s representation is held in an unmodifiable list instead of an array, better implementation of generic issues, renaming of several classes, etc.)&lt;/li&gt;
	&lt;li&gt;GeneticAlgorithm has a static Random instance, which is used for all random numbers in the implementation. This is useful for debugging, because if the Random is initialized to a particular seed, the behavior can be reproduced. If a similar mechanism is already somewhere in the&lt;/li&gt;
	&lt;li&gt;the code should be java 1.5 compatible&lt;/li&gt;
	&lt;li&gt;all the files should include the Apache license headers&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I have also filled and signed the CLA and sent it to secretary@apache.org&lt;/p&gt;</comment>
                    <comment id="12689487" author="david.stefka@gmail.com" created="Thu, 26 Mar 2009 13:50:12 +0000"  >&lt;p&gt;New implementation of basic GA algorithms&lt;/p&gt;</comment>
                    <comment id="12705721" author="chengas123" created="Mon, 4 May 2009 20:08:04 +0000"  >&lt;p&gt;Sorry for my delayed response.  JIRA didn&apos;t email me on any of these updates for whatever reason.&lt;br/&gt;
There&apos;s no real need to make the fields protected in my patch.  Private would be fine.  I&apos;ve just gotten in the habit of frequently using protected to allow easier subclassing and unit testing, but those fields all have public getters, so no harm in making them private.&lt;/p&gt;</comment>
                    <comment id="12719319" author="psteitz" created="Sun, 14 Jun 2009 19:08:40 +0000"  >&lt;p&gt;Committed a slightly modified version of David&apos;s last patch in r784604.&lt;/p&gt;

&lt;p&gt;Other than minor javadoc/formatting changes to make checkstyle happy, I also made the shared source of randomness pluggable.&lt;/p&gt;

&lt;p&gt;I am not 100% happy with the static randomGenerator attached to GeneticAlgorithm, though I understand and support the need to ensure reproducibility for some applications.  Comments / suggestions for better ways to do this welcome.&lt;/p&gt;

&lt;p&gt;Leaving open as we need to update the user guide to complete this.&lt;/p&gt;</comment>
                    <comment id="12725409" author="psteitz" created="Tue, 30 Jun 2009 00:44:50 +0000"  >&lt;p&gt;User guide updated in r789511&lt;/p&gt;</comment>
                    <comment id="12740477" author="luc" created="Fri, 7 Aug 2009 09:20:08 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12403714" name="geneticAlgorithms.zip" size="49710" author="david.stefka@gmail.com" created="Thu, 26 Mar 2009 13:50:12 +0000" />
                    <attachment id="12401205" name="geneticalgorithm.patch" size="8034" author="bmccann" created="Sun, 1 Mar 2009 19:41:20 +0000" />
                    <attachment id="12391126" name="genetics_impl.zip" size="34274" author="david.stefka@gmail.com" created="Mon, 29 Sep 2008 11:05:45 +0000" />
                    <attachment id="12382518" name="patch" size="2144" author="david.stefka" created="Wed, 21 May 2008 21:51:27 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>4.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 27 Sep 2008 18:09:43 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-206] ComplexFormat.parse doesn&apos;t parse a double e.g. 0.0</title>
                <link>https://issues.apache.org/jira/browse/MATH-206</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When running:&lt;/p&gt;

&lt;p&gt;public static void main(String[] args) {&lt;br/&gt;
        try {
            String s = &quot;0.0&quot;;
            ComplexFormat cf = new ComplexFormat();
            Complex c = cf.parse(s);
            System.out.println(&quot;c = &quot; + c);
        } catch (ParseException ex) {
            ex.printStackTrace();
        }&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;i get the following error:&lt;/p&gt;

&lt;p&gt;java.text.ParseException: Unparseable complex number: &quot;0.0&quot;&lt;br/&gt;
        at org.apache.commons.math.complex.ComplexFormat.parse(ComplexFormat.java:307)&lt;br/&gt;
        at complexformattest.Main.main(Main.java:26)&lt;/p&gt;

&lt;p&gt;With integers it works correctly but support for doubles is even more important ;] (from my point of view). I downloaded the &quot;Latest release&quot;&lt;/p&gt;

&lt;p&gt;Hope u fix it quick. I have a proposal but it affects much the code. Maybe You have some quick hint?&lt;/p&gt;</description>
                <environment>&lt;p&gt;Windows Vista + JDK 6&lt;/p&gt;</environment>
            <key id="12396454">MATH-206</key>
            <summary>ComplexFormat.parse doesn&apos;t parse a double e.g. 0.0</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="fsala">Frederick Salardi</reporter>
                        <labels>
                    </labels>
                <created>Tue, 20 May 2008 22:08:19 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:18 +0000</updated>
                    <resolved>Tue, 20 May 2008 22:15:58 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12598505" author="fsala" created="Tue, 20 May 2008 22:15:58 +0000"  >&lt;p&gt;It works with &quot;0,0&quot;.&lt;/p&gt;

&lt;p&gt;But anyway doubles in java uses a dot not a comma. &lt;/p&gt;</comment>
                    <comment id="12598523" author="sebb@apache.org" created="Tue, 20 May 2008 23:11:55 +0000"  >&lt;p&gt;Surely the decimal &quot;point&quot; depends on the Locale - it may be &quot;.&quot; or &quot;,&quot; (perhaps there are others).&lt;/p&gt;</comment>
                    <comment id="12598623" author="luc" created="Wed, 21 May 2008 11:43:30 +0000"  >&lt;p&gt;Using a no-argument constructor for ComplexFormat leads to use a default format which itself relies on the default locale as returned by Locale.getDefault(). This is a normal behavior and is the same behavior you get from parsing a single double value with functions like Double.parseDouble().&lt;/p&gt;

&lt;p&gt;Parsing non-localized strings even in localized environments can be done by supplying the format to use to ComplexFormat, for example like this:&lt;/p&gt;

&lt;p&gt;  ComplexFormat cf = new ComplexFormat(NumberFormat.getInstance(Locale.US));&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 20 May 2008 23:11:55 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-204] BrentSolver throws IllegalArgumentException </title>
                <link>https://issues.apache.org/jira/browse/MATH-204</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I am getting this exception:&lt;/p&gt;

&lt;p&gt;java.lang.IllegalArgumentException: Function values at endpoints do not have different signs.  Endpoints: &lt;span class=&quot;error&quot;&gt;&amp;#91;-100000.0,1.7976931348623157E308&amp;#93;&lt;/span&gt;  Values: &lt;span class=&quot;error&quot;&gt;&amp;#91;0.0,-101945.04630982173&amp;#93;&lt;/span&gt;&lt;br/&gt;
at org.apache.commons.math.analysis.BrentSolver.solve(BrentSolver.java:99)&lt;br/&gt;
at org.apache.commons.math.analysis.BrentSolver.solve(BrentSolver.java:62)&lt;/p&gt;

&lt;p&gt;The exception should not be thrown with values  &lt;span class=&quot;error&quot;&gt;&amp;#91;0.0,-101945.04630982173&amp;#93;&lt;/span&gt; because 0.0 is positive.&lt;br/&gt;
According to Brent Worden, the algorithm should stop and return 0 as the root instead of throwing an exception.&lt;/p&gt;

&lt;p&gt;The problem comes from this method:&lt;br/&gt;
    public double solve(double min, double max) throws MaxIterationsExceededException, &lt;br/&gt;
        FunctionEvaluationException {&lt;/p&gt;

&lt;p&gt;        clearResult();&lt;br/&gt;
        verifyInterval(min, max);&lt;/p&gt;

&lt;p&gt;        double yMin = f.value(min);&lt;br/&gt;
        double yMax = f.value(max);&lt;/p&gt;

&lt;p&gt;        // Verify bracketing&lt;br/&gt;
        if (yMin * yMax &amp;gt;= 0) {
            throw new IllegalArgumentException
            (&quot;Function values at endpoints do not have different signs.&quot; +
                    &quot;  Endpoints: [&quot; + min + &quot;,&quot; + max + &quot;]&quot; + 
                    &quot;  Values: [&quot; + yMin + &quot;,&quot; + yMax + &quot;]&quot;);       
        }&lt;/p&gt;

&lt;p&gt;        // solve using only the first endpoint as initial guess&lt;br/&gt;
        return solve(min, yMin, max, yMax, min, yMin);&lt;/p&gt;

&lt;p&gt;    }&lt;/p&gt;

&lt;p&gt;One way to fix it would be to add this code after the assignment of yMin and yMax:&lt;br/&gt;
        if (yMin ==0 || yMax == 0) {
        	return 0;
       	}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Win XP&lt;/p&gt;</environment>
            <key id="12395456">MATH-204</key>
            <summary>BrentSolver throws IllegalArgumentException </summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="brentworden">Brent Worden</assignee>
                                <reporter username="mickeydog">Mick</reporter>
                        <labels>
                    </labels>
                <created>Tue, 6 May 2008 20:33:57 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:18 +0000</updated>
                    <resolved>Wed, 7 May 2008 13:37:07 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12594906" author="brentworden" created="Wed, 7 May 2008 13:37:07 +0000"  >&lt;p&gt;SVN 654100.  added root checks for the endpoints.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 7 May 2008 13:37:07 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-201] T-test p-value precision hampered by machine epsilon</title>
                <link>https://issues.apache.org/jira/browse/MATH-201</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The smallest p-value returned by TTestImpl.tTest() is the machine epsilon, which is 2.220446E-16 with IEEE754 64-bit double precision floats.&lt;/p&gt;

&lt;p&gt;We found this bug porting some analysis software from R to java, and noticed that the p-values did not match up.  We believe we&apos;ve identified why this is happening in commons-math-1.2, and a possible solution.&lt;/p&gt;

&lt;p&gt;Please be gentle, as I am not a statistics expert!&lt;/p&gt;

&lt;p&gt;The following method in org.apache.commons.math.stat.inference.TTestImpl currently implements the following method to calculate the p-value for a 2-sided, 2-sample t-test:&lt;/p&gt;

&lt;p&gt;protected double tTest(double m1, double m2, double v1, double v2,  double n1, double n2)&lt;/p&gt;

&lt;p&gt;and it returns:&lt;/p&gt;

&lt;p&gt;        1.0 - distribution.cumulativeProbability(-t, t);&lt;/p&gt;

&lt;p&gt;at line 1034 in version 1.2.&lt;/p&gt;

&lt;p&gt;double cumulativeProbability(double x0, double x1) is implemented by org.apache.commons.math.distribution.AbstractDisstribution, and returns:&lt;/p&gt;

&lt;p&gt;        return cumulativeProbability(x1) - cumulativeProbability(x0);&lt;/p&gt;

&lt;p&gt;So in essence, the p-value returned by TTestImpl.tTest() is:&lt;/p&gt;

&lt;p&gt;1.0 - (cumulativeProbability(t) - cumulativeProbabily(-t))&lt;/p&gt;

&lt;p&gt;For large-ish t-statistics, cumulativeProbabilty(-t) can get quite small, and cumulativeProbabilty(t) can get very close to 1.0.  When cumulativeProbability(-t) is less than the machine epsilon, we get p-values equal to zero because:&lt;/p&gt;

&lt;p&gt;1.0 - 1.0 + 0.0 = 0.0&lt;/p&gt;

&lt;p&gt;An alternative calculation for the p-value of a 2-sided, 2-sample t-test is:&lt;/p&gt;

&lt;p&gt;p = 2.0 * cumulativeProbability(-t)&lt;/p&gt;

&lt;p&gt;This calculation does not suffer from the machine epsilon problem, and we are now getting p-values much smaller than the 2.2E-16 limit we were seeing previously.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12393132">MATH-201</key>
            <summary>T-test p-value precision hampered by machine epsilon</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="brentworden">Brent Worden</assignee>
                                <reporter username="pwyngaard">Peter Wyngaard</reporter>
                        <labels>
                    </labels>
                <created>Fri, 4 Apr 2008 16:31:20 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sun, 6 Apr 2008 01:24:56 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12586080" author="brentworden" created="Sun, 6 Apr 2008 01:24:56 +0000"  >&lt;p&gt;SVN 645193.&lt;/p&gt;

&lt;p&gt;Changes applied.  Thank you for reporting this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Apr 2008 01:24:56 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-200] AbstractEstimator: getCovariances() and guessParametersErrors() crash when having bound parameters</title>
                <link>https://issues.apache.org/jira/browse/MATH-200</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;the two methods getCovariances() and guessParametersErrors() from org.apache.commons.math.estimation.AbstractEstimator crash with ArrayOutOfBounds exception when some of the parameters are bound. The reason is that the Jacobian is calculated only for the unbound parameters. in the code you loop through all parameters.&lt;/p&gt;

&lt;p&gt;line #166: final int cols = problem.&lt;b&gt;getAllParameters()&lt;/b&gt;.length;&lt;br/&gt;
should be replaced by:  final int cols = problem.&lt;b&gt;getUnboundParameters()&lt;/b&gt;.length;&lt;br/&gt;
(similar changes could be done in guessParametersErrors())&lt;/p&gt;

&lt;p&gt;the dissadvantage of the above bug fix is that what is returned to the user is an array with smaller size than the number of all parameters. Alternatively, you can have some logic in the code which writes zeros for the elements of the covariance matrix corresponding to the bound parameters&lt;/p&gt;</description>
                <environment></environment>
            <key id="12392292">MATH-200</key>
            <summary>AbstractEstimator: getCovariances() and guessParametersErrors() crash when having bound parameters</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="ppv666">Plamen Petrov</reporter>
                        <labels>
                    </labels>
                <created>Tue, 25 Mar 2008 22:22:21 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Fri, 28 Mar 2008 20:11:06 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12582080" author="luc" created="Tue, 25 Mar 2008 23:33:11 +0000"  >&lt;p&gt;Since the contract on the two methods is related to the complete parameters array, only the more elaborate fix with specific logic for bound parameters is feasible.&lt;/p&gt;

&lt;p&gt;I agree this is a critical error. I will try to provide a fix in the next few days.&lt;/p&gt;

&lt;p&gt;Thanks for reporting this.&lt;/p&gt;</comment>
                    <comment id="12582160" author="ppv666" created="Wed, 26 Mar 2008 07:37:26 +0000"  >&lt;p&gt;Thanks a lot for your quick response!&lt;br/&gt;
Best wishes,&lt;br/&gt;
Plamen&lt;/p&gt;

</comment>
                    <comment id="12583174" author="luc" created="Fri, 28 Mar 2008 20:11:06 +0000"  >&lt;p&gt;I finally changed my mind and limited the results of both methods to unbound parameters only.&lt;br/&gt;
This is more compliant with what user can expect when they bind parameters (a problem with bound parameters should behave exactly as if these parameters were simply constants).&lt;br/&gt;
The previous javadoc was not clear about this and the methods did not work at all in this case, so such a change seems wiser to me.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 25 Mar 2008 23:33:11 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-199] exception in LevenbergMarquardtEstimator</title>
                <link>https://issues.apache.org/jira/browse/MATH-199</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I get this exception:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.ArrayIndexOutOfBoundsException: -1&lt;br/&gt;
       at org.apache.commons.math.estimation.LevenbergMarquardtEstimator.qrDecomposition(LevenbergMarquardtEstimator.java:772)&lt;br/&gt;
       at org.apache.commons.math.estimation.LevenbergMarquardtEstimator.estimate(LevenbergMarquardtEstimator.java:232)&lt;br/&gt;
       at quadraticFitterProblem.QuadraticFitterProblem.&amp;lt;init&amp;gt;(QuadraticFitterProblem.java:27)&lt;br/&gt;
       at quadraticFitterProblem.QuadraticFitterProblem.main(QuadraticFitterProblem.java:40)&lt;br/&gt;
on the code below.&lt;/p&gt;

&lt;p&gt;The exception does not occur all the weights in the quadraticFitter are 0.0;&lt;/p&gt;


&lt;p&gt;---------------------------------------------------------------------------------------------&lt;/p&gt;

&lt;p&gt;package quadraticFitterProblem;&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.estimation.EstimationException;&lt;br/&gt;
import org.apache.commons.math.estimation.LevenbergMarquardtEstimator;&lt;br/&gt;
//import org.apache.commons.math.estimation.WeightedMeasurement;&lt;/p&gt;

&lt;p&gt;import com.strategicanalytics.dtd.data.smoothers.QuadraticFitter;&lt;/p&gt;

&lt;p&gt;public class QuadraticFitterProblem {&lt;/p&gt;

&lt;p&gt;       private QuadraticFitter quadraticFitter;&lt;/p&gt;

&lt;p&gt;       public QuadraticFitterProblem() {&lt;br/&gt;
         // create the uninitialized fitting problem&lt;br/&gt;
         quadraticFitter = new QuadraticFitter();&lt;/p&gt;

&lt;p&gt;         quadraticFitter.addPoint (0,  -3.182591015485607, 0.0);&lt;br/&gt;
         quadraticFitter.addPoint (1,  -2.5581184967730577, 4.4E-323);&lt;br/&gt;
         quadraticFitter.addPoint (2,  -2.1488478161387325, 1.0);&lt;br/&gt;
         quadraticFitter.addPoint (3,  -1.9122489313410047, 4.4E-323);&lt;br/&gt;
         quadraticFitter.addPoint (4,  1.7785661310051026, 0.0);&lt;/p&gt;

&lt;p&gt;         try {
           // solve the problem, using a Levenberg-Marquardt algorithm with
default settings
           LevenbergMarquardtEstimator estimator = new LevenbergMarquardtEstimator();
           //WeightedMeasurement[] wm = quadraticFitter.getMeasurements();
           estimator.estimate(quadraticFitter);

         } catch (EstimationException ee) {
               System.err.println(ee.getMessage());
         }&lt;br/&gt;
       }&lt;/p&gt;

&lt;p&gt;       /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;@param args&lt;br/&gt;
        *&lt;br/&gt;
        */&lt;br/&gt;
       public static void main(String[] args) {

                       new QuadraticFitterProblem();
                       System.out.println (&quot;Done.&quot;);
       }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;}&lt;/p&gt;

&lt;p&gt;----------------------------------------------------------------------------------------------&lt;br/&gt;
import org.apache.commons.math.estimation.EstimatedParameter;&lt;br/&gt;
//import org.apache.commons.math.estimation.EstimationException;&lt;br/&gt;
//import org.apache.commons.math.estimation.LevenbergMarquardtEstimator;&lt;br/&gt;
import org.apache.commons.math.estimation.SimpleEstimationProblem;&lt;br/&gt;
import org.apache.commons.math.estimation.WeightedMeasurement;&lt;/p&gt;

&lt;p&gt;public class QuadraticFitter extends SimpleEstimationProblem {&lt;/p&gt;

&lt;p&gt;       // y = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;br/&gt;
   private EstimatedParameter a;&lt;br/&gt;
   private EstimatedParameter b;&lt;br/&gt;
   private EstimatedParameter c;&lt;/p&gt;

&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;constructor&lt;br/&gt;
    *&lt;br/&gt;
    *Fitter for a quadratic model to a sample of 2D points.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;The model is y&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;/li&gt;
	&lt;li&gt;its three parameters of the model are a, b and c.&amp;lt;/p&amp;gt;&lt;br/&gt;
    */&lt;br/&gt;
   public QuadraticFitter() {

       // three parameters of the model
       a = new EstimatedParameter(&quot;a&quot;, 0.0);
       b = new EstimatedParameter(&quot;b&quot;, 0.0);
       c = new EstimatedParameter(&quot;c&quot;, 0.0);

       // provide the parameters to the base class which
       // implements the getAllParameters and getUnboundParameters methods
       addParameter(a);
       addParameter(b);
       addParameter(c);
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Add a sample point&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@param x abscissa&lt;/li&gt;
	&lt;li&gt;@param y ordinate&lt;/li&gt;
	&lt;li&gt;@param w weight&lt;br/&gt;
    */&lt;br/&gt;
   public void addPoint(double x, double y, double w) {
       addMeasurement(new LocalMeasurement(x, y, w));
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Get the value of the quadratic coefficient.&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@return the value of a for the quadratic model&lt;/li&gt;
	&lt;li&gt;y = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;br/&gt;
    */&lt;br/&gt;
   public double getA() {
       return a.getEstimate();
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Get the value of the linear coefficient.&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@return the value of b for the quadratic model&lt;/li&gt;
	&lt;li&gt;y = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;br/&gt;
    */&lt;br/&gt;
   public double getB() {
       return b.getEstimate();
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Get the value of the constant coefficient.&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@return the value of ac for the quadratic model&lt;/li&gt;
	&lt;li&gt;y = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;br/&gt;
    */&lt;br/&gt;
   public double getC() {
       return c.getEstimate();
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Get the theoretical value of the model for some x.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;The theoretical value is the value computed using&lt;/li&gt;
	&lt;li&gt;the current state of the problem parameters.&amp;lt;/p&amp;gt;&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;Note the use of H&#246;rner&apos;s method (synthetic division) for&lt;br/&gt;
evaluating polynomials,&lt;/li&gt;
	&lt;li&gt;(more efficient)&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@param x explanatory variable&lt;/li&gt;
	&lt;li&gt;@return the theoretical value y = a x&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; + b x + c&lt;br/&gt;
    */&lt;br/&gt;
   public double theoreticalValue(double x) {
       //System.out.println (&quot;x = &quot; + x + &quot;  a.getEstimate() = &quot; +
a.getEstimate() + &quot;  b.getEstimate() = &quot; + b.getEstimate() + &quot;
c.getEstimate() = &quot; + c.getEstimate());
       return ( (a.getEstimate() * x + b.getEstimate() ) * x +
c.getEstimate());
   }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Get the partial derivative of the theoretical value&lt;/li&gt;
	&lt;li&gt;of the model for some x.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;The derivative is computed using&lt;/li&gt;
	&lt;li&gt;the current state of the problem parameters.&amp;lt;/p&amp;gt;&lt;br/&gt;
    *&lt;/li&gt;
	&lt;li&gt;@param x explanatory variable&lt;/li&gt;
	&lt;li&gt;@param parameter estimated parameter (either a, b, or c)&lt;/li&gt;
	&lt;li&gt;@return the partial derivative dy/dp&lt;br/&gt;
    */&lt;br/&gt;
   private double partial(double x, EstimatedParameter parameter) {&lt;br/&gt;
       // since we know the only parameters are a, b and c in this&lt;br/&gt;
       // class we simply use &quot;==&quot; for efficiency&lt;br/&gt;
       if (parameter == a) {
           return x * x;
       } else if (parameter == b) {
           return x;
       } else {
           return 1.0;
       }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   }&lt;/p&gt;


&lt;p&gt;   /** Internal measurements class.&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;The measurement is the y value for a fixed specified x.&amp;lt;/p&amp;gt;&lt;br/&gt;
    */&lt;br/&gt;
   private class LocalMeasurement extends WeightedMeasurement {&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;       static final long serialVersionUID = 1;&lt;/p&gt;

&lt;p&gt;       private final double x;&lt;/p&gt;

&lt;p&gt;       // constructor&lt;br/&gt;
       public LocalMeasurement(double x, double y, double w) {
           super(w, y);
           this.x = x;
       }&lt;/p&gt;

&lt;p&gt;       public double getTheoreticalValue() {
           // the value is provided by the model for the local x
           return theoreticalValue(x);
       }&lt;/p&gt;

&lt;p&gt;       public double getPartial(EstimatedParameter parameter) {
           // the value is provided by the model for the local x
           return partial(x, parameter);
       }&lt;/p&gt;

&lt;p&gt;   }&lt;/p&gt;

&lt;p&gt; }&lt;/p&gt;</description>
                <environment>&lt;p&gt;Windows XP&lt;br/&gt;
Java 6&lt;/p&gt;</environment>
            <key id="12392015">MATH-199</key>
            <summary>exception in LevenbergMarquardtEstimator</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mickeydog">Mick</reporter>
                        <labels>
                    </labels>
                <created>Thu, 20 Mar 2008 22:56:33 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sun, 23 Mar 2008 13:40:12 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12581383" author="luc" created="Sun, 23 Mar 2008 13:40:12 +0000"  >&lt;p&gt;Fixed in svn as of r640205&lt;/p&gt;

&lt;p&gt;The problem was due to an overflow in Q.R decomposition. One of  the transformed columns had both infinite and NaN elements, so the test of the norm was never met and a column index was never set.&lt;/p&gt;

&lt;p&gt;The fix consist in detecting non-numeric norms and throwing an EstimationException stating the Q.R decomposition could not be performed.&lt;/p&gt;</comment>
                    <comment id="12581536" author="mickeydog" created="Mon, 24 Mar 2008 13:56:34 +0000"  >&lt;p&gt;Is it accurate to say that the problem is caused by the 4.4E-323 in the error term?&lt;br/&gt;
(ie, the 4.4E-323 causes one of the transformed columns to have values of Infinity or NaN?&lt;/p&gt;

&lt;p&gt;If I eliminate those error terms, e.g.:&lt;br/&gt;
	  quadraticFitter.addPoint (0,  -3.182591015485607, 0.0);&lt;br/&gt;
	  quadraticFitter.addPoint (1,  -2.5581184967730577, 0.5);&lt;br/&gt;
	  quadraticFitter.addPoint (2,  -2.1488478161387325, 1.0);&lt;br/&gt;
	  quadraticFitter.addPoint (3,  -1.9122489313410047, 0.5);&lt;br/&gt;
	  quadraticFitter.addPoint (4,  1.7785661310051026, 0.0);&lt;br/&gt;
then, indeed, the error does not occur.&lt;/p&gt;

&lt;p&gt;I have a concern that, while it is true that  4.4E-323 is a number of extremely small magnitude, it is a vaild double, but using it causes an exception.&lt;br/&gt;
:Perhaps I am not seeing this correctly.&lt;/p&gt;
</comment>
                    <comment id="12581558" author="luc" created="Mon, 24 Mar 2008 15:09:08 +0000"  >&lt;p&gt;Yes, this is this small value that triggers the error. It is a valid number but during the Q.R decomposition, this number is used in several operations. One of these operations lead to an overflow.&lt;/p&gt;

&lt;p&gt;At line 785 of LevenbergMarquardt.java, we compute :  double betak = 1.0 / (ak2 - akk * alpha)&lt;/p&gt;

&lt;p&gt;With the very small values of the example, the value for betak overflows while processing the second column (first column is computed without problem). The denominator ak2 - akk * alpha has a value of 1.43e-322 which can be handled by double. It&apos;s inverse is 6.9e321, far larger than the Double.MAX_VALUE which is about 1.8e+308. The result of the computation is that betak is set to positive infinity. The rest of the computation behaves badly with such a value. Some of the elements of third column are set to infinity, others are set to NaN.&lt;/p&gt;

&lt;p&gt;The fact is that despite many representable double number have a representable inverse in IEE754, it is not true for all.&lt;/p&gt;</comment>
                    <comment id="12581577" author="mickeydog" created="Mon, 24 Mar 2008 15:57:00 +0000"  >&lt;p&gt;That being the case, could the commons math library define a constant such that its inverse it  equal to Double.MAX_VALUE?&lt;br/&gt;
I could then use this as a limit.&lt;/p&gt;</comment>
                    <comment id="12581590" author="luc" created="Mon, 24 Mar 2008 16:29:26 +0000"  >&lt;p&gt;Numbers that behave well are &quot;normal numbers&quot; as defined by IEEE754. Numbers to avoid in your case are &quot;subnormal numbers&quot;. You can use Double.MIN_NORMAL if you use Java 6, or simply 4 / Double.MAX_VALUE (which is almost but not exactly the same value) if you use an earlier version of Java.&lt;/p&gt;

&lt;p&gt;Beware that this may not be enough because you can test only the numbers you put in the method, not the intermediate values computed within it. For example the ak2, akk and alpha values are not available in the statement above, and betak is available only on output.&lt;/p&gt;

&lt;p&gt;I&apos;m not sure such constants have a place in &lt;span class=&quot;error&quot;&gt;&amp;#91;math&amp;#93;&lt;/span&gt;, but this is only a personal opinion.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 23 Mar 2008 13:40:12 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-198] java.lang.StringIndexOutOfBoundsException in ComplexFormat.parse(String source, ParsePosition pos)</title>
                <link>https://issues.apache.org/jira/browse/MATH-198</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The parse(String source, ParsePosition pos) method in the ComplexFormat class does not check whether the imaginary character is set or not which produces StringIndexOutOfBoundsException in the substring method :&lt;/p&gt;

&lt;p&gt;(line 375 of ComplexFormat)&lt;br/&gt;
...&lt;br/&gt;
        // parse imaginary character&lt;br/&gt;
        int n = getImaginaryCharacter().length();&lt;/p&gt;

&lt;p&gt;        startIndex = pos.getIndex();&lt;br/&gt;
        int endIndex = startIndex + n;&lt;br/&gt;
        if (source.substring(startIndex, endIndex).compareTo(&lt;br/&gt;
            getImaginaryCharacter()) != 0) {&lt;br/&gt;
...&lt;br/&gt;
I encoutered this exception typing in a JTextFied with ComplexFormat set to look up an AbstractFormatter.&lt;br/&gt;
If only the user types the imaginary part of the complex number first, he gets this exception.&lt;/p&gt;

&lt;p&gt;Solution: Before setting to n length of the imaginary character, check if the source contains it. My proposal:&lt;br/&gt;
...&lt;br/&gt;
        int n = 0;&lt;br/&gt;
        if (source.contains(getImaginaryCharacter()))&lt;br/&gt;
        n = getImaginaryCharacter().length();&lt;br/&gt;
...		 &lt;/p&gt;

&lt;p&gt;F.S.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Ubuntu 7.10, JDK 6.0, PC&lt;/p&gt;</environment>
            <key id="12391806">MATH-198</key>
            <summary>java.lang.StringIndexOutOfBoundsException in ComplexFormat.parse(String source, ParsePosition pos)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="fsala">Frederick Salardi</reporter>
                        <labels>
                    </labels>
                <created>Tue, 18 Mar 2008 23:06:45 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sun, 23 Mar 2008 12:23:59 +0000</resolved>
                            <version>1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12581374" author="luc" created="Sun, 23 Mar 2008 12:23:59 +0000"  >&lt;p&gt;Fixed in svn as of r 640191.&lt;/p&gt;

&lt;p&gt;The adopted fixed is different from the proposed one, it simply checks the length of the string with respect to the expected position of the imaginary character&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 23 Mar 2008 12:23:59 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-197] RandomDataImpl.nextPoisson() is extreme slow for large lambdas</title>
                <link>https://issues.apache.org/jira/browse/MATH-197</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The RandomDataImpl.nextPoisson() is extreme slow for large lambdas:&lt;/p&gt;

&lt;p&gt;E.g. drawing 100 random numbers with lambda = 1000 takes around 10s on my dual core with 2.2GHz.&lt;br/&gt;
With lambda smaller than 500 everything is fine. Any ideas?&lt;/p&gt;

&lt;p&gt;    RandomDataImpl r = new RandomDataImpl();&lt;br/&gt;
    r.reSeed(101);&lt;/p&gt;

&lt;p&gt;    int d = 100;&lt;br/&gt;
    long poissonLambda = 1000;&lt;/p&gt;

&lt;p&gt;    long st = System.currentTimeMillis();&lt;br/&gt;
    for (int row = 0; row &amp;lt; d; row++) {
      long nxtRnd = r.nextPoisson(poissonLambda);
    }&lt;br/&gt;
    System.out.println(&quot;delta &quot; + (System.currentTimeMillis() - st));&lt;/p&gt;</description>
                <environment>&lt;p&gt;jdk1.6.0_04, windows xp&lt;/p&gt;</environment>
            <key id="12391611">MATH-197</key>
            <summary>RandomDataImpl.nextPoisson() is extreme slow for large lambdas</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="brentworden">Brent Worden</assignee>
                                <reporter username="zubow">Tolja Zubow</reporter>
                        <labels>
                    </labels>
                <created>Mon, 17 Mar 2008 11:55:26 +0000</created>
                <updated>Fri, 7 Aug 2009 09:19:48 +0000</updated>
                    <resolved>Sun, 21 Jun 2009 15:10:50 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                <version>1.2</version>
                                <fixVersion>2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12581371" author="luc" created="Sun, 23 Mar 2008 11:11:48 +0000"  >&lt;p&gt;The problems comes from the way the distribution is computed. A Poisson process is simulated and lots of random numbers are drawn, until there product reach some threshold.&lt;br/&gt;
If lambda is greater or equal to 746, the value of Math.exp(-lambda) cannot be represented anymore in a double and it is replaced by 0 (exactly 0). The previous value, for lambda = 745 is 4.9e-324, which is ... small.&lt;br/&gt;
In this case, the threshold is never reached and the loop is exited only because of an exceeded count.&lt;br/&gt;
This means that in addition to being long to obtain, the result is false (it will be exactly 1000 * lambda).&lt;/p&gt;

&lt;p&gt;So the current algorithm cannot handle large lambda values.&lt;/p&gt;

&lt;p&gt;Does anybody have a reference for another algorithm that could be used for large lambda values ?&lt;/p&gt;</comment>
                    <comment id="12581576" author="brentworden" created="Mon, 24 Mar 2008 15:55:44 +0000"  >&lt;p&gt;I&apos;ve been looking at  Devroye&apos;s &apos;Non-Uniform Random Variate Generation&apos; book.  The book is freely available at &lt;a href=&quot;http://cg.scs.carleton.ca/~luc/rnbookindex.html&quot;&gt;http://cg.scs.carleton.ca/~luc/rnbookindex.html&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Chapter 10 defines some rejection methods for Poisson generation which, the author claims, are uniformily fast for all lambda.&lt;/p&gt;

&lt;p&gt;I hope to soon implement one or more of the rejection methods and test its performance.&lt;/p&gt;</comment>
                    <comment id="12722346" author="jkff" created="Sun, 21 Jun 2009 12:04:28 +0000"  >&lt;p&gt;I have had a look at the source and it looks like the method is already implemented, so the bug should probably be closed?&lt;/p&gt;</comment>
                    <comment id="12722366" author="psteitz" created="Sun, 21 Jun 2009 15:10:50 +0000"  >&lt;p&gt;Fix was committed in r762194 by brentworden&lt;/p&gt;</comment>
                    <comment id="12740476" author="luc" created="Fri, 7 Aug 2009 09:19:48 +0000"  >&lt;p&gt;closing resolved issue for 2.0 release&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 23 Mar 2008 11:11:48 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-191] SummaryStatistics computes sum of logs but does not provide access to it</title>
                <link>https://issues.apache.org/jira/browse/MATH-191</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;A SumOfLogs instances is maintained and incremented by SummaryStatistics, but there is no getSumOfLogs method to report the value of this statistic.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12388270">MATH-191</key>
            <summary>SummaryStatistics computes sum of logs but does not provide access to it</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="psteitz">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sat, 9 Feb 2008 16:23:08 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sat, 9 Feb 2008 23:43:24 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12567379" author="psteitz" created="Sat, 9 Feb 2008 23:43:24 +0000"  >&lt;p&gt;Fixed in r 620221.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-190] Incorrect SVN properties for some files</title>
                <link>https://issues.apache.org/jira/browse/MATH-190</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;There seem to be a few incorrect SVN properties in SVN trunk; following is a list of SVN commands that can be used to fix them:&lt;/p&gt;

&lt;p&gt;These should be done on whatever OS was used to create the files, probably Unix, otherwise there may be problems:&lt;/p&gt;

&lt;p&gt;svn ps svn:eol-style native src/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java&lt;br/&gt;
svn ps svn:eol-style native src/java/org/apache/commons/math/stat/inference/OneWayAnova.java&lt;br/&gt;
svn ps svn:eol-style native src/java/org/apache/commons/math/stat/inference/OneWayAnovaImpl.java&lt;br/&gt;
svn ps svn:eol-style native src/test/org/apache/commons/math/stat/inference/OneWayAnovaTest.java&lt;/p&gt;

&lt;p&gt;These files should not be executable &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; - can be done on any OS:&lt;/p&gt;

&lt;p&gt;svn pd svn:executable src/java/org/apache/commons/math/transform/package.html&lt;br/&gt;
svn pd svn:executable src/mantissa/src/org/spaceroots/mantissa/algebra/Chebyshev.java&lt;br/&gt;
svn pd svn:executable src/mantissa/src/org/spaceroots/mantissa/algebra/Hermite.java&lt;br/&gt;
svn pd svn:executable src/mantissa/src/org/spaceroots/mantissa/algebra/Legendre.java&lt;br/&gt;
svn pd svn:executable src/mantissa/src/org/spaceroots/mantissa/algebra/Polynomial.java&lt;br/&gt;
svn pd svn:executable src/mantissa/src/org/spaceroots/mantissa/algebra/PolynomialFraction.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/ChebyshevTest.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/HermiteTest.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/LegendreTest.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/PolynomialDoubleTest.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/PolynomialFractionTest.java&lt;br/&gt;
svn pd svn:executable src/mantissa/tests-src/org/spaceroots/mantissa/algebra/PolynomialRationalTest.java&lt;/p&gt;</description>
                <environment></environment>
            <key id="12387809">MATH-190</key>
            <summary>Incorrect SVN properties for some files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Mon, 4 Feb 2008 19:00:45 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Mon, 4 Feb 2008 20:30:58 +0000</resolved>
                                            <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12565511" author="luc" created="Mon, 4 Feb 2008 20:30:58 +0000"  >&lt;p&gt;fixed&lt;br/&gt;
thanks for both the issue and the commands &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 4 Feb 2008 20:30:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-187] MatrixUtils - are these supposed to have a public or package scope constructor?</title>
                <link>https://issues.apache.org/jira/browse/MATH-187</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Package or public?&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/**
     * Default constructor.  Package scope to prevent unwanted instantiation. 
     */
    &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; MatrixUtils() {
        &lt;span class=&quot;code-keyword&quot;&gt;super&lt;/span&gt;();
    }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="12387756">MATH-187</key>
            <summary>MatrixUtils - are these supposed to have a public or package scope constructor?</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Mon, 4 Feb 2008 01:40:45 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sun, 10 Feb 2008 21:11:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12565268" author="psteitz" created="Mon, 4 Feb 2008 04:47:56 +0000"  >&lt;p&gt;The comment is wrong.  The constructor is public and needs to stay that way, though at this point we could deprecate it.&lt;/p&gt;</comment>
                    <comment id="12567475" author="psteitz" created="Sun, 10 Feb 2008 21:11:01 +0000"  >&lt;p&gt;Fixed in r 620330.&lt;br/&gt;
Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 4 Feb 2008 04:47:56 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-186] test results depend on java version</title>
                <link>https://issues.apache.org/jira/browse/MATH-186</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Running the tests with maven and changing the java version used by changing JAVA_HOME in the ~/.mavenrc file, I get different results.&lt;/p&gt;

&lt;p&gt;With the Eclipse compiler set to 1.3 compatibility and with blackdown jvm (1.4), the tests succed.&lt;br/&gt;
With the Sun jvm (1.6), SummaryStatisticsAbstractTest.testEqualsAndHashCode (which is used both by SummaryStatisticsTest and SynchronizedSummaryStatisticsTest) fails.&lt;/p&gt;

&lt;p&gt;The error is related to geometric mean computation, which lead to slightly different results depending on the order of added elements. One instance returns 2.213363839400643 and the other returns 2.2133638394006434. Both results are consistent with IEEE754 arithmetic (they differ in the last two bits).&lt;/p&gt;

&lt;p&gt;Using Sun 1.6.0_03 jvm, the different values induce a test failure when SummaryStatistics.equals() method is called (it checks for exact equality). If this part of the test is commented out, another failure occurs when the SummaryStatistics.hashcode() method is called.&lt;/p&gt;

&lt;p&gt;Changing the equals method would be possible, but would be a change of semantics and would imply choosing some threshold which would never suit everybody needs. Changing the hashcode method simply does not seem realistic to me. So I would like to keep these methods as they are now. So the main conclusion would be that the test is too sensitive to jvm implementation (which are consistent with IEEE754 arithmetic in this case).&lt;/p&gt;

&lt;p&gt;I don&apos;t know what to do about this issue.&lt;/p&gt;</description>
                <environment>&lt;p&gt;GNU/Linux (ubuntu Gutsy Gibbon),  java 1.3: eclipse compiler, java 1.4: Blackdown-1.4.2-02, java 1.6:  SUN 1.6.0_03-b05,  AMD athlon XP2000+&lt;/p&gt;</environment>
            <key id="12387752">MATH-186</key>
            <summary>test results depend on java version</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Sun, 3 Feb 2008 22:31:21 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sun, 3 Feb 2008 22:47:32 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12565231" author="psteitz" created="Sun, 3 Feb 2008 22:44:06 +0000"  >&lt;p&gt;I think the test should be modified to add data in the same order in each case, which will ensure equals semantics works.  The assumption that arithmetic operations are commutative is not true and the test in its current form depends on that.&lt;/p&gt;</comment>
                    <comment id="12565232" author="luc" created="Sun, 3 Feb 2008 22:47:32 +0000"  >&lt;p&gt;Changed slightly the test to be less sensitive to JVM issues.&lt;br/&gt;
The change was simply to add the points in a different order. So instead of having one instance handling values 2, 1, 3, 4 and the other handling values 4, 2, 3, 1, the second instance now handles 2, 3, 1, 4.&lt;br/&gt;
It works, but it is definitely not a clean solution. The problem may happen again with other jvm implementations.&lt;/p&gt;</comment>
                    <comment id="12565234" author="luc" created="Sun, 3 Feb 2008 22:53:28 +0000"  >&lt;p&gt;Sorry Phil, I did not see your proposal before sending my last comment.&lt;br/&gt;
You are right, I will commit a new fix for this using exactly the same order (2, 1, 3, 4) for both instances. This is a real solution, not a dirty trick like mine.&lt;br/&gt;
Thanks&lt;/p&gt;</comment>
                    <comment id="12565235" author="psteitz" created="Sun, 3 Feb 2008 22:54:45 +0000"  >&lt;p&gt;For this to happen with other JVM impls with the change just made, the jvm would have to produce different results for the exact same computations, which would be odd.  Equals is strictly defined for this class, which I think is OK and the test is really supposed to just be testing equals and hashcode.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 3 Feb 2008 22:44:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-185] using an empty file to ValueServer in REPLAY_MODE triggers a NULL_POINTER_EXCEPTION</title>
                <link>https://issues.apache.org/jira/browse/MATH-185</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;when the URL provided to ValueServer.setValuesFileURL() contains no data,&lt;br/&gt;
subsequent calls to ValueServer.getNext() in replay mode triggers an exception at the&lt;br/&gt;
end of the private method getNextReplay.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12387712">MATH-185</key>
            <summary>using an empty file to ValueServer in REPLAY_MODE triggers a NULL_POINTER_EXCEPTION</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Sat, 2 Feb 2008 17:57:05 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:17 +0000</updated>
                    <resolved>Sat, 2 Feb 2008 18:02:08 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12565095" author="luc" created="Sat, 2 Feb 2008 18:02:08 +0000"  >&lt;p&gt;fixed as of r617850&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-184] cumulativeProbability((double)n, (double)n) returns 0 for integer distributions</title>
                <link>https://issues.apache.org/jira/browse/MATH-184</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;cumulativeProbability((double)n, (double)n) returns 0 for&lt;br/&gt;
discrete/integer distributions&lt;/p&gt;

&lt;p&gt;I suppose AbstractIntegerDistribution.cumulativeProbability(double,&lt;br/&gt;
double) should be overridden to call its (int, int) version instead of&lt;br/&gt;
using default one from AbstractDistribution&lt;/p&gt;</description>
                <environment></environment>
            <key id="12387678">MATH-184</key>
            <summary>cumulativeProbability((double)n, (double)n) returns 0 for integer distributions</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="yegor">Yegor Bryukhov</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Feb 2008 22:17:45 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:16 +0000</updated>
                    <resolved>Mon, 11 Feb 2008 01:05:28 +0000</resolved>
                            <version>1.1</version>
                <version>1.2</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12567497" author="psteitz" created="Mon, 11 Feb 2008 01:05:28 +0000"  >&lt;p&gt;Fixed in r 620368.&lt;br/&gt;
Thanks for reporting this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 11 Feb 2008 01:05:28 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-183] Findbugs Report</title>
                <link>https://issues.apache.org/jira/browse/MATH-183</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attachment (to follow) is a summary of a Findbugs run.&lt;/p&gt;

&lt;p&gt;It&apos;s possible that the use of == for comparing floats is intended; if so perhaps it should be commented.&lt;/p&gt;

&lt;p&gt;I think all the other bug reports are valid, though of course the ones relating to the exposure of internal implementation may be ignored&lt;/p&gt;</description>
                <environment></environment>
            <key id="12387636">MATH-183</key>
            <summary>Findbugs Report</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Feb 2008 14:25:43 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:16 +0000</updated>
                    <resolved>Sun, 3 Feb 2008 21:41:36 +0000</resolved>
                                            <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12564777" author="sebb@apache.org" created="Fri, 1 Feb 2008 14:27:15 +0000"  >&lt;p&gt;CSV file summarising Findbugs report&lt;/p&gt;</comment>
                    <comment id="12564978" author="luc" created="Fri, 1 Feb 2008 23:43:01 +0000"  >&lt;p&gt;The first two warnings about the non final TOO_SMALL fields have been discussed on the list (see &lt;a href=&quot;http://markmail.org/message/tnxlul6qfjzs3mr3&quot;&gt;http://markmail.org/message/tnxlul6qfjzs3mr3&lt;/a&gt;). Phil proposed to comment this in the release notes.&lt;/p&gt;

&lt;p&gt;The next four floating point equality warnings and the last four internal representation exposed are intentional. They are identified in a commented findbugs exclusion filter in the subversion tree (file findbugs-exclude-filter.xml added about three weeks ago). This filter is active when findbugs report is created from maven2 (see plugin configuration in pom.xml).&lt;/p&gt;

&lt;p&gt;The null pointer possible dereference was also discussed here (see &lt;a href=&quot;http://markmail.org/message/33jpeig4qjmvtvy7&quot;&gt;http://markmail.org/message/33jpeig4qjmvtvy7&lt;/a&gt;). I forgot to check after Phil answered. I&apos;ll do it.&lt;/p&gt;

&lt;p&gt;I&apos;ll fix the static inner class in Frequency if possible without breaking compatibility.&lt;/p&gt;

&lt;p&gt;I understand the concerns about synchronisation, but would prefer someone else check them also.&lt;/p&gt;

&lt;p&gt;As a summary, only the first two warnings should remain at the end.&lt;br/&gt;
Thanks for the report.&lt;/p&gt;</comment>
                    <comment id="12564982" author="sebb@apache.org" created="Fri, 1 Feb 2008 23:56:48 +0000"  >&lt;p&gt;OK.&lt;/p&gt;

&lt;p&gt;However, I suggest that the floating point equality tests should be commented in the actual code, as it&apos;s an unusual idiom.&lt;/p&gt;

&lt;p&gt;As to synchronisation, it depends partly on whether the Math classes are intended to be thread-safe or not.&lt;/p&gt;</comment>
                    <comment id="12565203" author="luc" created="Sun, 3 Feb 2008 19:15:15 +0000"  >&lt;p&gt;I have looked again at the synchronisation issues.&lt;br/&gt;
The one in ResizableDoubleArray was straightforward and fixed.&lt;br/&gt;
The ones in SummaryStatistics are more difficult. They are due to the various setters and getters for implementations (set*Impl and get*Impl) which are synchronized, whereas other methods using these implementations are not synchronized.  In fact, there are more issues than the two appearing in the report: if we fix these two, a bunch of other problems appear, which should also be fixed. At the end, almost all methods end up being synchronized. This seems not to be the objective of this class but rather the objective of the SynchronizedSummaryStatistics.&lt;br/&gt;
So I would suggest moving the synchronization on the setters/getters from the SummaryStatistics class to the SynchronizedSummaryStatistics. derived class.&lt;br/&gt;
What do you think ?&lt;/p&gt;</comment>
                    <comment id="12565206" author="sebb@apache.org" created="Sun, 3 Feb 2008 19:44:14 +0000"  >&lt;p&gt;Yes, making SynchronizedSummaryStatistics fully sync, and removing synch from SummaryStatistics seems like a good idea, as the latter class is neither one thing nor the other.&lt;/p&gt;</comment>
                    <comment id="12565208" author="psteitz" created="Sun, 3 Feb 2008 19:55:12 +0000"  >&lt;p&gt;I agree that moving synch to the synch classes is better.&lt;/p&gt;</comment>
                    <comment id="12565229" author="luc" created="Sun, 3 Feb 2008 21:41:36 +0000"  >&lt;p&gt;synchronized setters/getters have been moved to SynchronizedSummaryStatistics class as of r618097&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12374555" name="MathFindbugs.csv" size="3290" author="sebb@apache.org" created="Fri, 1 Feb 2008 14:27:10 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 1 Feb 2008 23:43:01 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-182] converting some double numbers to Fraction can lead to integer overflows</title>
                <link>https://issues.apache.org/jira/browse/MATH-182</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;converting 0.75000000001455192 leads to an overflow at the third iteration&lt;br/&gt;
 converting 1.0e10 leads to an overflow before the loop (while computiong a0)&lt;/p&gt;</description>
                <environment>&lt;p&gt;GNU/Linux, Sun Java 1.6&lt;/p&gt;</environment>
            <key id="12387627">MATH-182</key>
            <summary>converting some double numbers to Fraction can lead to integer overflows</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="luc">Luc Maisonobe</assignee>
                                <reporter username="luc">Luc Maisonobe</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Feb 2008 11:59:39 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:16 +0000</updated>
                    <resolved>Fri, 1 Feb 2008 12:03:18 +0000</resolved>
                            <version>1.2</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12564729" author="luc" created="Fri, 1 Feb 2008 12:03:18 +0000"  >&lt;p&gt;fixed as of r617482&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                                            <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-175] chiSquare(double[] expected, long[] observed) is returning incorrect test statistic</title>
                <link>https://issues.apache.org/jira/browse/MATH-175</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;ChiSquareTestImpl is returning incorrect chi-squared value. An implicit assumption of public double chiSquare(double[] expected, long[] observed) is that the sum of expected and observed are equal. That is, in the code:&lt;br/&gt;
for (int i = 0; i &amp;lt; observed.length; i++) {
            dev = ((double) observed[i] - expected[i]);
            sumSq += dev * dev / expected[i];
        }&lt;br/&gt;
this calculation is only correct if sum(observed)==sum(expected). When they are not equal then one must rescale the expected value by sum(observed) / sum(expected) so that they are.&lt;br/&gt;
Ironically, it is an example in the unit test ChiSquareTestTest that highlights the error:&lt;/p&gt;

&lt;p&gt;long[] observed1 = { 500, 623, 72, 70, 31 };&lt;br/&gt;
        double[] expected1 = { 485, 541, 82, 61, 37 };&lt;br/&gt;
        assertEquals( &quot;chi-square test statistic&quot;, 16.4131070362, testStatistic.chiSquare(expected1, observed1), 1E-10);&lt;br/&gt;
        assertEquals(&quot;chi-square p-value&quot;, 0.002512096, testStatistic.chiSquareTest(expected1, observed1), 1E-9);&lt;/p&gt;

&lt;p&gt;16.413 is not correct because the expected values do not make sense, they should be: 521.19403 581.37313  88.11940  65.55224  39.76119 so that the sum of expected equals 1296 which is the sum of observed.&lt;/p&gt;

&lt;p&gt;Here is some R code (r-project.org) which proves it:&lt;br/&gt;
&amp;gt; o1&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; 500 623  72  70  31&lt;br/&gt;
&amp;gt; e1&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; 485 541  82  61  37&lt;br/&gt;
&amp;gt; chisq.test(o1,p=e1,rescale.p=TRUE)&lt;/p&gt;

&lt;p&gt;        Chi-squared test for given probabilities&lt;/p&gt;

&lt;p&gt;data:  o1 &lt;br/&gt;
X-squared = 9.0233, df = 4, p-value = 0.06052&lt;/p&gt;

&lt;p&gt;&amp;gt; chisq.test(o1,p=e1,rescale.p=TRUE)$observed&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; 500 623  72  70  31&lt;br/&gt;
&amp;gt; chisq.test(o1,p=e1,rescale.p=TRUE)$expected&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; 521.19403 581.37313  88.11940  65.55224  39.76119&lt;/p&gt;





</description>
                <environment>&lt;p&gt;windows xp&lt;/p&gt;</environment>
            <key id="12383845">MATH-175</key>
            <summary>chiSquare(double[] expected, long[] observed) is returning incorrect test statistic</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="carlanderson">carl anderson</reporter>
                        <labels>
                    </labels>
                <created>Tue, 4 Dec 2007 02:31:53 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:16 +0000</updated>
                    <resolved>Wed, 9 Jan 2008 05:17:45 +0000</resolved>
                            <version>1.1</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12548094" author="carlanderson" created="Tue, 4 Dec 2007 02:33:23 +0000"  >&lt;p&gt;here is the calculations currently in the code, and below the correct calculations&lt;/p&gt;</comment>
                    <comment id="12548526" author="psteitz" created="Wed, 5 Dec 2007 03:58:31 +0000"  >&lt;p&gt;Thank you for reporting this.  I agree that if the count sums are unequal, the test is not meaningful (at least I can&apos;t see a meaningful interpretation).  So the question is, do we throw IllegalArgumentException in this case or assume expected should be rescaled? &lt;/p&gt;</comment>
                    <comment id="12548743" author="carlanderson" created="Wed, 5 Dec 2007 17:43:48 +0000"  >&lt;p&gt;Hi Phil,&lt;/p&gt;

&lt;p&gt;I coded a rescaling, as below, but I have to admit that I spent a long&lt;br/&gt;
time puzzling over why results from Java differed from those with R&lt;br/&gt;
because neither threw an exception or any warning that the argument sums&lt;br/&gt;
differed. It just didn&apos;t occur to me at first that this was an issue.&lt;/p&gt;

&lt;p&gt;Carl&lt;/p&gt;


&lt;p&gt;package com.archimedesmodel.automation.stats;&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.stat.inference.ChiSquareTestImpl;&lt;/p&gt;

&lt;p&gt;public class ArchiChiSquared extends ChiSquareTestImpl {&lt;/p&gt;

&lt;p&gt;	public double chiSquare(double[] expected, long[] observed)&lt;br/&gt;
			throws IllegalArgumentException {&lt;br/&gt;
		double sumSq = 0.0d;&lt;br/&gt;
		double dev = 0.0d;&lt;br/&gt;
		if ((expected.length &amp;lt; 2) || (expected.length !=&lt;br/&gt;
observed.length)) {
			throw new IllegalArgumentException(
					&quot;observed, expected array
lengths incorrect&quot;);
		}&lt;/p&gt;

&lt;p&gt;		double sumObs = 0;&lt;br/&gt;
		for (int i = 0; i &amp;lt; observed.length; i++) {&lt;br/&gt;
			sumObs += observed&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt;;&lt;br/&gt;
			if (observed&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; &amp;lt; 0) {
				throw new IllegalArgumentException(
						&quot;observed counts must be
non-negative&quot;);
			}&lt;br/&gt;
		}&lt;/p&gt;

&lt;p&gt;		double sumExp = 0;&lt;br/&gt;
		for (int i = 0; i &amp;lt; expected.length; i++) {&lt;br/&gt;
			sumExp += expected&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt;;&lt;br/&gt;
			if (expected&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; &amp;lt;= 0) {
				throw new IllegalArgumentException(
						&quot;expected counts must be
postive&quot;);
			}&lt;br/&gt;
		}&lt;/p&gt;

&lt;p&gt;		double ratio = 1.0;&lt;br/&gt;
		if (Double.compare(sumObs, sumExp) != 0) {
			//log some warning?
			ratio = sumObs / sumExp;
		}&lt;/p&gt;

&lt;p&gt;		for (int i = 0; i &amp;lt; observed.length; i++) {
			dev = ((double) observed[i] - ratio *
expected[i]);
			sumSq += dev * dev / (ratio * expected[i]);
		}&lt;br/&gt;
		return sumSq;&lt;br/&gt;
	}&lt;/p&gt;

&lt;p&gt;}&lt;/p&gt;






</comment>
                    <comment id="12557135" author="psteitz" created="Wed, 9 Jan 2008 05:17:45 +0000"  >&lt;p&gt;Automatic rescaling fix committed in r610274. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12370901" name="chi.xls" size="14336" author="carlanderson" created="Tue, 4 Dec 2007 02:33:22 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 5 Dec 2007 03:58:31 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-174] Mean.evaluate() should use a two-pass algorithm</title>
                <link>https://issues.apache.org/jira/browse/MATH-174</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Since it has access to the full array of stored data, Mean.evaluate(double[]) can improve its accuracy by executing a two-pass algorithm, first computing an initial estimate using the definitional forumla and then correcting that value by the mean deviation against that value.  The attached patch makes the correction and includes an algorithm reference.  It also re-activates and increases sensitivity in some of the certified data tests.  The Michelson data test fails with the current implementation, showing a difference in the 13th significant digit.&lt;/p&gt;

&lt;p&gt;This change will improve accuracy in DescriptiveStatistics.getMean and also in Variance.evaluate() and DescriptiveStatistics.getVariance().  There is a cost associated with the change - as it roughly doubles the arithmetic operations required to compute the mean.  Since it only applies to the &quot;stored array&quot; implementation and the implementation will be pluggable in 1.2,  my preference is to move ahead with this change.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12383747">MATH-174</key>
            <summary>Mean.evaluate() should use a two-pass algorithm</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="psteitz">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 2 Dec 2007 19:15:09 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:16 +0000</updated>
                    <resolved>Sat, 8 Dec 2007 03:02:34 +0000</resolved>
                            <version>1.0</version>
                <version>1.1</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12547660" author="luc" created="Sun, 2 Dec 2007 19:47:40 +0000"  >&lt;p&gt;I agree with you, go ahead with this change.&lt;/p&gt;</comment>
                    <comment id="12549642" author="psteitz" created="Sat, 8 Dec 2007 03:02:34 +0000"  >&lt;p&gt;Fixed in r602306.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12370797" name="mean.patch" size="7941" author="psteitz" created="Sun, 2 Dec 2007 19:17:19 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 2 Dec 2007 19:47:40 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-167] ConvergenceException in normal CDF</title>
                <link>https://issues.apache.org/jira/browse/MATH-167</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;NormalDistributionImpl::cumulativeProbability(double x) throws ConvergenceException&lt;br/&gt;
if x deviates too much from the mean. For example, when x=+/-100, mean=0, sd=1.&lt;br/&gt;
Of course the value of the CDF is hard to evaluate in these cases,&lt;br/&gt;
but effectively it should be either zero or one.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12372594">MATH-167</key>
            <summary>ConvergenceException in normal CDF</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="uttumuttu">Mikko Kauppila</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Jun 2007 14:50:05 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:15 +0000</updated>
                    <resolved>Mon, 19 Nov 2007 01:18:28 +0000</resolved>
                                            <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12510905" author="psteitz" created="Sat, 7 Jul 2007 15:35:10 +0000"  >&lt;p&gt;Thanks for reporting this.  I see three alternatives to address - appreciate comments.&lt;br/&gt;
1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and &quot;top code&quot;, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean.  To find the cut points, empirically determine where convergence starts to fail.  Document the cut points in javadoc for Impl.&lt;br/&gt;
2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen).&lt;br/&gt;
3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument.  Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0.&lt;br/&gt;
My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative.&lt;br/&gt;
Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue.&lt;/p&gt;

</comment>
                    <comment id="12514453" author="psteitz" created="Sun, 22 Jul 2007 02:33:45 +0000"  >&lt;p&gt;Fixed for nomal distribution in r558450.&lt;br/&gt;
Leaving open because we should look at other distributions before closing.  &lt;/p&gt;</comment>
                    <comment id="12543443" author="psteitz" created="Mon, 19 Nov 2007 01:18:28 +0000"  >&lt;p&gt;While the t, F and Gamma distributions all use convergents (which may fail to converge for tail probabilities), there is no obvious way (to me at least) to test and set uniform bounds as we did for the Normal distribution in the fix applied in r558450.  Since this issue was reported against the Normal distribution, I am resolving this issue as fixed.  &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 7 Jul 2007 15:35:10 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-166] Special functions not very accurate</title>
                <link>https://issues.apache.org/jira/browse/MATH-166</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The Gamma and Beta functions return values in double precision but the default epsilon is set to 10e-9. I think that the default should be set to the highest possible accuracy, as this is what I&apos;d expect to be returned by a double precision routine. Note that the erf function already uses a call to Gamma.regularizedGammaP with an epsilon of 1.0e-15.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12370828">MATH-166</key>
            <summary>Special functions not very accurate</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ltheussl">Lukas Theussl</reporter>
                        <labels>
                    </labels>
                <created>Mon, 4 Jun 2007 09:34:54 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:15 +0000</updated>
                    <resolved>Wed, 20 Jun 2007 22:24:30 +0000</resolved>
                            <version>1.1</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12501165" author="ltheussl" created="Mon, 4 Jun 2007 09:36:22 +0000"  >&lt;p&gt;Patch to increase the default accuracy and corresponding tests.&lt;/p&gt;</comment>
                    <comment id="12503281" author="psteitz" created="Mon, 11 Jun 2007 05:15:23 +0000"  >&lt;p&gt;I see no reason not to apply this patch for 1.2.&lt;/p&gt;</comment>
                    <comment id="12506704" author="psteitz" created="Wed, 20 Jun 2007 22:24:30 +0000"  >&lt;p&gt;Patch applied.  Thanks&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12358839" name="MATH-166.patch" size="3822" author="ltheussl" created="Mon, 4 Jun 2007 09:36:22 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 11 Jun 2007 05:15:23 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-153] RandomDataImpl nextInt(int, int) nextLong(long, long)</title>
                <link>https://issues.apache.org/jira/browse/MATH-153</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors.&lt;/p&gt;

&lt;p&gt;change&lt;br/&gt;
return lower + (int) (rand.nextDouble() * (upper - lower + 1));&lt;br/&gt;
to&lt;br/&gt;
return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1)));&lt;/p&gt;

&lt;p&gt;additional checks must be made for the nextlong(long, long) method.&lt;br/&gt;
At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes.  The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference.&lt;/p&gt;</description>
                <environment></environment>
            <key id="12346925">MATH-153</key>
            <summary>RandomDataImpl nextInt(int, int) nextLong(long, long)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="remi_arntzen">Remi Arntzen</reporter>
                        <labels>
                    </labels>
                <created>Mon, 31 Jul 2006 03:48:24 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:14 +0000</updated>
                    <resolved>Thu, 5 Apr 2007 15:20:45 +0000</resolved>
                            <version>1.1</version>
                <version>Nightly Builds</version>
                                <fixVersion>1.2</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="12424472" author="remi_arntzen" created="Mon, 31 Jul 2006 04:16:02 +0000"  >&lt;p&gt;once Math-154 (MathUtils addAndCheck and subAndCheck for long values)&lt;br/&gt;
is commited nextLong(long, long) could become&lt;/p&gt;

&lt;p&gt;public long nextLong(long lower, long upper) {&lt;br/&gt;
    if (lower &amp;gt;= upper) {
        throw new IllegalArgumentException(
                &quot;upper bound must be &amp;gt; lower bound&quot;);
    }&lt;br/&gt;
    RandomGenerator rand = getRan();&lt;br/&gt;
    boolean overFlow = false;&lt;br/&gt;
    try {
        MathUtils.subAndCheck(upper, lower);
    } catch (ArithmeticException thrown) {
        overFlow = true;
    }&lt;/p&gt;

&lt;p&gt;    long returnValue;&lt;/p&gt;

&lt;p&gt;    if (upper - lower == Long.MAX_VALUE) {
        //upper - lower + 1 = Long.MAX_VALUE + 1 = *overflow error*;
        overFlow = true;
    }&lt;/p&gt;

&lt;p&gt;    if (!overFlow) {
        returnValue = lower + (long) (rand.nextDouble() * (upper -
                                                           lower + 1)
                                                          );
    } else {&lt;br/&gt;
        returnValue = rand.nextLong();&lt;br/&gt;
        while (returnValue &amp;gt; upper || returnValue &amp;lt; lower) {
            returnValue = rand.nextLong();
        }&lt;br/&gt;
    }&lt;br/&gt;
    return returnValue;&lt;br/&gt;
}&lt;/p&gt;</comment>
                    <comment id="12426064" author="psteitz" created="Sun, 6 Aug 2006 15:01:15 +0000"  >&lt;p&gt;Agree this is a bug and should be fixed.   Thanks for reporting this issue.&lt;/p&gt;

&lt;p&gt;Using the added method in &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-154&quot; title=&quot;MathUtils addAndCheck and subAndCheck for long values&quot;&gt;&lt;del&gt;MATH-154&lt;/del&gt;&lt;/a&gt; to detect overflow in the long case is good.&lt;/p&gt;

&lt;p&gt;There should be a way to avoid the while loop at the end of the long impl.&lt;/p&gt;

&lt;p&gt;We also need test cases to close this.&lt;/p&gt;</comment>
                    <comment id="12426210" author="brentworden" created="Mon, 7 Aug 2006 13:19:58 +0000"  >&lt;p&gt;I think we can avoid the overflow conditions simply by distributing the multiplication of the random value.  With this, the method body would become:&lt;/p&gt;

&lt;p&gt;double r = rand.nextDouble();&lt;br/&gt;
return (int)((r * upper) + ((1.0 - r) * lower) + r);&lt;/p&gt;</comment>
                    <comment id="12487006" author="brentworden" created="Thu, 5 Apr 2007 15:20:45 +0000"  >&lt;p&gt;SVN 525842: Corrected nextInt and nextLong to handle wide value ranges.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12338445" name="Test.diff" size="2747" author="remi_arntzen" created="Wed, 9 Aug 2006 05:58:12 +0000" />
                    <attachment id="12338418" name="diff.txt" size="948" author="remi_arntzen" created="Tue, 8 Aug 2006 21:47:47 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Aug 2006 15:01:15 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-151] MathUtils.round incorrect result</title>
                <link>https://issues.apache.org/jira/browse/MATH-151</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with default rounding mode BigDecimal.ROUND_HALF_UP.&lt;/p&gt;

&lt;p&gt;I found that internally MathUtils.round multiplies the given number by 10^scale.&lt;br/&gt;
 39.245 * 100.0 results 3924.49999...5 , and after this the calculation is not correct any more.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Win2K, Sun JDK1.5.0_05 b05&lt;/p&gt;</environment>
            <key id="12343947">MATH-151</key>
            <summary>MathUtils.round incorrect result</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="buzaz">Buza Zolt&#225;n</reporter>
                        <labels>
                    </labels>
                <created>Mon, 5 Jun 2006 22:22:11 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:14 +0000</updated>
                    <resolved>Tue, 4 Jul 2006 15:19:28 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12414956" author="psteitz" created="Tue, 6 Jun 2006 20:40:32 +0000"  >&lt;p&gt;Thanks for reporting this bug.  Could be we want to reconsider the changes applied to address &lt;a href=&quot;http://issues.apache.org/jira/browse/MATH-32&quot;&gt;http://issues.apache.org/jira/browse/MATH-32&lt;/a&gt;.  Patches welcome!&lt;/p&gt;</comment>
                    <comment id="12415048" author="luc" created="Wed, 7 Jun 2006 04:11:25 +0000"  >&lt;p&gt;I think this behaviour is normal.&lt;br/&gt;
Despite 39.245 has a finite representation in decimal, this is not true in base 2, it has a infinite number of digits. For the sake of simplicity, here is the representation in base 16 (much more readable than base 2) :&lt;/p&gt;

&lt;p&gt;  0x27.3EB851EB851EB851EB851...&lt;/p&gt;

&lt;p&gt;Note that the pattern EB851 repeats itself ad infinitum, in base 2 it is a 20 bits pattern.&lt;br/&gt;
If this number could be represented in a virtual infinite register, multiplying it by 100.0 (base 10) would be&lt;br/&gt;
multiplying it by 0x64 (base 16) and the result would be 0xF54.8 which is 3924.5 as could be rounded as expected.&lt;/p&gt;

&lt;p&gt;However, primitive doubles are represented in Java using the IEEE754 norm, where the mantissa is 53 bits long, counting an implicit first bit. This implies that in the previous infinite number only the following is represented in IEE754:&lt;/p&gt;

&lt;p&gt;  0x27.3EB851EB851&lt;/p&gt;

&lt;p&gt;hence, when this number is multiplied by 100, we get the result:&lt;/p&gt;

&lt;p&gt;  0xF54.7FFFFFFFFA4 or 3924.49999999999477040546480566263198...&lt;/p&gt;

&lt;p&gt;So the error is exactly 0x0.0000000005C or 92/16^11 which is approximately 5.229e-12.&lt;/p&gt;

&lt;p&gt;The problem comes from the fact the original number cannot be represented exactly (it is not what is sometimes called a &quot;floating-point number&quot; or &quot;normal number&quot;), and in this case the first neglected hexadecimal digit is large (E) which explains the large error (7 wrong bits after the multiplication).&lt;/p&gt;

&lt;p&gt;I would say this is not an issue with commons-math but with IEE754, we cannot do anything about it.&lt;/p&gt;

&lt;p&gt;Note that the same would occur if we could add one pattern by adding 20 bits. In this case, the final number would be 3924.4999999999999999950126700065666 and the error appoximately 4.987e-18 (92/16^16), but still lesser than 3924.5&lt;/p&gt;</comment>
                    <comment id="12415723" author="psteitz" created="Sun, 11 Jun 2006 07:26:25 +0000"  >&lt;p&gt;Thanks for digging into this, Luc.&lt;/p&gt;

&lt;p&gt;I agree that the source of the problem here is in the decimal - binary conversion; but I don&apos;t want to close this as &quot;invalid&quot; or &quot;wontfix&quot; until we have exhausted all practical means to address the problem from the user standpoint.  In other words, I would prefer to find a workaround if that is possible.  &lt;/p&gt;

&lt;p&gt;One possibility is to revert to the implementation in R226479 or earlier.  See &lt;a href=&quot;http://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?revision=226479&quot;&gt;http://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?revision=226479&lt;/a&gt; &lt;br/&gt;
where we used BigDecimal rounding.  We changed this partly for efficiency, partly to address &lt;a href=&quot;http://issues.apache.org/jira/browse/MATH-32&quot;&gt;http://issues.apache.org/jira/browse/MATH-32&lt;/a&gt;, which we would have to address in some other way if we go that route.&lt;/p&gt;

&lt;p&gt;Ideas or patches welcome!&lt;/p&gt;</comment>
                    <comment id="12415733" author="luc" created="Sun, 11 Jun 2006 16:04:15 +0000"  >&lt;p&gt;The point is neither on the rounding method not on the scale factor, it is rather on the initial number itself.&lt;br/&gt;
39.245 has no exact representation in IEE754. it lies between two representable numbers (I forgot 4 bits in my previous post):&lt;/p&gt;

&lt;p&gt;      0x139f5c28f5c28f  * 2^-47  &amp;lt; 39.245  &amp;lt;  0x139f5c28f5c290 * 2^-47&lt;br/&gt;
 or 0x27.3eb851eb851e  &amp;lt;  39.245  &amp;lt;  27.3eb851eb8520&lt;br/&gt;
 or 39.2449999999999974420461512636...  &amp;lt;  39.245  &amp;lt;  39.2450000000000045474735088646...&lt;/p&gt;

&lt;p&gt;When we talk about 39.245, we refer to the decimal representation that was parsed either by some data input function using something like Double.parseDouble(String) or we refer to a litteral value in the Java code, which in fact is also parsed at compilation time, probably also by double.parseDouble(String) or a similar function. The virtual machine doesn&apos;t see the 39.245 real number we want, it sees either 0x27.3EB851EB851E  or x27.3EB851EB8520 depending on the parsing behaviour. This is not a Java-related problem, it is also true for languages like C, C++, fortran, whatever.&lt;/p&gt;

&lt;p&gt;In the case discussed here, the value was the low one (i.e. 0x27.3EB851EB851E, or 39.2449999999999974420461...). The parsing method did a good job here in my opinion as this number is the closest one to the real number we wanted (the error is about 2.55e-15 and it would have been 4.54e-15 if the other alternative were chosen).&lt;/p&gt;

&lt;p&gt;Going back to the initial problem, and assuming we now start from 39.2449999999999974420461..., we want to round this number 2 digits after the decimal point. MathUtils.round answer is 39.24 (really 39.2400000000000019895...), which is &quot;only&quot; 0.0049999999999954525264... away from out number. Answering 39.25 (which CAN be represented exactly in IEEE754) would be &quot;0.005000000000002557953848...&quot; away. The initial number is not exactly at a 0.5 * 10^-n boundary, so switching between ROUND_HALF_DOWN, ROUND_HALF_UP or ROUND_HALF_EVEN does not change anything (I have checked this).&lt;/p&gt;</comment>
                    <comment id="12415764" author="psteitz" created="Sun, 11 Jun 2006 23:57:58 +0000"  >&lt;p&gt;I understand and agree with your analysis of the IEEE754 representation, but I would still like to see if there is anyting clever that we can do to work around the problem.   Could be this is hopeless, but I am bothered by the fact that the previous implementation actually handles this correctly.  Sorry I messed up the link in the comment above to the earlier BigDecimal-based impl.  That should have been to &lt;br/&gt;
&lt;a href=&quot;http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?revision=239294&amp;amp;view=markup&quot;&gt;http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?revision=239294&amp;amp;view=markup&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In any case, the impl there, modified to handle the special values included in later tests would be:&lt;br/&gt;
public static double round(double x, int scale, int roundingMethod) {&lt;br/&gt;
        try {
            return (new BigDecimal
                   (new Double(x).toString())
                   .setScale(scale, roundingMethod))
                   .doubleValue();
        } catch (NumberFormatException ex) {&lt;br/&gt;
            if (Double.isInfinite&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;) {
                return x;          
            } else {
                return Double.NaN;
            }&lt;br/&gt;
        }&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;Before &lt;a href=&quot;http://issues.apache.org/jira/browse/MATH-32&quot;&gt;http://issues.apache.org/jira/browse/MATH-32&lt;/a&gt;, it was just&lt;br/&gt;
return (new BigDecimal&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.setScale(scale, roundingMethod))&lt;/p&gt;

&lt;p&gt;The code above passes all tests, including even&lt;br/&gt;
double x = 39.0d;&lt;br/&gt;
x = x + 245d/1000d;&lt;br/&gt;
assertEquals(39.25,MathUtils.round(x, 2), 0.0);&lt;/p&gt;</comment>
                    <comment id="12415774" author="psteitz" created="Mon, 12 Jun 2006 00:59:50 +0000"  >&lt;p&gt;Sorry, messed up the link yet again.  Best to just look at&lt;br/&gt;
&lt;a href=&quot;http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?view=log&quot;&gt;http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?view=log&lt;/a&gt;&lt;br/&gt;
or use a svn client to examine history. &lt;/p&gt;

&lt;p&gt;I also neglected to mention that part of the reason for the change to the new impl was performance.   I played with some microbenchmarks to confirm this some time ago, seeing about 5x-8x improvement in the direct impl.  It might be a good idea to do this testing rigorously.  &lt;/p&gt;

&lt;p&gt;If we could characterize the inputs somehow that have &quot;bad&quot; IEEE754 representations, perhaps we could use the BigDecimal-based impl just for them.   I don&apos;t see any reliable way to do that, though.&lt;/p&gt;</comment>
                    <comment id="12416287" author="luc" created="Thu, 15 Jun 2006 09:31:51 +0000"  >&lt;p&gt;I was looking for a way to characterize those &quot;bad&quot; IEEE754 representations. Here is one proposal:&lt;br/&gt;
we could had an implementation of  the nextAfter method, either in MathUtils or in a new IeeeFunctions method in case we want also to add other interesting functions defined by the IEEE754 standard. The signature of this method is:&lt;/p&gt;

&lt;p&gt;  static double nextAfter(double d, double direction)&lt;/p&gt;

&lt;p&gt;It returns the next representable number after its first argument which lies on the same side as the second argument. Using this, we could compare the rounding of x and nextAfter(x, x+1) when the rounding mode is ROUND_HALF_UP. If the results is different, the IEEE754 representation of x is on some boundary. In fact, I think we could always return the rounding of nextAfter in this mode (after all if round&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; and round(nextAfter&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;) are the same, we could return either and if they are not the same, we want to return round(nextAfter, at least in some rounding methods). The test could be performed in the roundUnscaled method, and similar tests could be implemented in the other branches of the switch for other rounding methods.&lt;/p&gt;

&lt;p&gt;This would be slower than the current implementation, but probably much faster than going back to rebuild a String and parsing it as a BigDecimal.&lt;/p&gt;

&lt;p&gt;I have written an implementation of nextAfter. It is based on Double.doubleToLongBits, bits twiddling, and  Double.longBitsToDouble.&lt;/p&gt;</comment>
                    <comment id="12416856" author="psteitz" created="Tue, 20 Jun 2006 14:03:54 +0000"  >&lt;p&gt;+1 to nextAfter as addition to MathUtils and for the approach outlined above for resolving this issue.  Thanks in advance for patches. &lt;/p&gt;</comment>
                    <comment id="12418308" author="luc" created="Thu, 29 Jun 2006 03:12:05 +0000"  >&lt;p&gt;This patch is an attempt to solve the issue.&lt;br/&gt;
The principle is to add a nexAfter method in MathUtils and to use it in order to very slightly shift the numbers (by one ulp) in the expected rounding direction in order to avoid some degenerate cases.&lt;br/&gt;
Note that if someone REALLY wants to round a number like 39.2449999999999974420461512636 and NOT 39.245, we will produce a wrong result. I didn&apos;t put any warning about this behaviour in the javadoc, but I think that if this patch is finally applied, the javadoc should be exlpicit.&lt;/p&gt;

&lt;p&gt;I understand the user problem but do not really like answering like that, it seems more like an ad hoc trick to me. I&apos;m not very proud of my first patch &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12419059" author="psteitz" created="Tue, 4 Jul 2006 15:19:27 +0000"  >&lt;p&gt;Patch applied.  Thanks!&lt;/p&gt;

&lt;p&gt;I understand that the patch is not really satisfying, but it makes the code better and resolves the reported problem.   A more elegant solution may be possible, but the patch improves the code and resolves the reported problem, so it should be applied.  If we find a better way to handle correct rounding of &quot;bad&quot; IEEE754 numbers, we can reopen or create a separate issue.&lt;/p&gt;

&lt;p&gt;Thanks for the patch!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12336090" name="math-151.patch" size="10754" author="luc" created="Thu, 29 Jun 2006 03:12:05 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 6 Jun 2006 20:40:32 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-112] [math][patch] Comments Changes</title>
                <link>https://issues.apache.org/jira/browse/MATH-112</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Index: TrapezoidIntegrator.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; TrapezoidIntegrator.java	(revision 233018)&lt;br/&gt;
+++ TrapezoidIntegrator.java	(working copy)&lt;br/&gt;
@@ -20,7 +20,7 @@&lt;/p&gt;

&lt;p&gt; /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Implements the &amp;lt;a href=&quot;http://mathworld.wolfram.com/TrapezoidalRule.html&quot;&amp;gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* Trapezoidal Rule&amp;lt;/a&amp;gt; for integrating of real univariate functions. For&lt;br/&gt;
+ * Trapezoidal Rule&amp;lt;/a&amp;gt; for integration of real univariate functions. For&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;reference, see &amp;lt;b&amp;gt;Introduction to Numerical Analysis&amp;lt;/b&amp;gt;, ISBN 038795452X,&lt;/li&gt;
	&lt;li&gt;chapter 3.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;&lt;br/&gt;
@@ -39,7 +39,7 @@&lt;br/&gt;
     /**&lt;/li&gt;
	&lt;li&gt;Construct an integrator for the given function.&lt;/li&gt;
	&lt;li&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* @param f function to solve&lt;br/&gt;
+     * @param f function to integrate&lt;br/&gt;
      */&lt;br/&gt;
     public TrapezoidIntegrator(UnivariateRealFunction f) {&lt;br/&gt;
         super(f, 64);&lt;br/&gt;
Index: SimpsonIntegrator.java&lt;br/&gt;
===================================================================
	&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
		&lt;li&gt;
		&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
			&lt;li&gt;SimpsonIntegrator.java	(revision 233018)&lt;br/&gt;
+++ SimpsonIntegrator.java	(working copy)&lt;br/&gt;
@@ -20,7 +20,7 @@&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt; /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Implements the &amp;lt;a href=&quot;http://mathworld.wolfram.com/SimpsonsRule.html&quot;&amp;gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* Simpson&apos;s Rule&amp;lt;/a&amp;gt; for integrating of real univariate functions. For&lt;br/&gt;
+ * Simpson&apos;s Rule&amp;lt;/a&amp;gt; for integration of real univariate functions. For&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;reference, see &amp;lt;b&amp;gt;Introduction to Numerical Analysis&amp;lt;/b&amp;gt;, ISBN 038795452X,&lt;/li&gt;
	&lt;li&gt;chapter 3.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;&lt;br/&gt;
@@ -37,7 +37,7 @@&lt;br/&gt;
     /**&lt;/li&gt;
	&lt;li&gt;Construct an integrator for the given function.&lt;/li&gt;
	&lt;li&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* @param f function to solve&lt;br/&gt;
+     * @param f function to integrate&lt;br/&gt;
      */&lt;br/&gt;
     public SimpsonIntegrator(UnivariateRealFunction f) {&lt;br/&gt;
         super(f, 64);&lt;br/&gt;
Index: RombergIntegrator.java&lt;br/&gt;
===================================================================
	&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
		&lt;li&gt;
		&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
			&lt;li&gt;RombergIntegrator.java	(revision 233018)&lt;br/&gt;
+++ RombergIntegrator.java	(working copy)&lt;br/&gt;
@@ -1,5 +1,5 @@&lt;br/&gt;
 /*&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;* Copyright 2003-2005 The Apache Software Foundation.&lt;br/&gt;
+ * Copyright 2005 The Apache Software Foundation.&lt;br/&gt;
  *&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;Licensed under the Apache License, Version 2.0 (the &quot;License&quot;);&lt;/li&gt;
	&lt;li&gt;you may not use this file except in compliance with the License.&lt;br/&gt;
@@ -20,7 +20,7 @@&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt; /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Implements the &amp;lt;a href=&quot;http://mathworld.wolfram.com/RombergIntegration.html&quot;&amp;gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* Romberg Algorithm&amp;lt;/a&amp;gt; for integrating of real univariate functions. For&lt;br/&gt;
+ * Romberg Algorithm&amp;lt;/a&amp;gt; for integration of real univariate functions. For&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;reference, see &amp;lt;b&amp;gt;Introduction to Numerical Analysis&amp;lt;/b&amp;gt;, ISBN 038795452X,&lt;/li&gt;
	&lt;li&gt;chapter 3.&lt;/li&gt;
	&lt;li&gt;&amp;lt;p&amp;gt;&lt;br/&gt;
@@ -38,7 +38,7 @@&lt;br/&gt;
     /**&lt;/li&gt;
	&lt;li&gt;Construct an integrator for the given function.&lt;/li&gt;
	&lt;li&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;* @param f function to solve&lt;br/&gt;
+     * @param f function to integrate&lt;br/&gt;
      */&lt;br/&gt;
     public RombergIntegrator(UnivariateRealFunction f) {&lt;br/&gt;
         super(f, 32);&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342480">MATH-112</key>
            <summary>[math][patch] Comments Changes</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Aug 2005 03:59:59 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:12 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:12 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410126" author="zxg_32@yahoo.com" created="Wed, 17 Aug 2005 04:02:07 +0000"  >&lt;p&gt;minor changes of comments&lt;/p&gt;</comment>
                    <comment id="12410127" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 07:26:51 +0000"  >&lt;p&gt;Applied. Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36211</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Aug 2005 07:26:51 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-110] [math] TestStatistic interface, implementation, tests</title>
                <link>https://issues.apache.org/jira/browse/MATH-110</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Includes only chi-square test statistic, used in testing homogeneity of random&lt;br/&gt;
sequences.  Used in test cases for RandomData to follow.&lt;/p&gt;

&lt;p&gt;Illustrates proposed documentation style.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340711">MATH-110</key>
            <summary>[math] TestStatistic interface, implementation, tests</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Fri, 16 May 2003 04:30:05 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:12 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:12 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404247" author="phil@steitz.com" created="Fri, 16 May 2003 04:31:16 +0000"  >&lt;p&gt;Created an attachment (id=6375)&lt;br/&gt;
TestStatistic Interface&lt;/p&gt;</comment>
                    <comment id="12404248" author="phil@steitz.com" created="Fri, 16 May 2003 04:31:56 +0000"  >&lt;p&gt;Created an attachment (id=6376)&lt;br/&gt;
TestStatistic Implementation&lt;/p&gt;</comment>
                    <comment id="12404249" author="phil@steitz.com" created="Fri, 16 May 2003 04:33:07 +0000"  >&lt;p&gt;Created an attachment (id=6377)&lt;br/&gt;
Test Statistic Test cases&lt;/p&gt;</comment>
                    <comment id="12404250" author="phil@steitz.com" created="Fri, 16 May 2003 04:34:09 +0000"  >&lt;p&gt;Created an attachment (id=6378)&lt;br/&gt;
Patch to include test cases&lt;/p&gt;</comment>
                    <comment id="12404251" author="tobrien@discursive.com" created="Fri, 16 May 2003 05:03:12 +0000"  >&lt;p&gt;All patches applied, exception the final patch to the test suite which&lt;br/&gt;
referenced a non-existant class RandomUtilTest.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332275" name="MathTestSuitePatch.txt" size="1205" author="phil@steitz.com" created="Fri, 16 May 2003 04:34:09 +0000" />
                    <attachment id="12332272" name="TestStatistic.java" size="4001" author="phil@steitz.com" created="Fri, 16 May 2003 04:31:16 +0000" />
                    <attachment id="12332273" name="TestStatisticImpl.java" size="4103" author="phil@steitz.com" created="Fri, 16 May 2003 04:31:56 +0000" />
                    <attachment id="12332274" name="TestStatisticTest.java" size="4432" author="phil@steitz.com" created="Fri, 16 May 2003 04:33:07 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>4.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>19971</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 16 May 2003 05:03:12 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-109] Wrong p-value in SimpleRegression (factor 2 difference)</title>
                <link>https://issues.apache.org/jira/browse/MATH-109</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;SimpleRegression gives back wrong P-value. (when test data set is compared to&lt;br/&gt;
STATISTICA software package output. Error is likely one-sided versus two-sided&lt;br/&gt;
testing issue:&lt;br/&gt;
OLD:&lt;br/&gt;
    public double getSignificance() throws MathException {
        return (
            1.0 - getTDistribution().cumulativeProbability(
                    Math.abs(getSlope()) / getSlopeStdErr()));
    }&lt;/p&gt;

&lt;p&gt;FIXED:&lt;br/&gt;
    public double getSignificance() throws MathException {
        return 2d*(
            1.0 - getTDistribution().cumulativeProbability(
                    Math.abs(getSlope()) / getSlopeStdErr()));
    }&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12341827">MATH-109</key>
            <summary>Wrong p-value in SimpleRegression (factor 2 difference)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="kim@kimvdlinde.com">Kim van der Linde</reporter>
                        <labels>
                    </labels>
                <created>Sat, 23 Oct 2004 10:52:25 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:12 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:12 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12407868" author="phil@steitz.com" created="Sun, 24 Oct 2004 02:56:37 +0000"  >&lt;p&gt;This is a bug. Returned significance does not match javadoc.  Good catch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31860</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 24 Oct 2004 02:56:37 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-108] [math][patch] Update UnivariateRealSolverImpl.java</title>
                <link>https://issues.apache.org/jira/browse/MATH-108</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Index: UnivariateRealSolverImpl.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; UnivariateRealSolverImpl.java       (revision 233212)&lt;br/&gt;
+++ UnivariateRealSolverImpl.java       (working copy)&lt;br/&gt;
@@ -265,7 +265,8 @@&lt;br/&gt;
      */&lt;br/&gt;
     protected boolean isBracketing(double lower, double upper,&lt;br/&gt;
             UnivariateRealFunction f) throws FunctionEvaluationException {
-        return  (f.value(lower) * f.value(upper) &amp;lt; 0);
+        return ((f.value(lower) &amp;gt; 0 &amp;amp;&amp;amp; f.value(upper) &amp;lt; 0) ||
+                (f.value(lower) &amp;lt; 0 &amp;amp;&amp;amp; f.value(upper) &amp;gt; 0));
     }&lt;/p&gt;

&lt;p&gt;     /**&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342486">MATH-108</key>
            <summary>[math][patch] Update UnivariateRealSolverImpl.java</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Aug 2005 02:51:55 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:12 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:12 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410163" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 02:56:20 +0000"  >&lt;p&gt;isBracketing() should use condition branching instead of multiplication because&lt;/p&gt;

&lt;p&gt;1. saves one unnecessary floating-point multiplication&lt;br/&gt;
2. prevent underflow, for example&lt;br/&gt;
    double a = 4.5E-180;&lt;br/&gt;
    double b = -3.2E-180;&lt;br/&gt;
    double c = a * b;&lt;br/&gt;
   c would be -0.0, but in fact a and b still satisfy bracketing condition.&lt;/p&gt;</comment>
                    <comment id="12410164" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 02:57:00 +0000"  >&lt;p&gt;Created an attachment (id=16083)&lt;br/&gt;
UnivariateRealSolverImpl.java&lt;/p&gt;</comment>
                    <comment id="12410165" author="j3322ptm@yahoo.de" created="Thu, 18 Aug 2005 05:54:32 +0000"  >&lt;p&gt;Well, commonly the cost of a single floating point operation can be safely&lt;br/&gt;
neglected compared to the cost of evaluating the function in question.&lt;/p&gt;</comment>
                    <comment id="12410166" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 08:54:47 +0000"  >&lt;p&gt;Actually it should be like this. Maybe the compiler will optimize&lt;br/&gt;
to avoid repeated function evaluations.&lt;/p&gt;


&lt;p&gt;Index: UnivariateRealSolverImpl.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; UnivariateRealSolverImpl.java       (revision 233396)&lt;br/&gt;
+++ UnivariateRealSolverImpl.java       (working copy)&lt;br/&gt;
@@ -265,7 +265,9 @@&lt;br/&gt;
      */&lt;br/&gt;
     protected boolean isBracketing(double lower, double upper,&lt;br/&gt;
             UnivariateRealFunction f) throws FunctionEvaluationException {
-        return  (f.value(lower) * f.value(upper) &amp;lt; 0);
+        double f1 = f.value(lower);
+        double f2 = f.value(upper);
+        return ((f1 &amp;gt; 0 &amp;amp;&amp;amp; f2 &amp;lt; 0) || (f1 &amp;lt; 0 &amp;amp;&amp;amp; f2 &amp;gt; 0));
     }&lt;/p&gt;

&lt;p&gt;     /**&lt;/p&gt;</comment>
                    <comment id="12410167" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 08:57:55 +0000"  >&lt;p&gt;floating point multiplication is not big deal, underflow is not&lt;br/&gt;
frequent, but may happen in some cases.&lt;/p&gt;</comment>
                    <comment id="12410168" author="phil@steitz.com" created="Tue, 23 Aug 2005 05:59:21 +0000"  >&lt;p&gt;I am +1 for the last patch. Agree that function evals are what we should be&lt;br/&gt;
looking to minimize, but underflow looks like legitimate concern for current code.&lt;/p&gt;</comment>
                    <comment id="12410169" author="brentworden" created="Tue, 23 Aug 2005 12:05:20 +0000"  >&lt;p&gt;Applied.  SVN Revision 239305.  Applied to MATH_1_1 branch.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333725" name="UnivariateRealSolverImpl.java" size="10812" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 02:57:00 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36232</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 18 Aug 2005 05:54:32 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-107] [math] wrong message in subAndCheck</title>
                <link>https://issues.apache.org/jira/browse/MATH-107</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;In MathUtils I found this code:&lt;/p&gt;

&lt;p&gt;    public static int subAndCheck(int x, int y) {&lt;br/&gt;
        long s = (long)x - (long)y;&lt;br/&gt;
        if (s &amp;lt; Integer.MIN_VALUE || s &amp;gt; Integer.MAX_VALUE) {
            throw new ArithmeticException(&quot;overflow: add&quot;);
        }&lt;br/&gt;
        return (int)s;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;The message should be &quot;overflow: subtract&quot;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342632">MATH-107</key>
            <summary>[math] wrong message in subAndCheck</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="elharo@metalab.unc.edu">elharo</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Oct 2005 23:57:32 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:12 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:12 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410619" author="elharo@metalab.unc.edu" created="Sat, 15 Oct 2005 00:02:18 +0000"  >&lt;p&gt;Here&apos;s a test case for the bug. The fix is trivial.&lt;/p&gt;

&lt;p&gt;    public void testSubAndCheckErrorMessage() {&lt;br/&gt;
        int big = Integer.MAX_VALUE;&lt;br/&gt;
        int bigNeg = Integer.MIN_VALUE;&lt;br/&gt;
        try {
            int res = MathUtils.subAndCheck(big, -1);
        } catch (ArithmeticException ex) {
            assertEquals(&quot;overflow: subtract&quot;, ex.getMessage());
        }&lt;br/&gt;
    }&lt;/p&gt;</comment>
                    <comment id="12410620" author="phil@steitz.com" created="Sun, 16 Oct 2005 07:34:22 +0000"  >&lt;p&gt;Patch applied.  Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37093</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 16 Oct 2005 07:34:22 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-106] [math] update task list</title>
                <link>https://issues.apache.org/jira/browse/MATH-106</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached path the tasks.xml moves the following tasks into the completed bucket:&lt;/p&gt;

&lt;p&gt;Binomial coefficients &amp;#8211; incorporate an &quot;exact&quot; implementation that is&lt;br/&gt;
limited to what can be stored in a long.  Also provided double-valued&lt;br/&gt;
implementation of binomial coefficients and their logs.&lt;/p&gt;

&lt;p&gt;Add percentiles to stored Univariate implementations&lt;/p&gt;

&lt;p&gt;It also includes some edits to the open tasks&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340758">MATH-106</key>
            <summary>[math] update task list</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Thu, 5 Jun 2003 21:07:26 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404370" author="phil@steitz.com" created="Thu, 5 Jun 2003 21:08:25 +0000"  >&lt;p&gt;Created an attachment (id=6646)&lt;br/&gt;
updates to task list&lt;/p&gt;</comment>
                    <comment id="12404371" author="mdiggory@gmail.com" created="Thu, 5 Jun 2003 21:16:22 +0000"  >&lt;p&gt;I applied the patch and validated xml content. Ahh, progress! Maybe we should&lt;br/&gt;
consider &quot;classifying some of these tasks priorities now to get a grasp on&lt;br/&gt;
priority, otherwise the high/medium/low priority sections are just taking up space.&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332310" name="taskListPatch.txt" size="1988" author="phil@steitz.com" created="Thu, 5 Jun 2003 21:08:25 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20507</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 5 Jun 2003 21:16:22 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-103] ValueServer switching from URL to File is badly broken</title>
                <link>https://issues.apache.org/jira/browse/MATH-103</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;On a Windows machine, where there are spaces in the install path, URL.getFile &lt;br/&gt;
returns something like:&lt;br/&gt;
  /C:/Jakarta%20Development/commons-math/target/test-&lt;br/&gt;
classes/org/apache/commons/math/random/testData.txt&lt;/p&gt;

&lt;p&gt;ValueServer then tries to construct a File out of this, which is of course an &lt;br/&gt;
invalid path.  &lt;/p&gt;

&lt;p&gt;IMHO it would be better to base the class on InputStream (instead of File), &lt;br/&gt;
since in an app-server the concept of File isn&apos;t really defined.  Otherwise, it &lt;br/&gt;
should be based on a URL, and use the openStream method to read the resource.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341193">MATH-103</key>
            <summary>ValueServer switching from URL to File is badly broken</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="william.barker@wilshire.com">william.barker</reporter>
                        <labels>
                    </labels>
                <created>Thu, 8 Jan 2004 14:59:34 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405771" author="phil@steitz.com" created="Sun, 11 Jan 2004 15:43:01 +0000"  >&lt;p&gt;Should be fixed now in CVS.  Dependency on URL -&amp;gt; string -&amp;gt; File has been&lt;br/&gt;
eliminated.  I am not able to test on Windows, so I am leaving this open.  Can&lt;br/&gt;
someone pls run the tests on Windows to confirm?  &lt;/p&gt;</comment>
                    <comment id="12405772" author="william.barker@wilshire.com" created="Mon, 12 Jan 2004 04:25:59 +0000"  >&lt;p&gt;I can confirm that the junit tests now work on Windows.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>25972</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 11 Jan 2004 15:43:01 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-102] [math][patch] Interpolation Source Files</title>
                <link>https://issues.apache.org/jira/browse/MATH-102</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Add PolynomialFunctionNewtonForm.java&lt;br/&gt;
Add PolynomialFunctionNewtonFormTest.java&lt;br/&gt;
Add DividedDifferenceInterpolator.java&lt;br/&gt;
Add DividedDifferenceInterpolatorTest.java&lt;br/&gt;
Update NevilleInterpolator.java&lt;br/&gt;
Update NevilleInterpolatorTest.java&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342465">MATH-102</key>
            <summary>[math][patch] Interpolation Source Files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Sun, 14 Aug 2005 11:14:01 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410091" author="zxg_32@yahoo.com" created="Sun, 14 Aug 2005 11:14:29 +0000"  >&lt;p&gt;Created an attachment (id=16037)&lt;br/&gt;
Interpolation Source Files&lt;/p&gt;</comment>
                    <comment id="12410092" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 06:46:30 +0000"  >&lt;p&gt;Files added (without change, revision pending)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333710" name="Interpolation.zip" size="10049" author="zxg_32@yahoo.com" created="Sun, 14 Aug 2005 11:14:29 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36178</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Aug 2005 06:46:30 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-101] [math] Remove mode, remove some methods from StatUtils</title>
                <link>https://issues.apache.org/jira/browse/MATH-101</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch removes the following methods:&lt;/p&gt;

&lt;p&gt;1. getMode() from StoreUnivariate, AbstractStoreUnivariate, and StatUtils.  As&lt;br/&gt;
defined in the javadoc, the mode has little meaning for continuously scaled data&lt;br/&gt;
(which is what will be analyzed in the Univariate implementations).  If users&lt;br/&gt;
want frequency distributions, they can use Freq(uency).   &lt;/p&gt;

&lt;p&gt;2. Skewness, Kurtosis and Median computations from StatUtils.  We do not need&lt;br/&gt;
these internally (they are only supported in the Stored univariates) and they&lt;br/&gt;
are much less commonly used than the other methods in StatUtils.  The median is&lt;br/&gt;
also redundant with getPercentiles in AbstractStoreUnivariate and it is not&lt;br/&gt;
implemented (while the more general getPercentiles is).&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340804">MATH-101</key>
            <summary>[math] Remove mode, remove some methods from StatUtils</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sat, 21 Jun 2003 02:01:51 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404558" author="phil@steitz.com" created="Sat, 21 Jun 2003 02:03:07 +0000"  >&lt;p&gt;Created an attachment (id=6918)&lt;br/&gt;
patch to remove methods&lt;/p&gt;</comment>
                    <comment id="12404559" author="mdiggory@gmail.com" created="Sat, 21 Jun 2003 02:33:48 +0000"  >&lt;p&gt;I am all for (1.) &lt;/p&gt;

&lt;p&gt;I feel the first part of (2) needs some more thought. I am using the StatUtils&lt;br/&gt;
versions of Skewness and Kurtosis to provide for the storage based solution in&lt;br/&gt;
UnivariateImpl. This was currently the ideal location for them as I am&lt;br/&gt;
delegating to StatUtils for the other storage cases (mean, var, std) as well, so&lt;br/&gt;
its a uniform strategy across all of Univariate. As they are moments just like&lt;br/&gt;
mean and var, they can have resonably simple standalone implementations. I was&lt;br/&gt;
also optimizing the StatUtil versions of these methods at this time. &lt;/p&gt;

&lt;p&gt;The second part of (2) I&apos;m ok with. &lt;/p&gt;

&lt;p&gt;What do you think about moving percentile and sort functions into StatUtils? Are&lt;br/&gt;
you also aware that there are sort utilities for arrays in java.uitl.Arrays?&lt;/p&gt;

&lt;p&gt;Also, it would be wise to approach such changes with consideration for whats&lt;br/&gt;
happening in the rest of the system. Stripping skew and kurt without checking&lt;br/&gt;
their dependencies in UnivariateImpl would end up breaking the build. you should&lt;br/&gt;
have encountered compilation problems with UnivariateImpl after making the&lt;br/&gt;
changes in this patch. This is where IDE&apos;s like Eclipse come in handy, you can&lt;br/&gt;
do refactorings, deletions and see what breaks immediately in the IDE.&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;
</comment>
                    <comment id="12404560" author="phil@steitz.com" created="Sat, 21 Jun 2003 03:35:44 +0000"  >&lt;p&gt;I want to keep StatUtils as lean as possible, partly because the methods are static.&lt;/p&gt;

&lt;p&gt;Regarding the build, all tests run fine for me after the change.  Unfortunately,&lt;br/&gt;
the test cases for UnivariateImpl do not execute the paths that would have&lt;br/&gt;
caused failure. One more reason to get the path coverage up. Also, I neglected&lt;br/&gt;
to execute maven clean before test.  My mistake.  I see now that these methods&lt;br/&gt;
are reused, so we have to keep them in StatUtils (unless we decide to drop&lt;br/&gt;
skewness and kurtosis from UnivariateImpl).  I will submit a revised patch&lt;br/&gt;
keeping these things in; but I am getting a little squemish about so many static&lt;br/&gt;
methods. My preference would be to remove skewness and kurtosis from&lt;br/&gt;
UnivariateImpl and StatUtils as well.&lt;/p&gt;

&lt;p&gt;I do not want to put the percentile computations into StatUtils. Yes, you are&lt;br/&gt;
correct, the pre-1.2 sort implementation that I embedded in&lt;br/&gt;
abstractStoreUnivariate.getSortedValues should be replaced by the ArrayUtils&lt;br/&gt;
sort.  I will submit a separate patch for this.&lt;/p&gt;</comment>
                    <comment id="12404561" author="phil@steitz.com" created="Sat, 21 Jun 2003 03:53:48 +0000"  >&lt;p&gt;Created an attachment (id=6921)&lt;br/&gt;
Revised patch, leaving skewness, kutosis in StatUtils&lt;/p&gt;</comment>
                    <comment id="12404562" author="mdiggory@gmail.com" created="Sat, 21 Jun 2003 09:45:44 +0000"  >&lt;p&gt;Everything here was commited now, I&apos;ve also added a new test in&lt;br/&gt;
UnivariateImplTest for mean, varaince, skew and kurt (the same one thats in&lt;br/&gt;
StoreUnivariateImplTest).&lt;/p&gt;

&lt;p&gt;I&apos;m closing it out. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332373" name="statPatches.txt" size="7314" author="phil@steitz.com" created="Sat, 21 Jun 2003 02:03:07 +0000" />
                    <attachment id="12332374" name="statPatches2.txt" size="3368" author="phil@steitz.com" created="Sat, 21 Jun 2003 03:53:48 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20964</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 21 Jun 2003 02:33:48 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-100] [Math] HypergeometricDistributionImpl cumulativeProbability calculation overflown</title>
                <link>https://issues.apache.org/jira/browse/MATH-100</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Hi, for all that might use this class:&lt;/p&gt;

&lt;p&gt;several things I found when using this class to calculate the&lt;br/&gt;
cumulative probability. I attached my code FYI. three things:&lt;/p&gt;

&lt;p&gt;1. when I used my code to calculate the cumulativeProbability(50) of&lt;br/&gt;
5000 200 100 (Population size, number of successes, sample size),&lt;br/&gt;
result was greater than 1 (1.0000000000134985);&lt;br/&gt;
2. when I calculated cumulativeProbability(50) and&lt;br/&gt;
cumulativeProbability(51) for the distribution 5000 200 100, I got the&lt;br/&gt;
same results, but it should have been different;&lt;br/&gt;
2. the cumulativeProbability&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; returns &quot;for this distribution, X,&lt;br/&gt;
P(X&amp;lt;=x)&quot;, but most of the time (at least in my case) what I care about&lt;br/&gt;
is the upper tail (X&amp;gt;=x). based on the above findings, I can&apos;t simply&lt;br/&gt;
use 1-cumulativeProbability(x-1) to get what I want.&lt;/p&gt;

&lt;p&gt;here&apos;s what I think might be related to the problem: since the&lt;br/&gt;
cumulativeProbability is calculating the lower tail (X&amp;lt;=x), a&lt;br/&gt;
distribution like above often has this probability very close to 1;&lt;br/&gt;
thus it&apos;s difficult to record a number that = 1-1E-50 &apos;cause all you&lt;br/&gt;
can do is record sth like 0.9999..... and further digits will be&lt;br/&gt;
rounded. to avoid this, I suggest adding a new function to calculate&lt;br/&gt;
upper tail or change this to calculate x in a range like (n&amp;lt;=x&amp;lt;=m), in&lt;br/&gt;
addition to fix the overflow of the current function.&lt;/p&gt;

&lt;p&gt;thank you for your patience to get here. I&apos;m a newbie but I&apos;ve asked&lt;br/&gt;
Java experts in our lab about this. looking into the source code really&lt;br/&gt;
isn&apos;t up for me......hope someone can fix it, &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; BTW I&apos;m using cygwin under&lt;br/&gt;
WinXP pro SP2, with Java SDK 1.4.2_09 build b05, and the commons-math I used is&lt;br/&gt;
both the 1.0 and the nightly build of 8-15-05. &lt;/p&gt;

&lt;p&gt;the code:&lt;br/&gt;
-------------------&lt;br/&gt;
import org.apache.commons.math.distribution.HypergeometricDistributionImpl;&lt;/p&gt;

&lt;p&gt;class HyperGeometricProbability {&lt;/p&gt;

&lt;p&gt;    public static void main(String args[]) {&lt;/p&gt;

&lt;p&gt;	if(args.length != 4) {
	    
	    System.out.println(&quot;USAGE: java HyperGeometricProbabilityCalc [population]
[numsuccess] [sample] [overlap]&quot;);
	    
	}&lt;br/&gt;
	else {&lt;/p&gt;

&lt;p&gt;	    String population = args&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;;&lt;br/&gt;
	    String numsuccess = args&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;;&lt;br/&gt;
	    String sample = args&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;;&lt;br/&gt;
	    String overlap = args&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;;&lt;/p&gt;

&lt;p&gt;	    int populationI = Integer.parseInt(population);&lt;br/&gt;
	    int numsuccessI = Integer.parseInt(numsuccess);&lt;br/&gt;
	    int sampleI = Integer.parseInt(sample);&lt;br/&gt;
	    int overlapI = Integer.parseInt(overlap);&lt;/p&gt;

&lt;p&gt;	    HypergeometricDistributionImpl hDist = new&lt;br/&gt;
HypergeometricDistributionImpl(populationI, numsuccessI, sampleI);&lt;/p&gt;

&lt;p&gt;	    double raw_probability = 1.0;&lt;br/&gt;
	    double cumPro = 1.0;&lt;br/&gt;
	    double real_cumPro = 1.0;&lt;/p&gt;

&lt;p&gt;	    try {&lt;br/&gt;
		if (0 &amp;lt; overlapI &amp;amp;&amp;amp; 0 &amp;lt; numsuccessI &amp;amp;&amp;amp; 0 &amp;lt; sampleI) {
		    raw_probability = hDist.probability(overlapI);
		    cumPro = hDist.cumulativeProbability(overlapI - 1.0);
		    real_cumPro = 1.0 - cumPro;
			System.out.println(&quot;cumulative probability=&quot; + cumPro + &quot;\t&quot; + &quot;raw
probability=&quot; + raw_probability + &quot;\t&quot; + &quot;real cumulative probability=&quot; + &quot;\t&quot; +
real_cumPro);
		    }&lt;br/&gt;
	    }&lt;br/&gt;
	    catch (Exception e) {
		System.err.println(&quot;BAD PROBABILITY CALCULATION&quot;);
	    }&lt;/p&gt;

&lt;p&gt;	}&lt;/p&gt;

&lt;p&gt;    }&lt;/p&gt;

&lt;p&gt;}&lt;br/&gt;
----------------------------------&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342483">MATH-100</key>
            <summary>[Math] HypergeometricDistributionImpl cumulativeProbability calculation overflown</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="microarray@gmail.com">mike hu</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Aug 2005 08:41:21 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410133" author="microarray@gmail.com" created="Wed, 17 Aug 2005 08:43:22 +0000"  >&lt;p&gt;Created an attachment (id=16073)&lt;br/&gt;
the code as a txt file&lt;/p&gt;

&lt;p&gt;the same code as in my post. figured this might be easier to work with. &lt;/p&gt;</comment>
                    <comment id="12410134" author="brentworden" created="Thu, 18 Aug 2005 03:36:17 +0000"  >&lt;p&gt;I think we&apos;re witnessing the accumulation of numerical error.  The cumulative &lt;br/&gt;
probability method uses the textbook definition for its computation: summing &lt;br/&gt;
the point probabilities.  Each of these probabilities results in a small &lt;br/&gt;
numerical error and the process of summing them just exacerbates the error.&lt;/p&gt;

&lt;p&gt;In your case, X ~ hyper(2000, 500, 100) and P(X &amp;lt;= 50) there are 51 small &lt;br/&gt;
errors that, when added together, cause the total sum to be over 1.0.  Also, &lt;br/&gt;
the point probabilities the larger x values (30 - 50) are so small that they &lt;br/&gt;
provide little value to the overall sum, just error.&lt;/p&gt;

&lt;p&gt;I think we can address this problem by simply short-circuiting the summation &lt;br/&gt;
whenever it goes above 1.0.  This will solve the problem of cumulative &lt;br/&gt;
probablities greater than 1 and make the upper tail probabilties correct &lt;br/&gt;
because, again in your case, P(X &amp;gt;= 50) is extremely close to zero.&lt;/p&gt;

&lt;p&gt;What do others think?&lt;/p&gt;</comment>
                    <comment id="12410135" author="microarray@gmail.com" created="Thu, 18 Aug 2005 04:18:19 +0000"  >&lt;p&gt;I think you&apos;re right. it is coming from the accumulation of numerical error. but&lt;br/&gt;
I think the solution should be more complicated than a simple short circuit.&lt;br/&gt;
let&apos;s see an example again:&lt;/p&gt;

&lt;p&gt;if we calculate cumulativeProbability(50) for (6000, 200, 100), the upper tail&lt;br/&gt;
(X&amp;gt;=50) probability will be 1 - cumulativeProbability(50) = 3.37E-11. but if you&lt;br/&gt;
do a sum of the point probabilities using probability(50),(51),...,(100), which&lt;br/&gt;
by textbook definition defines the upper tail, you&apos;ll get 6.02E-49. &lt;br/&gt;
the discrepency, coming from the accumulation of numerical error, results in a&lt;br/&gt;
false estimate of the real cumulative probability, by a factor of E38. true,&lt;br/&gt;
both are very small, but in some cases it would matter for sure. &lt;/p&gt;

&lt;p&gt;that&apos;s why my suggestion is, either we define a new function to the class to&lt;br/&gt;
calculate P(X&amp;gt;=x) for upper tail probability, or we can define the&lt;br/&gt;
cumulativeProbability so that it calculates P(m&amp;lt;=x&amp;lt;=n); in this case if you&lt;br/&gt;
simply want upper or lower tail, just define m or n separately. and I guess&lt;br/&gt;
it&apos;ll help to short-circuit the class so that it won&apos;t produce p&amp;gt;1 or p&amp;lt;0 cases.&lt;/p&gt;

&lt;p&gt;what do you think?&lt;/p&gt;

&lt;p&gt;(In reply to comment #2)&lt;/p&gt;</comment>
                    <comment id="12410136" author="brentworden" created="Fri, 19 Aug 2005 12:16:09 +0000"  >&lt;p&gt;Addressed.  SVN revision 233412.  Committed to MATH_1_1 branch. Added upper &lt;br/&gt;
tail cumulative probability method to HypergeometricDistributionImpl.  Note, &lt;br/&gt;
this new method was not added to the HypergeometricDistribution interface to &lt;br/&gt;
avoid binary incompatiblities with older versions.&lt;/p&gt;</comment>
                    <comment id="12410137" author="microarray@gmail.com" created="Tue, 23 Aug 2005 04:06:06 +0000"  >&lt;p&gt;Thanks for the fix. However I&apos;m still having problems with this. When I compiled&lt;br/&gt;
my code again with the new build (I tried the nightly build of 8-20 and 8-21)&lt;br/&gt;
and try to calculate the cumulativeProbability of 5000 200 100 50, I still got&lt;br/&gt;
the same overflow 1.0000000000134985. &lt;br/&gt;
Initially I guess it&apos;s because Brent Worden has added a new method to calculate&lt;br/&gt;
the upper tail and the current method is untouched? But I can&apos;t find anywhere&lt;br/&gt;
about how to use the new method.&lt;br/&gt;
This post may sound stupid; can anyone tell me whether I&apos;m doing the right thing&lt;br/&gt;
here and the bug is really still here? &lt;/p&gt;

&lt;p&gt;(In reply to comment #4)&lt;br/&gt;
&amp;gt; Addressed.  SVN revision 233412.  Committed to MATH_1_1 branch. Added upper &lt;br/&gt;
&amp;gt; tail cumulative probability method to HypergeometricDistributionImpl.  Note, &lt;br/&gt;
&amp;gt; this new method was not added to the HypergeometricDistribution interface to &lt;br/&gt;
&amp;gt; avoid binary incompatiblities with older versions.&lt;/p&gt;
</comment>
                    <comment id="12410138" author="phil@steitz.com" created="Tue, 23 Aug 2005 05:21:56 +0000"  >&lt;p&gt;The fix was committed to the MATH_1_1 release branch, not to the svn trunk, so&lt;br/&gt;
the nightlies have not picked it up yet.   Once the 1.1 release goes final&lt;br/&gt;
(hopefully very soon), we will merge all of the fixes recently made (including&lt;br/&gt;
this one) back into the main development trunk.&lt;/p&gt;

&lt;p&gt;For now, to test your code, you will have to check out and build using the&lt;br/&gt;
MATH_1_1 branch.  If you need help doing this, or would just like a jar to test&lt;br/&gt;
with, let me know.&lt;/p&gt;</comment>
                    <comment id="12410139" author="microarray@gmail.com" created="Tue, 23 Aug 2005 07:44:19 +0000"  >&lt;p&gt;Ah, I see. so could you please just send me a jar to test with? I don&apos;t know how&lt;br/&gt;
to do it the other way,&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; after all, I&apos;m a newbie to the java world. &lt;br/&gt;
microarray@gmail.com&lt;br/&gt;
Thanks!&lt;/p&gt;

&lt;p&gt;(In reply to comment #6)&lt;/p&gt;</comment>
                    <comment id="12410140" author="microarray@gmail.com" created="Tue, 23 Aug 2005 07:46:06 +0000"  >&lt;p&gt;Oh, I forgot to ask, can you also let me know something about the new upper tail&lt;br/&gt;
method that Brent mentioned? Thanks!&lt;/p&gt;</comment>
                    <comment id="12410141" author="brentworden" created="Tue, 23 Aug 2005 11:37:54 +0000"  >&lt;p&gt;I just merged the changes, including this fix, in the MATH_1_1 branch to the &lt;br/&gt;
trunk.  The next nightly build should contain your fix.&lt;/p&gt;

&lt;p&gt;The actual added method is only found on the HypergeometricDistributionImpl and &lt;br/&gt;
has a signature of:&lt;br/&gt;
public double upperCumulativeProbability(int x);&lt;/p&gt;

&lt;p&gt;It returns P(X &amp;gt;= x).&lt;/p&gt;</comment>
                    <comment id="12410142" author="microarray@gmail.com" created="Wed, 24 Aug 2005 00:29:55 +0000"  >&lt;p&gt;Thanks a lot! you guys rock &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12410143" author="microarray@gmail.com" created="Thu, 25 Aug 2005 07:45:09 +0000"  >&lt;p&gt;I really hate to post this but I think this bug is somewhat hard to catch:&lt;br/&gt;
evolution somehow kicks in......&lt;/p&gt;

&lt;p&gt;check this out: &lt;br/&gt;
before I used the new jar I coded a loop to calculate all the probabilities of&lt;br/&gt;
the upper tail and sum them to get the upper cumPro, just like textbook&lt;br/&gt;
definition, but of course, slow. &lt;br/&gt;
I used the new upperCumulativeProbability method to calculate my example, 5000&lt;br/&gt;
200 100 50. used my old looping way calculation and a perl script to cross&lt;br/&gt;
check. I got exactly the same answer: upper cumPro = 4.407167010070517E-45. Great!!!&lt;br/&gt;
but, as I used it more, ugly bugs showed up: when I calculate 26896 895 55 19,&lt;br/&gt;
the new jar with the fix gave me 3.40373618E-10, my old looping way and the perl&lt;br/&gt;
script says 6.2588249E-15 is right, and the probability(19)= 5.8805728E-15,&lt;br/&gt;
which is a good comfirmation that the second answer is right, because you can&lt;br/&gt;
imagine something with a tail of even smaller than E-15 won&apos;t accumulate to E-10. &lt;/p&gt;

&lt;p&gt;I have absolutely no idea where this comes from now: the fixed jar can calculate&lt;br/&gt;
something as small as 4E-45, as we saw in the first example, which indicates&lt;br/&gt;
accumulation of numeric error is not happening here; without any knowledge of&lt;br/&gt;
the source code (not that I can&apos;t get it, but I won&apos;t be able to understand it&lt;br/&gt;
at all, as a newbie), I have no idea why it would calculate the second case&lt;br/&gt;
wrong. you guys might think &quot;hey, these are values small enough to be taken as&lt;br/&gt;
zero, what&apos;s the difference?!&quot; I guess mathematicall precision is what we&apos;re&lt;br/&gt;
after here. my looping code can do the job, but it&apos;s gonna be tooo slow imagine&lt;br/&gt;
you do this over and over. &lt;/p&gt;

&lt;p&gt;Thanks for everyone&apos;s patience and effort in solving this.&lt;/p&gt;</comment>
                    <comment id="12410144" author="microarray@gmail.com" created="Thu, 25 Aug 2005 07:49:26 +0000"  >&lt;p&gt;oh, another thing I forgot to mention just now: if you calculate something like&lt;br/&gt;
1000 100 1 1, the upper cumPro will return 0. basically, if your query number&lt;br/&gt;
equals to either the number of success or the sample, then you got 0. for these&lt;br/&gt;
cases, the cumPro should just be the probability of this query number. &lt;/p&gt;</comment>
                    <comment id="12410145" author="brentworden" created="Fri, 26 Aug 2005 14:14:33 +0000"  >&lt;p&gt;Fixed.  SVN revision 240613.  Fixed in MATH_1_1 branch.&lt;/p&gt;</comment>
                    <comment id="12410146" author="pkillion@yahoo.com" created="Fri, 26 Aug 2005 19:27:18 +0000"  >&lt;p&gt;will this fix be in the 0826 nightly?  does it address both issues raised by mike hu?&lt;/p&gt;</comment>
                    <comment id="12410147" author="pkillion@yahoo.com" created="Fri, 26 Aug 2005 21:18:46 +0000"  >&lt;p&gt;hello - i show no change in the behavior of the upperCumulativeProbability&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; returning 0.0 when x = &lt;br/&gt;
numsuccess or x = sample size.   i am not sure about the other issue (raised by mike hu on 0825).  &lt;br/&gt;
perhaps the fix did not make the 0826 build or it is still not fixed.&lt;/p&gt;</comment>
                    <comment id="12410148" author="brentworden" created="Fri, 26 Aug 2005 22:25:49 +0000"  >&lt;p&gt;(In reply to comment #15)&lt;/p&gt;

&lt;p&gt;I have not had time to get the fix pushed to the trunk, soit will not be in the &lt;br/&gt;
nightly builds yet.  I hope to get around to this today.&lt;/p&gt;

&lt;p&gt;Both problems have been resolved.  The problem with returning 0 was caused by a &lt;br/&gt;
simple erroneous boundry value check.  The poor accuracy for small cumulative &lt;br/&gt;
probabilities was the result of a truncation error when performing 1.0 - &lt;br/&gt;
verySmallProbability in certain circumstances.&lt;/p&gt;

&lt;p&gt;Of note, the performance for these routines is quite poor for large population &lt;br/&gt;
sizes.  I plan to address these limitations and improve performance post &lt;br/&gt;
release 1.1.&lt;/p&gt;

</comment>
                    <comment id="12410149" author="microarray@gmail.com" created="Sat, 27 Aug 2005 00:39:51 +0000"  >&lt;p&gt;OKay, for the love of Java, let&apos;s see the details of all the bugs. I tend to&lt;br/&gt;
believe they&apos;re not all caught yet, but if I have the jar I can definitely test&lt;br/&gt;
them out. &lt;/p&gt;

&lt;p&gt;for the current build 8-25-05, the code below&lt;br/&gt;
HypergeometricDistributionImpl hDist = new HypergeometricDistributionImpl(26932,&lt;br/&gt;
270, 823);&lt;/p&gt;

&lt;p&gt;        double probability = hDist.probability(52);&lt;br/&gt;
        double utprobability = hDist.upperCumulativeProbability(52);&lt;br/&gt;
        double cprobability = hDist.cumulativeProbability(52);&lt;/p&gt;

&lt;p&gt;        System.out.println(probability);&lt;br/&gt;
        System.out.println(utprobability);&lt;br/&gt;
        System.out.println(cprobability);&lt;br/&gt;
        System.out.println(1 - cprobability);&lt;br/&gt;
will return:&lt;br/&gt;
1.018427824183987E-26&lt;br/&gt;
-2.437485768780334E-10&lt;br/&gt;
1.0000000002437486&lt;br/&gt;
-2.437485768780334E-10&lt;br/&gt;
this shows that in this example, the upper tail cumPro is just 1 - cumPro, which&lt;br/&gt;
is wrong because of the numeric error accumulation we discusse earlier.&lt;/p&gt;

&lt;p&gt;but this is obviously not always happening, as when I tried 6000 200 100 50, it&lt;br/&gt;
returned 6.02E-49, as I expected. what&apos;s the mystery here?&lt;/p&gt;

&lt;p&gt;furthermore, if you run the above code but change it so that it runs&lt;br/&gt;
HypergeometricDistributionImpl hDist = new HypergeometricDistributionImpl(26932,&lt;br/&gt;
823, 270);&lt;br/&gt;
the result will be different:&lt;br/&gt;
1.0184278236099406E-26&lt;br/&gt;
3.7159353372118176E-10&lt;br/&gt;
0.99999999962840647&lt;br/&gt;
3.7159353372118176E-10&lt;br/&gt;
but by textbook definition of hypergeometric distribution, the order of&lt;br/&gt;
numSuccess and sample shouldn&apos;t matter at all, notice here: A. the raw&lt;br/&gt;
probability is slightly different, at the 9th digit; B. this should have&lt;br/&gt;
generated what the earlier calculation had, but it&apos;s totally different.&lt;/p&gt;

&lt;p&gt;so, summarizing the bugs here:&lt;br/&gt;
1. upper tail cumulative probability when running some examples, will overflow&lt;br/&gt;
and give negative values;&lt;br/&gt;
2. upper tail cumPro obviously is not consistently calculating in the same&lt;br/&gt;
fashion, sometimes it works, sometimes not;&lt;br/&gt;
3. the order of numSuccess and sample sometimes matters to the code, while it&lt;br/&gt;
should not, ever;&lt;br/&gt;
4. the raw probability, when change the order of numSuccess and sample, will&lt;br/&gt;
differ slightly, if it&apos;s calculated in exactly the same way then it shouldn&apos;t.&lt;/p&gt;

&lt;p&gt;I suggest that when you have a fix, test it out further with many more examples,&lt;br/&gt;
like what we suggested here, and in reversing order, etc. and if you could send&lt;br/&gt;
me the jar or post it here I can test it out as well, rather than waiting for&lt;br/&gt;
the nightly build to include it. &lt;/p&gt;

&lt;p&gt;pop numSuccess sample query upperCumPro&lt;br/&gt;
26932 823 270 53 1.4160591836816684E-27&lt;br/&gt;
26932 270 823 53&lt;br/&gt;
6000 200 100 50 6.020909331626761E-49&lt;br/&gt;
6000 100 200 50&lt;br/&gt;
26896 895 55 15 2.077516591801479E-10&lt;br/&gt;
26896 55 895 15&lt;/p&gt;</comment>
                    <comment id="12410150" author="microarray@gmail.com" created="Sat, 27 Aug 2005 00:49:09 +0000"  >&lt;p&gt;I saw your post and actually bugzilla told me &lt;br/&gt;
Mid-air collision detected!&lt;br/&gt;
Someone else has made changes to this bug at the same time you were trying to.&lt;br/&gt;
The changes made were:&lt;br/&gt;
pretty cool huh?&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;anyways, it seems like that for some cases your are using 1-small probabilities,&lt;br/&gt;
while in the example I mentioned it&apos;s not calculated this way: why there seems&lt;br/&gt;
to be two ways to calculate this? is it for performance concern? personally I&apos;d&lt;br/&gt;
rather get the accurate answer than saving time, and I&apos;m currently doing the&lt;br/&gt;
slow looping thing to get the right answer.&lt;/p&gt;

&lt;p&gt;thanks!&lt;/p&gt;</comment>
                    <comment id="12410151" author="microarray@gmail.com" created="Mon, 29 Aug 2005 22:53:12 +0000"  >&lt;p&gt;I tested the nightly build 8-29-05. it seems like the bugs I mentioned above are&lt;br/&gt;
all fixed. will post if I get further problems.&lt;/p&gt;

&lt;p&gt;Thanks a lot!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333722" name="HyperGeometricProbability.java" size="1385" author="microarray@gmail.com" created="Wed, 17 Aug 2005 08:43:22 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36215</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 18 Aug 2005 03:36:17 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-99] [math] wrong results and stack overflow error from BivariateRegression</title>
                <link>https://issues.apache.org/jira/browse/MATH-99</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Example:&lt;/p&gt;

&lt;p&gt;import java.util.*;&lt;br/&gt;
import org.apache.commons.math.stat.*;&lt;/p&gt;

&lt;p&gt;public class RegressionTest&lt;br/&gt;
{&lt;/p&gt;


&lt;p&gt;	public static void main(String[] args)&lt;br/&gt;
	{&lt;/p&gt;


&lt;p&gt;		BivariateRegression br1 = new BivariateRegression();&lt;br/&gt;
		BivariateRegression br2 = new BivariateRegression();&lt;/p&gt;


&lt;p&gt;		Random random = new Random(1);&lt;/p&gt;

&lt;p&gt;		int n = 100;&lt;/p&gt;

&lt;p&gt;		for (int i = 0; i &amp;lt; n; i++)&lt;/p&gt;
		{
		
		
			br1.addData(((double)i)/(n-1), i); //perfectly correlated example
			br2.addData(((double)i)/(n-1), random.nextDouble()); //uncorrelated example
			
		
		
		
		}


&lt;p&gt;		System.out.println(br1.getSignificance()); //should return 0, but returns NaN instead&lt;br/&gt;
		System.out.println(br2.getSignificance()); //should return 1, but some sequences cause stack overflow error!&lt;/p&gt;



&lt;p&gt;	}&lt;/p&gt;




&lt;p&gt;}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341098">MATH-99</key>
            <summary>[math] wrong results and stack overflow error from BivariateRegression</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="skarupo@mail.ru">sergei skarupo</reporter>
                        <labels>
                    </labels>
                <created>Mon, 17 Nov 2003 19:14:28 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405467" author="skarupo@mail.ru" created="Mon, 17 Nov 2003 19:16:24 +0000"  >&lt;p&gt;Created an attachment (id=9142)&lt;br/&gt;
unit test source code&lt;/p&gt;</comment>
                    <comment id="12405468" author="skarupo@mail.ru" created="Mon, 17 Nov 2003 19:17:04 +0000"  >&lt;p&gt;Created an attachment (id=9143)&lt;br/&gt;
unit test class file&lt;/p&gt;</comment>
                    <comment id="12405469" author="brentworden" created="Tue, 18 Nov 2003 01:51:59 +0000"  >&lt;p&gt;For the perfect correlation case, the sum of squares error is being computed to &lt;br/&gt;
a negative number because of numerical error (it is a very small number &lt;del&gt;1e&lt;/del&gt;&lt;br/&gt;
11).  So, when the std err. of the slope is computed, a sqrt of a negative &lt;br/&gt;
number is computed resulting in NaN.&lt;/p&gt;

&lt;p&gt;When I get a chance, I&apos;ll review and research the updating formulas we&apos;re using &lt;br/&gt;
to see if they can be improved upon.&lt;/p&gt;


&lt;p&gt;For the random correlation case, the Beta.regularizedBeta routine isn&apos;t &lt;br/&gt;
converging for large a and small b.  I&apos;ll look into that further.&lt;/p&gt;</comment>
                    <comment id="12405470" author="brentworden" created="Tue, 18 Nov 2003 14:04:33 +0000"  >&lt;p&gt;Created an attachment (id=9149)&lt;br/&gt;
This patch fixes both problems&lt;/p&gt;</comment>
                    <comment id="12405471" author="brentworden" created="Tue, 18 Nov 2003 14:07:10 +0000"  >&lt;p&gt;The 11/18 attachment should fix both problems.  It changes the regularizedBeta &lt;br/&gt;
routine to fix the random correlation case and it modifies the &lt;br/&gt;
BivariateRegression sums of squares updating formulas to fix the perfect &lt;br/&gt;
correlation case.&lt;/p&gt;</comment>
                    <comment id="12405472" author="mdiggory@gmail.com" created="Tue, 18 Nov 2003 23:07:33 +0000"  >&lt;p&gt;Applied and Tested&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332623" name="RegressionTest.class" size="720" author="skarupo@mail.ru" created="Mon, 17 Nov 2003 19:17:04 +0000" />
                    <attachment id="12332622" name="RegressionTest.java" size="775" author="skarupo@mail.ru" created="Mon, 17 Nov 2003 19:16:24 +0000" />
                    <attachment id="12332624" name="regression-bug-fixes.txt" size="4415" author="brentworden" created="Tue, 18 Nov 2003 14:04:33 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>24747</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 18 Nov 2003 01:51:59 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-97] [math] Add content to guidelines section in developer.xml</title>
                <link>https://issues.apache.org/jira/browse/MATH-97</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch adds content to the guidelines section of developer.xml,&lt;br/&gt;
including subsections on coding style, documentation, unit tests and licensing.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340749">MATH-97</key>
            <summary>[math] Add content to guidelines section in developer.xml</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 2 Jun 2003 12:53:29 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404331" author="phil@steitz.com" created="Mon, 2 Jun 2003 12:54:14 +0000"  >&lt;p&gt;Created an attachment (id=6591)&lt;br/&gt;
patch to developers.xml&lt;/p&gt;</comment>
                    <comment id="12404332" author="mdiggory@gmail.com" created="Wed, 4 Jun 2003 09:44:39 +0000"  >&lt;p&gt;Applied the first part of this patch. The links were already commited to the&lt;br/&gt;
file earlier.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332304" name="developersPatch.txt" size="5634" author="phil@steitz.com" created="Mon, 2 Jun 2003 12:54:14 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20404</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 4 Jun 2003 09:44:39 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-96] ChiSquareTest does not return</title>
                <link>https://issues.apache.org/jira/browse/MATH-96</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;When executing the following code it never returns:&lt;/p&gt;

&lt;p&gt;try { &lt;br/&gt;
    double[] exp = new double[] {
        3389119.5, 649136.6, 285745.4, 25357364.76, 11291189.78, 543628.0, 
232921.0, 437665.75
    };&lt;/p&gt;

&lt;p&gt;    long[] obs = new long[] {
        2372383, 584222, 257170, 17750155, 7903832, 489265, 209628, 393899
    };&lt;br/&gt;
    org.apache.commons.math.stat.inference.ChiSquareTestImpl csti =&lt;br/&gt;
      new org.apache.commons.math.stat.inference.ChiSquareTestImpl(); &lt;br/&gt;
    double cst = csti.chiSquareTest(exp, obs); &lt;br/&gt;
} catch (org.apache.commons.math.MathException me) {&lt;br/&gt;
    me.printStackTrace();&lt;br/&gt;
}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341492">MATH-96</key>
            <summary>ChiSquareTest does not return</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="scott@duchin.com">Scott Duchin</reporter>
                        <labels>
                    </labels>
                <created>Mon, 7 Jun 2004 07:24:14 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406753" author="brentworden" created="Mon, 7 Jun 2004 08:56:57 +0000"  >&lt;p&gt;The problem is in the Gamma special functions.  For large x values in &lt;br/&gt;
comparison to a values, the regularizedGammaP function never converges to a &lt;br/&gt;
finite sum because the series terms approach numerical infinity.&lt;/p&gt;

&lt;p&gt;IIRC, the algorithm I chose is slow to converge for this particular parameter &lt;br/&gt;
scenario (x &amp;gt;&amp;gt; a).  Long term, I will research a different approach for this &lt;br/&gt;
case and get it integrated into regularizedGammaP.&lt;/p&gt;

&lt;p&gt;Short term, I was going to add a infinite term check to short-circut the &lt;br/&gt;
algorithm and either return infinity or throw an exception from &lt;br/&gt;
regularizedGammaP.  Any input on which choice of inifinity handling is &lt;br/&gt;
preferred?&lt;/p&gt;</comment>
                    <comment id="12406754" author="phil@steitz.com" created="Mon, 7 Jun 2004 09:33:43 +0000"  >&lt;p&gt;The ChiSquare test statistic in this case is 3624883 (rounded).  With df = 7,&lt;br/&gt;
the p-value returned should be effectively 0.  The code actually does terminate,&lt;br/&gt;
when Gamma.regularizedGammaP throws a ConvergenceException.  It takes a &lt;b&gt;long&lt;/b&gt;&lt;br/&gt;
time, however, since the default iteration bound of Integer.MAX_VALUE is used.&lt;/p&gt;

&lt;p&gt;It is not obvious to me how to address this.  Reducing the default max&lt;br/&gt;
iterations above might be a good idea in general; but this would just cause us&lt;br/&gt;
to throw sooneer in the present case, when we should be returning 0.  I am&lt;br/&gt;
inclined to suggest that we force 0 for the p-value (or 1 in the ChiSquare cdf)&lt;br/&gt;
when the value of the test statistic is greater than say, 1000 * df (which is&lt;br/&gt;
500 times the variance) or some such bound.  I will run some tests to see what a&lt;br/&gt;
reasonable bound might be.&lt;/p&gt;</comment>
                    <comment id="12406755" author="phil@steitz.com" created="Mon, 7 Jun 2004 09:38:29 +0000"  >&lt;p&gt;In response to Brent: I think that &quot;returning infinity&quot; would be better than&lt;br/&gt;
throwing.  That way the cdf could return 1 in the present case.  I think this is&lt;br/&gt;
better than dealing with the problem at the test or distribution level as I&lt;br/&gt;
suggeseted.  &lt;/p&gt;</comment>
                    <comment id="12406756" author="brentworden" created="Tue, 8 Jun 2004 03:34:45 +0000"  >&lt;p&gt;I added a regularized gamma function implementation based on a continued &lt;br/&gt;
fraction.  This approach converges much faster for the large x case and fixes &lt;br/&gt;
the problem experienced by Scott.&lt;/p&gt;

&lt;p&gt;I added the example submitted by Scott as a test case and got it and all &lt;br/&gt;
existing test cases to pass with my changes.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29419</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 7 Jun 2004 08:56:57 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-95] [math] BrentSolver and SecantSolver request boundary values from function twice</title>
                <link>https://issues.apache.org/jira/browse/MATH-95</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I&apos;m using the BrentSolver class and I noticed that, when I call the solve() &lt;br/&gt;
method,  it requests the boundary values of the initial interval twice from my &lt;br/&gt;
function. The function is quite expensive so it would be good to avoid these &lt;br/&gt;
two duplicate computations.&lt;/p&gt;

&lt;p&gt;I had a look at the source code (see below) and I can see that &lt;br/&gt;
the &apos;verifyBracketing&apos; check requests the boundary values from the function and &lt;br/&gt;
then the &apos;solve&apos; method itself also requests those values. It looks like the &lt;br/&gt;
SecantSolver will exhibit this behaviour too. Would it be possible to change &lt;br/&gt;
the code so that the values are requested just once?&lt;/p&gt;



&lt;p&gt;BrentSolver.class&lt;/p&gt;

&lt;p&gt;   public double solve(double min, double max) throws ConvergenceException, &lt;br/&gt;
        FunctionEvaluationException {&lt;/p&gt;

&lt;p&gt;        clearResult();&lt;br/&gt;
        verifyBracketing(min, max, f);&lt;/p&gt;

&lt;p&gt;        // Index 0 is the old approximation for the root.&lt;br/&gt;
        // Index 1 is the last calculated approximation  for the root.&lt;br/&gt;
        // Index 2 is a bracket for the root with respect to x1.&lt;br/&gt;
        double x0 = min;&lt;br/&gt;
        double x1 = max;&lt;br/&gt;
        double y0;&lt;br/&gt;
        double y1;&lt;br/&gt;
        y0 = f.value(x0);  // ******* REQUESTS BOUNDARY (MIN) VALUE HERE ****&lt;br/&gt;
        y1 = f.value(x1);  // ******* REQUESTS BOUNDARY (MAX) VALUE HERE ****&lt;/p&gt;


&lt;p&gt;UnivariateRealSolverImpl.class:&lt;/p&gt;

&lt;p&gt;    protected void verifyBracketing(double lower, double upper, &lt;br/&gt;
            UnivariateRealFunction f) throws FunctionEvaluationException {&lt;br/&gt;
        verifyInterval(lower, upper);&lt;br/&gt;
        if (!isBracketing(lower, upper, f)) {
            throw new IllegalArgumentException
            (&quot;Function values at endpoints do not have different signs.&quot; +
                    &quot;  Endpoints: [&quot; + lower + &quot;,&quot; + upper + &quot;]&quot; + 
                    &quot;  Values: [&quot; + f.value(lower) + &quot;,&quot; + f.value(upper) 
+ &quot;]&quot;);       
        }&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;    protected boolean isBracketing(double lower, double upper, &lt;br/&gt;
            UnivariateRealFunction f) throws FunctionEvaluationException {
// ******* REQUESTS BOTH BOUNDARY VALUES HERE ****
        return  (f.value(lower) * f.value(upper) &amp;lt; 0);
    }&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342257">MATH-95</key>
            <summary>[math] BrentSolver and SecantSolver request boundary values from function twice</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="paulf">Paul Field</reporter>
                        <labels>
                    </labels>
                <created>Wed, 25 May 2005 00:17:07 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>1.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12409419" author="brentworden" created="Wed, 25 May 2005 02:41:47 +0000"  >&lt;p&gt;One solution might be to inline isBracketting logic in the verifyBracketing &lt;br/&gt;
method and return a 2-element array comprised of the endpoint evaluations.  The &lt;br/&gt;
solve method could then used these evaluations for initialization.&lt;/p&gt;</comment>
                    <comment id="12409420" author="phil@steitz.com" created="Sat, 4 Jun 2005 14:43:40 +0000"  >&lt;p&gt;Should be fixed in nightly builds starting 4 Jun 05.&lt;br/&gt;
Thanks for reporting this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>35042</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 25 May 2005 02:41:47 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-94] [math] Update task list</title>
                <link>https://issues.apache.org/jira/browse/MATH-94</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Attaching a patch updating tasks.xml&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340811">MATH-94</key>
            <summary>[math] Update task list</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jun 2003 22:37:40 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404574" author="phil@steitz.com" created="Mon, 23 Jun 2003 22:38:26 +0000"  >&lt;p&gt;Created an attachment (id=6937)&lt;br/&gt;
Patch to tasks.xml&lt;/p&gt;</comment>
                    <comment id="12404575" author="mdiggory@gmail.com" created="Wed, 25 Jun 2003 08:51:55 +0000"  >&lt;p&gt;Phil, This patch contains two patches to 2 different versions of the same file,&lt;br/&gt;
one for version 1.4 one for version 1.5. Do you know how it needs to be applied&lt;br/&gt;
or can you provide a single patch that covers the entire changes to this file. &lt;/p&gt;</comment>
                    <comment id="12404576" author="phil@steitz.com" created="Wed, 25 Jun 2003 20:28:37 +0000"  >&lt;p&gt;Created an attachment (id=6970)&lt;br/&gt;
corrected patch file&lt;/p&gt;</comment>
                    <comment id="12404577" author="phil@steitz.com" created="Wed, 25 Jun 2003 20:30:43 +0000"  >&lt;p&gt;Oops! I appended the new patch to an old patch file by mistake.  The new patch&lt;br/&gt;
that I just added includes only the new stuff. Sorry.  -P&lt;/p&gt;</comment>
                    <comment id="12404578" author="mdiggory@gmail.com" created="Wed, 25 Jun 2003 20:34:36 +0000"  >&lt;p&gt;Commited it with one minor change, I already added the array methods to StatUtils.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332380" name="taskListPatch.txt" size="7133" author="phil@steitz.com" created="Mon, 23 Jun 2003 22:38:26 +0000" />
                    <attachment id="12332381" name="tasksPatch.txt" size="5127" author="phil@steitz.com" created="Wed, 25 Jun 2003 20:28:37 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21015</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 25 Jun 2003 08:51:55 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-93] [math] PolynomialSplineFunction.value() throws an exception when requesting final datapoint</title>
                <link>https://issues.apache.org/jira/browse/MATH-93</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The javadocs for this function state that&lt;/p&gt;

&lt;p&gt;&quot;Throws: FunctionEvaluationException - if v is outside of the domain of of the &lt;br/&gt;
spline function (less than the smallest knot point or greater than or equal to &lt;br/&gt;
the largest knot point)&quot;&lt;/p&gt;

&lt;p&gt;I have a series of points, for example ( (12.2,3), (15.4,1.2), (18.9, 4.6)&lt;br/&gt;
) that I need to interpolate some data points from. The problem is that I need &lt;br/&gt;
to be able to interpolate from 12.2 through 18.9 inclusive, right now an &lt;br/&gt;
exception is thrown if I try to evaluate for 18.9, which is exactly what the &lt;br/&gt;
javadocs state should happen. Is there a mathematical reason for being able to &lt;br/&gt;
evaluate the first datapoint but not the last one? Can you point me to a &lt;br/&gt;
reference if that is the case? To me it seems to make sense that it should be &lt;br/&gt;
able to determine the value at one of the knot points, &quot;. &lt;/p&gt;

&lt;p&gt;Comments from Brent Worden:&lt;br/&gt;
I&apos;ve looked over some literature and I agree with you that it does not make &lt;br/&gt;
much sense that the function can not be evaluated at one of the knots.&lt;/p&gt;

&lt;p&gt;Ben has agreed to spend some time working on a patch.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342146">MATH-93</key>
            <summary>[math] PolynomialSplineFunction.value() throws an exception when requesting final datapoint</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ben@csh.rit.edu">Ben Litchfield</reporter>
                        <labels>
                    </labels>
                <created>Wed, 30 Mar 2005 08:34:11 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>1.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12409000" author="phil@steitz.com" created="Wed, 30 Mar 2005 15:09:09 +0000"  >&lt;p&gt;There is no mathematical reason that I can see now (or remember &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; that the&lt;br/&gt;
spline function should not just return the value at the final knot point.  The&lt;br/&gt;
interpolating polynomials are defined on the subintervals determined by the knot&lt;br/&gt;
points, closed on the left and open on the right, which is why the last one&lt;br/&gt;
(which would give the value at the final knot point) is now undefined at the&lt;br/&gt;
final knot point.  This is an implementation detail, however, and unecessary,&lt;br/&gt;
(unless I am forgetting something subtle) since the final polynomial should&lt;br/&gt;
extend by continuity to the final knot point and return the correct value there.&lt;br/&gt;
So I am +1 for this change.  Need to be careful to update all javadoc and unit&lt;br/&gt;
tests if we do this.  Patches welcome!&lt;/p&gt;

&lt;p&gt;See the javadoc for SplineInterpolator for a reference to the interpolation&lt;br/&gt;
algorithm used.&lt;/p&gt;</comment>
                    <comment id="12409001" author="ben@csh.rit.edu" created="Fri, 1 Apr 2005 23:37:04 +0000"  >&lt;p&gt;Created an attachment (id=14606)&lt;br/&gt;
Fix to issue&lt;/p&gt;

&lt;p&gt;I have attached a fix for this issue.  It is fixed by using the last polynomial&lt;br/&gt;
to evaluate the final knot point.  Also junit tests have been updated to check&lt;br/&gt;
the last knot point.&lt;/p&gt;

&lt;p&gt;Ben&lt;/p&gt;</comment>
                    <comment id="12409002" author="brentworden" created="Sat, 2 Apr 2005 06:47:53 +0000"  >&lt;p&gt;Patch applied.  Thanks, Ben.&lt;br/&gt;
(SVN revision 159727)&lt;/p&gt;
</comment>
                </comments>
                    <attachments>
                    <attachment id="12333435" name="SplineFunctionLastKnotPatch.zip" size="5174" author="ben@csh.rit.edu" created="Fri, 1 Apr 2005 23:37:04 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>34230</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 30 Mar 2005 15:09:09 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-92] [math][PATCH] inverseCumulativeProbability for PoissonDistributionImpl Fails for large lambda</title>
                <link>https://issues.apache.org/jira/browse/MATH-92</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The inverseCumulativeProbability for the Poisson distribution is calculated&lt;br/&gt;
through the standard implementation in AbstractIntegerDistribution.  This&lt;br/&gt;
implementation fails with a continue fraction stack overflow for large lambda.&lt;/p&gt;

&lt;p&gt;Instead, I suggest the following override in PoissonDistributionImpl&lt;/p&gt;

&lt;p&gt;/**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Calculate the inverse cumulative probability for the Poisson distribution&lt;/li&gt;
	&lt;li&gt;based on a Cornish-Fisher expansion approximation followed up by a line&lt;/li&gt;
	&lt;li&gt;search.&lt;/li&gt;
	&lt;li&gt;&lt;/li&gt;
	&lt;li&gt;For the Cornish-Fisher expansion see Abramawitz and Stegun&lt;/li&gt;
	&lt;li&gt;&apos;Handbook of Mathmatical Functions&apos; pages 935 and 928&lt;/li&gt;
	&lt;li&gt;&lt;/li&gt;
	&lt;li&gt;@param prob the target probability&lt;/li&gt;
	&lt;li&gt;@return the desired quantile&lt;/li&gt;
	&lt;li&gt;@throws MathException when things go wrong&lt;br/&gt;
 */&lt;br/&gt;
private int inverseCumulativeProbability(double prob) throws MathException{&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;    if (prob &amp;lt; 0.0 || prob &amp;gt;= 1.0)&lt;br/&gt;
        throw new MathException(&quot;Probability must be in right-side open interval&lt;br/&gt;
[0.0, 1.0)&quot;);&lt;/p&gt;

&lt;p&gt;    if (prob == 0) return 0;  // there is nothing to calculate&lt;/p&gt;

&lt;p&gt;    // Use the Cornish-Fisher Expansion with two terms to get a very good&lt;br/&gt;
approximation&lt;br/&gt;
    // see Abramawitz and Stegun &apos;Handbook of Mathmatical Functions&apos;&lt;br/&gt;
    // pages 935 and 928&lt;br/&gt;
    double mu = this.getMean();         // mean&lt;br/&gt;
    double sigma = Math.sqrt(mu);       // standard deviation&lt;br/&gt;
    double gamma = 1.0/Math.sqrt(mu);   // skewness&lt;/p&gt;

&lt;p&gt;    double z = new NormalDistributionImpl(0.0,&lt;br/&gt;
1.0).inverseCumulativeProbability(prob);&lt;br/&gt;
    // this is the actual expansion&lt;br/&gt;
    // the floor(... + 0.5) operation is the continuity correction&lt;br/&gt;
    int y = (int) Math.floor(mu + sigma*(z + gamma*(z*z - 1.0)/6.0) + 0.5);&lt;/p&gt;

&lt;p&gt;    // Given this starting point, line search to the right or left.&lt;br/&gt;
    // Bisection search is not necessary, since the approximation is rarely &lt;br/&gt;
    // off by more than 1 or 2&lt;br/&gt;
    z = this.cumulativeProbability&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/thumbs_up.gif&quot; height=&quot;19&quot; width=&quot;19&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;;&lt;/p&gt;

&lt;p&gt;    if ( z &amp;gt; prob) { // missed it to the right, search to the left&lt;br/&gt;
        while(true) {
            if (y == 0 || this.cumulativeProbability(y - 1) &amp;lt; prob)
                return y;
            y--;
        }&lt;br/&gt;
    } else { // missed it to the left, search to the right&lt;br/&gt;
        while(true) {
            y++;
            if (this.cumulativeProbability(y) &amp;gt;= prob)
                return y;
        }&lt;br/&gt;
    }&lt;br/&gt;
}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342453">MATH-92</key>
            <summary>[math][PATCH] inverseCumulativeProbability for PoissonDistributionImpl Fails for large lambda</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mikael@amazon.com">Mikael Weigelt</reporter>
                        <labels>
                    </labels>
                <created>Wed, 10 Aug 2005 02:44:51 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410057" author="brentworden" created="Wed, 10 Aug 2005 06:57:09 +0000"  >&lt;p&gt;Thanks.  &lt;/p&gt;

&lt;p&gt;Unfortunately, I tried adding that method to PoissonDistributionImpl but it &lt;br/&gt;
resulted in unit test errors.  Most of the errors dealt with boundry conditions &lt;br/&gt;
and degenerative cases.&lt;/p&gt;

&lt;p&gt;Can you try to modify your code so that is passes these test as well as add &lt;br/&gt;
some more tests for your large mean case?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;
</comment>
                    <comment id="12410058" author="brentworden" created="Wed, 17 Aug 2005 13:53:21 +0000"  >&lt;p&gt;Fixed. SVN Revision 233131. Added to MATH_1_1 branch.&lt;/p&gt;

&lt;p&gt;Continued fractions convergents were diverging because of infinite intermediate &lt;br/&gt;
computations.  To solve this, if infinite computations are detected, linear &lt;br/&gt;
scaling is performed to lessen the magnitude of these computations.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36105</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 10 Aug 2005 06:57:09 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-91] [math] DoubleArray: Document RuntimeException</title>
                <link>https://issues.apache.org/jira/browse/MATH-91</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Even though we don&apos;t have to, it is a good idea in the JavaDoc to document the &lt;br/&gt;
exact conditions under which a RuntimeException such as IllegalArgumentE or &lt;br/&gt;
ArrayOutOfBoundsE can be thrown.  Specifically, getElement() needs an explicit &lt;br/&gt;
description of when aoobe can be thrown.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341448">MATH-91</key>
            <summary>[math] DoubleArray: Document RuntimeException</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tobrien@discursive.com">Tim O&apos;Brien</reporter>
                        <labels>
                    </labels>
                <created>Sat, 15 May 2004 23:14:56 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406606" author="brentworden" created="Mon, 17 May 2004 22:34:13 +0000"  >&lt;p&gt;If/When this task is undertaken, one might need to add the exceptions to the &lt;br/&gt;
throws clause, otherwise, I think a warning appears in the javadoc report and &lt;br/&gt;
quite possibly in the checkstyle report.  If the exceptions aren&apos;t added, I&apos;m &lt;br/&gt;
sure the checkstyle warning could be suppressed but I&apos;m unsure about the &lt;br/&gt;
javadoc warnings.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29013</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 17 May 2004 22:34:13 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-89] [math] PolynomialSplineFunction does not implement DifferentiableUnivariateRealFunction</title>
                <link>https://issues.apache.org/jira/browse/MATH-89</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;DifferentiableUnivariateRealFunction declares one method:&lt;/p&gt;

&lt;p&gt;UnivariateRealFunction derivative();&lt;/p&gt;

&lt;p&gt;PolynomialSplineFunction has this method, but it only implements &lt;br/&gt;
UnivariateRealFunction, not DifferentiableUnivariateRealFunction.&lt;/p&gt;

&lt;p&gt;This has not caused any problems for me, but it seems like something that &lt;br/&gt;
should be changed.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342661">MATH-89</key>
            <summary>[math] PolynomialSplineFunction does not implement DifferentiableUnivariateRealFunction</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="wboyce@panix.com">Willis Blackburn</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Oct 2005 23:39:41 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>1.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410712" author="phil@steitz.com" created="Fri, 25 Nov 2005 01:04:49 +0000"  >&lt;p&gt;Thanks for pointing this out.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37255</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 25 Nov 2005 01:04:49 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-88] [math] Add sign() method to MathUtils</title>
                <link>https://issues.apache.org/jira/browse/MATH-88</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;While implementing Ridders&apos; method for root finding, I encountered a need for a&lt;br/&gt;
function that would return +1 or -1 depending on the sign of its argument.  I&lt;br/&gt;
started a MathUtility class to hold such things, but Phil beat me to the punch&lt;br/&gt;
by submitting MathUtils, so I am submitting additions to his class.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12340757">MATH-88</key>
            <summary>[math] Add sign() method to MathUtils</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hotfusionman@yahoo.com">Albert Davidson Chou</reporter>
                        <labels>
                    </labels>
                <created>Thu, 5 Jun 2003 14:20:06 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404363" author="mdiggory@gmail.com" created="Thu, 5 Jun 2003 21:09:25 +0000"  >&lt;p&gt;Is there a patch for this yet?&lt;/p&gt;</comment>
                    <comment id="12404364" author="hotfusionman@yahoo.com" created="Fri, 6 Jun 2003 03:58:25 +0000"  >&lt;p&gt;Created an attachment (id=6654)&lt;br/&gt;
In good TDD style, submitting test cases for new sign method before code&lt;/p&gt;</comment>
                    <comment id="12404365" author="hotfusionman@yahoo.com" created="Fri, 6 Jun 2003 03:59:51 +0000"  >&lt;p&gt;Created an attachment (id=6655)&lt;br/&gt;
patch to implement sign method&lt;/p&gt;</comment>
                    <comment id="12404366" author="mdiggory@gmail.com" created="Fri, 6 Jun 2003 04:40:41 +0000"  >&lt;p&gt;I&apos;ll apply these and run the tests. But here are some comments.&lt;/p&gt;

&lt;p&gt;1.) I suspect your using diff directly, I would recommend using cvs diff, this&lt;br/&gt;
way your diffs are built directly against the current cvs versions and not a&lt;br/&gt;
local copy (which I&apos;m assuming is where the .java~2~ extensions are coming&lt;br/&gt;
from), this will also generate a header in your diff that looks similar to the&lt;br/&gt;
following&lt;/p&gt;

&lt;p&gt;Index: MathUtilsTest.java&lt;br/&gt;
===================================================================&lt;br/&gt;
RCS file:&lt;br/&gt;
/home/cvs/jakarta-commons-sandbox/math/src/test/org/apache/commons/math/MathUtilsTest.java,v&lt;br/&gt;
retrieving revision 1.1&lt;br/&gt;
diff -u -r1.1 MathUtilsTest.java&lt;br/&gt;
&amp;#8212; MathUtilsTest.java  2003-06-03 13:39:19.000000000 -0700&lt;br/&gt;
+++ MathUtilsTest.java	2003-06-04 23:45:33.000000000 -0700&lt;/p&gt;

&lt;p&gt;2.) Try to generate your patches from the root of the project (at the level of&lt;br/&gt;
the math directory), not at the individual file level. Then you do not need to&lt;br/&gt;
submit separate patches for each file.&lt;/p&gt;

&lt;p&gt;This will help me to be able to quickly apply your patches.&lt;/p&gt;

&lt;p&gt;Cheers and thank you for your excellent efforts,&lt;br/&gt;
Mark&lt;/p&gt;</comment>
                    <comment id="12404367" author="hotfusionman@yahoo.com" created="Fri, 6 Jun 2003 05:58:03 +0000"  >&lt;p&gt;OK, will do.  Still inexperienced with CVS and mainstream software engineering&lt;br/&gt;
practices, having come from a world where software engineering is largely&lt;br/&gt;
unknown (scientific computing).&lt;/p&gt;</comment>
                    <comment id="12404368" author="mdiggory@gmail.com" created="Fri, 6 Jun 2003 06:31:08 +0000"  >&lt;p&gt;Same here, I didn&apos;t learn this stuff until I had to participate on software&lt;br/&gt;
development projects directly. Hey, it looks good on a resume&apos; when you can say&lt;br/&gt;
you&apos;ve worked with all these tools. &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; &lt;/p&gt;

&lt;p&gt;Here&apos;s some good reading &quot;fodder&quot; on cvs diff/patch at Apache&lt;br/&gt;
&lt;a href=&quot;http://cocoon.apache.org/2.0/howto/howto-patch.html&quot;&gt;http://cocoon.apache.org/2.0/howto/howto-patch.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Jakarta&apos;s isn&apos;t quite as detailed.&lt;br/&gt;
&lt;a href=&quot;http://jakarta.apache.org/site/source.html&quot;&gt;http://jakarta.apache.org/site/source.html&lt;/a&gt;&lt;/p&gt;
</comment>
                    <comment id="12404369" author="mdiggory@gmail.com" created="Fri, 6 Jun 2003 10:11:00 +0000"  >&lt;p&gt;Commited and Unit-Tested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332309" name="MathUtils.diff" size="12492" author="hotfusionman@yahoo.com" created="Fri, 6 Jun 2003 03:59:51 +0000" />
                    <attachment id="12332308" name="MathUtilsTest.diff" size="7216" author="hotfusionman@yahoo.com" created="Fri, 6 Jun 2003 03:58:25 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20496</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 5 Jun 2003 21:09:25 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-87] [math]TTest should support paired and homoscedastic tests</title>
                <link>https://issues.apache.org/jira/browse/MATH-87</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The TTest interface and implementation support only non-paired, unequal variance&lt;br/&gt;
tests.  The javadoc should make this clearer.  Support for paired sample tests&lt;br/&gt;
and tests under the assumption of equal subpopulation variances should also be&lt;br/&gt;
supported.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341454">MATH-87</key>
            <summary>[math]TTest should support paired and homoscedastic tests</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 18 May 2004 11:26:39 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406624" author="phil@steitz.com" created="Mon, 24 May 2004 12:38:04 +0000"  >&lt;p&gt;Support for paired t-tests has been added.&lt;/p&gt;</comment>
                    <comment id="12406625" author="phil@steitz.com" created="Sun, 6 Jun 2004 02:41:20 +0000"  >&lt;p&gt;Added equalVariances flag to enable homo/heteroscedastic tests, improved&lt;br/&gt;
javadoc, updated user guide to reflect changes.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29049</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-86] [math] improvements to UnivariateImpl</title>
                <link>https://issues.apache.org/jira/browse/MATH-86</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch includes the following improvements to Univariate and&lt;br/&gt;
UnivariateImpl:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Improved efficiency of min, max and product maintenance when windowSize is&lt;br/&gt;
  limited by incorporating suggestion posted to commons-dev by Brend Worden &lt;br/&gt;
  (added author credit).  Thanks, Brent!&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Added javadoc specifying NaN contracts for all statistics, definitions for&lt;br/&gt;
  geometric and arithmetic means.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Made some slight modifications to UnivariateImpl to make it consistent with&lt;br/&gt;
  NaN contracts&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;All interface documentation moved to Univariate. The interface specification&lt;br/&gt;
  includes the NaN semantics and a first attempt at clealy defining exactly what&lt;br/&gt;
  &quot;rolling&quot; means and how this effects what statistics are defined when.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Added test cases to verify that min, max, product are correctly maintained&lt;br/&gt;
  when &quot;rolling&quot; and to verify that NaN contracts are satisfied.&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340723">MATH-86</key>
            <summary>[math] improvements to UnivariateImpl</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Fri, 23 May 2003 15:16:56 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404277" author="phil@steitz.com" created="Fri, 23 May 2003 15:18:02 +0000"  >&lt;p&gt;Created an attachment (id=6466)&lt;br/&gt;
Patches for UnivariateImpl, Univariate, UnivariateImplTest&lt;/p&gt;</comment>
                    <comment id="12404278" author="tobrien@discursive.com" created="Sat, 24 May 2003 02:09:12 +0000"  >&lt;p&gt;Patch Submitted, thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332284" name="UnivariatePatches.txt" size="17851" author="phil@steitz.com" created="Fri, 23 May 2003 15:18:02 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20175</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 24 May 2003 02:09:12 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-85] [math]  SimpleRegression getSumSquaredErrors</title>
                <link>https://issues.apache.org/jira/browse/MATH-85</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;getSumSquaredErrors returns -ve value. See test below:&lt;/p&gt;

&lt;p&gt;public void testSimpleRegression() {&lt;br/&gt;
		double[] y = {  8915.102, 8919.302, 8923.502};&lt;br/&gt;
		double[] x = { 1.107178495, 1.107264895, 1.107351295};&lt;br/&gt;
		double[] x2 = { 1.107178495E2, 1.107264895E2, 1.107351295E2};&lt;br/&gt;
		SimpleRegression reg = new SimpleRegression();&lt;br/&gt;
		for (int i = 0; i &amp;lt; x.length; i++) {
			reg.addData(x[i],y[i]);
		}&lt;br/&gt;
		assertTrue(reg.getSumSquaredErrors() &amp;gt;= 0.0); // OK&lt;br/&gt;
		reg.clear();&lt;br/&gt;
		for (int i = 0; i &amp;lt; x.length; i++) {
			reg.addData(x2[i],y[i]);
		}&lt;br/&gt;
		assertTrue(reg.getSumSquaredErrors() &amp;gt;= 0.0); // FAIL&lt;/p&gt;

&lt;p&gt;	}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows 2000&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12343055">MATH-85</key>
            <summary>[math]  SimpleRegression getSumSquaredErrors</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mark.osborn@research.ge.com">Mark Osborn</reporter>
                        <labels>
                    </labels>
                <created>Fri, 28 Apr 2006 00:00:55 +0000</created>
                <updated>Thu, 6 Jul 2006 12:11:34 +0000</updated>
                    <resolved>Thu, 6 Jul 2006 12:11:34 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12419184" author="luc" created="Wed, 5 Jul 2006 04:15:40 +0000"  >&lt;p&gt;The problem is related to computation accuracy in a corner case.&lt;/p&gt;

&lt;p&gt;The data (110.7178495, 8915.102), (110.7264895, 8919.302), (110.7351295, 8923.502) represent three points on a perfect straigth line, with the second point exactly at the middle of the two extreme points. In this case, the sum of the squares of the errors should be exactly 0 as all points lie exactly on the estimated line.&lt;/p&gt;

&lt;p&gt;If instead of checking reg.getSumSquaredErrors() &amp;gt;= 0.0 I print the value, I get -7.105427357601002E-15 on my GNU/Linux box. This seems quite fair for me as the computation involves computing a subtraction close to 35.28 - 35.28, where both terms result from several former computations. This is consistent with double precision.&lt;/p&gt;

&lt;p&gt;What we observe here is simply a cancellation effect on subtraction. The result is null in the first part of the test (where the x values are 100 times smaller), slightly negative in the second part. I think the null result in the first part is only good fortune (well, it is really related to the orders of magnitude involved: x^2, y^2 and xy).&lt;/p&gt;

&lt;p&gt;I suggest to consider this is not a bug.&lt;br/&gt;
I will add a patch with a slightly modified test case in a few minutes.&lt;/p&gt;</comment>
                    <comment id="12419185" author="luc" created="Wed, 5 Jul 2006 04:19:26 +0000"  >&lt;p&gt;patch adding a test case for issue &lt;a href=&quot;https://issues.apache.org/jira/browse/MATH-85&quot; title=&quot;[math]  SimpleRegression getSumSquaredErrors&quot;&gt;&lt;del&gt;MATH-85&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="12419186" author="psteitz" created="Wed, 5 Jul 2006 04:35:15 +0000"  >&lt;p&gt;I agree this is a corner case and the negative result is due to rounding.  The question is, should we force the result to 0 when a negative value is returned by the computation? &lt;/p&gt;</comment>
                    <comment id="12419401" author="psteitz" created="Thu, 6 Jul 2006 12:11:33 +0000"  >&lt;p&gt;Constrained returned result to be non-negative.  &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12336345" name="math-85.patch" size="1144" author="luc" created="Wed, 5 Jul 2006 04:19:26 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>39432</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 5 Jul 2006 04:15:40 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-84] [math] javadoc and checkstyle changes</title>
                <link>https://issues.apache.org/jira/browse/MATH-84</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;fixed most all checkstyle errors.  Also, add some more checks to the checkstyle &lt;br/&gt;
config.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12340943">MATH-84</key>
            <summary>[math] javadoc and checkstyle changes</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Sat, 6 Sep 2003 12:37:49 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:11 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:11 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404996" author="brentworden" created="Sat, 6 Sep 2003 12:38:20 +0000"  >&lt;p&gt;Created an attachment (id=8079)&lt;br/&gt;
the patch file&lt;/p&gt;</comment>
                    <comment id="12404997" author="mdiggory@gmail.com" created="Sun, 7 Sep 2003 10:15:58 +0000"  >&lt;p&gt;I&apos;ll apply these. Thanks Brent.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332502" name="checkstyle-patch.txt" size="33839" author="brentworden" created="Sat, 6 Sep 2003 12:38:20 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>22954</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 7 Sep 2003 10:15:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-83] [math][patch] MathUtils Javadoc and minor correction to an indicator method</title>
                <link>https://issues.apache.org/jira/browse/MATH-83</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Some additions and fixes for javadoc in the MathUtils class, and a fix for a&lt;br/&gt;
minor bug in the indicator method used for short values.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12341386">MATH-83</key>
            <summary>[math][patch] MathUtils Javadoc and minor correction to an indicator method</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="cschuck@stny.rr.com">Christopher Schuck</reporter>
                        <labels>
                    </labels>
                <created>Mon, 5 Apr 2004 09:19:43 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:10 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:10 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406401" author="cschuck@stny.rr.com" created="Mon, 5 Apr 2004 09:20:53 +0000"  >&lt;p&gt;Created an attachment (id=11130)&lt;br/&gt;
unified cvs diff file for the patch&lt;/p&gt;</comment>
                    <comment id="12406402" author="phil@steitz.com" created="Mon, 5 Apr 2004 10:49:34 +0000"  >&lt;p&gt;Patch applied, thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332860" name="mupatch" size="12566" author="cschuck@stny.rr.com" created="Mon, 5 Apr 2004 09:20:53 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>28194</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 5 Apr 2004 10:49:34 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-81] [math] eliminate some author tags</title>
                <link>https://issues.apache.org/jira/browse/MATH-81</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch eliminates my author tags&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340842">MATH-81</key>
            <summary>[math] eliminate some author tags</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 7 Jul 2003 14:53:56 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:08 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:08 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404679" author="phil@steitz.com" created="Mon, 7 Jul 2003 14:55:06 +0000"  >&lt;p&gt;Created an attachment (id=7114)&lt;br/&gt;
Patch removing some author tags&lt;/p&gt;</comment>
                    <comment id="12404680" author="mdiggory@gmail.com" created="Mon, 7 Jul 2003 20:45:00 +0000"  >&lt;p&gt;Hey Phil, I want to wait just a hair on this till we get a response from Tim,&lt;br/&gt;
his question was a little ambiguous and I&apos;d rather see people get credit where&lt;br/&gt;
its due for their efforts (esp those who are submitting patches).&lt;/p&gt;</comment>
                    <comment id="12404681" author="mdiggory@gmail.com" created="Tue, 8 Jul 2003 06:13:59 +0000"  >&lt;p&gt;Phil, I was about to apply this patch. Are you sure you want to remove your name&lt;br/&gt;
from the contributors section of the project.xml? I&apos;ll apply the patch but not&lt;br/&gt;
alter the project.xml.&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;</comment>
                    <comment id="12404682" author="tobrien@discursive.com" created="Tue, 8 Jul 2003 21:56:01 +0000"  >&lt;p&gt;Just to clarify, I think that some level of attribution is somewhat essential &lt;br/&gt;
in this community.  I think the contributor&apos;s list in project.xml is an &lt;br/&gt;
appropriate place for listing contributors.&lt;/p&gt;

&lt;p&gt;In general, I&apos;m swayed by the arguments on community@ against author tags at &lt;br/&gt;
the code level.  If we want this effort to scale to more developers, 20+ it &lt;br/&gt;
makes sense to get rid of author tags at the code level and increase &lt;br/&gt;
attribution in our site documentation. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332407" name="authorPatch.txt" size="21384" author="phil@steitz.com" created="Mon, 7 Jul 2003 14:55:06 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21360</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 7 Jul 2003 20:45:00 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-80] [Math] some initial code</title>
                <link>https://issues.apache.org/jira/browse/MATH-80</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Some initial stuff for commons-sandbox/math &amp;#8211; more to follow.&lt;/p&gt;

&lt;p&gt;Freq, Univariate, RealMatrix, RealMatriximpl classes plus test cases.&lt;/p&gt;

&lt;p&gt;RealMatrixImpl is missing inversion and some other key functionality.  Interface&lt;br/&gt;
is also a bit &quot;spartan&quot;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340705">MATH-80</key>
            <summary>[Math] some initial code</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 13 May 2003 00:22:30 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:08 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:08 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404229" author="phil@steitz.com" created="Tue, 13 May 2003 00:24:07 +0000"  >&lt;p&gt;Created an attachment (id=6325)&lt;br/&gt;
tar including sources for classes and tests&lt;/p&gt;</comment>
                    <comment id="12404230" author="phil@steitz.com" created="Tue, 13 May 2003 00:25:26 +0000"  >&lt;p&gt;Created an attachment (id=6326)&lt;br/&gt;
diff to add MathTestSuite to build.xml&lt;/p&gt;</comment>
                    <comment id="12404231" author="rdonkin@apache.org" created="Tue, 13 May 2003 03:14:23 +0000"  >&lt;p&gt;committed. thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332266" name="buildPatch.txt" size="633" author="phil@steitz.com" created="Tue, 13 May 2003 00:25:26 +0000" />
                    <attachment id="12332265" name="src.tar" size="122880" author="phil@steitz.com" created="Tue, 13 May 2003 00:24:07 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>19859</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 13 May 2003 03:14:23 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-79] [Math] homoscedasticTTest method uses non homoscedastic method</title>
                <link>https://issues.apache.org/jira/browse/MATH-79</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;In TTestImpl, implementation of the method: &lt;br/&gt;
  double homoscedasticTTest(double,double,double,double,double,double)&lt;br/&gt;
calls method:&lt;br/&gt;
  t(double,double,double,double,double,double)&lt;br/&gt;
where one could expect it to call:&lt;br/&gt;
  homoscedasticT(double,double,double,double,double,double)&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342215">MATH-79</key>
            <summary>[Math] homoscedasticTTest method uses non homoscedastic method</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gillesgaillard@compuserve.com">Gilles Gaillard</reporter>
                        <labels>
                    </labels>
                <created>Fri, 29 Apr 2005 19:40:32 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:08 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:08 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12409251" author="phil@steitz.com" created="Mon, 2 May 2005 14:19:05 +0000"  >&lt;p&gt;Good catch - yes, this should use the homoscedastic t statistic. Previous test&lt;br/&gt;
case masked the error, as the t statistics took the same value.  Code has been&lt;br/&gt;
fixed and test cases made more sensitive. &lt;/p&gt;

&lt;p&gt;Fixed in nightly builds starting 02-may-2005.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>34677</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 2 May 2005 14:19:05 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-78] [math] serialization tests did not delete temp files</title>
                <link>https://issues.apache.org/jira/browse/MATH-78</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;There are some TestUtils.serializeAndRecover() calls in the test files.&lt;br/&gt;
They create temp files like test10487.ser in user temp directory&lt;br/&gt;
java.io.tmpdir (total of 127 for a complete build right now). They are&lt;br/&gt;
not removed after the build is finished, succeeded or not. They should&lt;br/&gt;
be deleted.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342452">MATH-78</key>
            <summary>[math] serialization tests did not delete temp files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Tue, 9 Aug 2005 01:55:09 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:08 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:08 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410056" author="brentworden" created="Sat, 13 Aug 2005 13:08:08 +0000"  >&lt;p&gt;Fixed.  SVN revision 232415.  Temp files were not being deleted because open &lt;br/&gt;
file streams were not being closed properly.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36084</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 13 Aug 2005 13:08:08 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-77] [math][patch] Interpolation Source Files</title>
                <link>https://issues.apache.org/jira/browse/MATH-77</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Add ExpFunction.java&lt;br/&gt;
Add NevilleInterpolator.java&lt;br/&gt;
Add NevilleInterpolatorTest.java&lt;br/&gt;
Add PolynomialFunctionLagrangeForm.java&lt;br/&gt;
Add PolynomialFunctionLagrangeFormTest.java&lt;/p&gt;

&lt;p&gt;ExpFunction.java is in the same directory of NevilleInterpolatorTest.java&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342463">MATH-77</key>
            <summary>[math][patch] Interpolation Source Files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Sat, 13 Aug 2005 02:48:44 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:08 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:08 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410087" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 02:49:15 +0000"  >&lt;p&gt;Created an attachment (id=16022)&lt;br/&gt;
Interpolation Source Files&lt;/p&gt;</comment>
                    <comment id="12410088" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 06:45:31 +0000"  >&lt;p&gt;Files added (without change, revision pending)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333708" name="Interpolation.zip" size="7974" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 02:49:15 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36167</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Aug 2005 06:45:31 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-76] [math] Improve performance, flexibility of discovery impl</title>
                <link>https://issues.apache.org/jira/browse/MATH-76</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Use of commons-discovery to implement pluggable factories in &lt;span class=&quot;error&quot;&gt;&amp;#91;math&amp;#93;&lt;/span&gt; should be &lt;br/&gt;
modified throughout to catch ClassNotFoundException and to cache instances &lt;br/&gt;
(&quot;newInstance&quot; should be replaced by &quot;getInstance&quot;).&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341458">MATH-76</key>
            <summary>[math] Improve performance, flexibility of discovery impl</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Wed, 19 May 2004 01:43:14 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406636" author="phil@steitz.com" created="Wed, 19 May 2004 01:47:23 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-1307 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12406637" author="mdiggory@gmail.com" created="Sun, 6 Jun 2004 07:37:17 +0000"  >&lt;p&gt;My major concern is that there are multiple usecases here, even in your code&lt;br/&gt;
example:&lt;/p&gt;

&lt;p&gt;DistributionFactory factory = DistributionFactory.newInstance();&lt;/p&gt;

&lt;p&gt;vs.&lt;/p&gt;

&lt;p&gt;DistributionFactory factory = DistributionFactory.getInstance();&lt;/p&gt;

&lt;p&gt;Here, the first case may construct a DistributionFactory where some internal&lt;br/&gt;
state/environment is maintained which makes it different than another&lt;br/&gt;
DistributionFactory. You can see this sort of case in examples such as SAX and&lt;br/&gt;
JAXP where the Factory instance is configurable and produces objects with&lt;br/&gt;
different states. &lt;/p&gt;

&lt;p&gt;In another example, with DescriptiveStatistics.newInstance() we have an issue&lt;br/&gt;
where the instantiated factory is also the object, it has unique state we want&lt;br/&gt;
to maintain multiple instances of the object. Having these methods be&lt;br/&gt;
getInstance instead of newInstance would be very limiting.&lt;/p&gt;

&lt;p&gt;Right now DistributionFactory has no state that would make it anymore unique&lt;br/&gt;
than any other distribution factory. Which makes me think your suggested change&lt;br/&gt;
would be fine. But, maybe we should evaluate if we think a Factory is going to&lt;br/&gt;
have greater capability or configurability in the future and try not to shoot&lt;br/&gt;
ourselves in the foot by limiting it to a singleton status.&lt;/p&gt;

&lt;p&gt;Finally, I wonder, if your going to reuse the object as a singleton, do&lt;br/&gt;
synchronous issues arise with concurrent access via the methods in the factory?&lt;/p&gt;

&lt;p&gt;I feel we should do a review and identify the Factories we would approach this&lt;br/&gt;
with and bring up discussion on each. Maybe we should try to identify the types&lt;br/&gt;
of factories we want to maintain.  There should be some analysis applied to&lt;br/&gt;
determine if the Factory instance is configurable. If it is, then &quot;newInstance&quot;&lt;br/&gt;
should be maintained. If not, the getInstance could be appropriate in cases&lt;br/&gt;
where reuse can occur.&lt;/p&gt;


&lt;p&gt;Singleton Factory:&lt;br/&gt;
factory backed by a singleton instances of itself&lt;/p&gt;

&lt;p&gt;Configurable Factory:&lt;br/&gt;
factory which can produce uniquely configured instances of itself&lt;/p&gt;

&lt;p&gt;???&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;</comment>
                    <comment id="12406638" author="phil@steitz.com" created="Sun, 11 Jul 2004 01:23:10 +0000"  >&lt;p&gt;Implementation have been changed to catch NoClassDefFound error.  Consensus is&lt;br/&gt;
that caching instances reduces flexibility and should be left to the client. &lt;br/&gt;
Closing bug as FIXED, though the caching part is really WONTFIX.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29068</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Jun 2004 07:37:17 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-74] [math] Findbugs report</title>
                <link>https://issues.apache.org/jira/browse/MATH-74</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Just out of curiosity, I ran findbugs 0.9.2-RC3 on the code (see below)&lt;/p&gt;

&lt;p&gt;The report shows that there are many uses of == or != for double comparisons.&lt;/p&gt;

&lt;p&gt;As far as I can see, most of these can be avoided (e.g. MathUtils.roundUnscaled&lt;br/&gt;
has the parameter &quot;double sign&quot; which is effectively only used as boolean)&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342529">MATH-74</key>
            <summary>[math] Findbugs report</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sebb@apache.org">Sebb</reporter>
                        <labels>
                    </labels>
                <created>Sun, 4 Sep 2005 22:36:37 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410329" author="sebb@apache.org" created="Sun, 4 Sep 2005 22:38:31 +0000"  >&lt;p&gt;Created an attachment (id=16301)&lt;br/&gt;
Summary output from Findbugs report&lt;/p&gt;</comment>
                    <comment id="12410330" author="phil@steitz.com" created="Mon, 5 Sep 2005 02:29:18 +0000"  >&lt;p&gt;Thanks!&lt;/p&gt;

&lt;p&gt;I am attaching an annotated version.  Some of the issues are real, IMHO and&lt;br/&gt;
should be fixed before 1.1.  Other &lt;span class=&quot;error&quot;&gt;&amp;#91;math&amp;#93;&lt;/span&gt; contributors, pls weigh in.&lt;/p&gt;</comment>
                    <comment id="12410331" author="phil@steitz.com" created="Mon, 5 Sep 2005 02:30:42 +0000"  >&lt;p&gt;Created an attachment (id=16303)&lt;br/&gt;
Annotated findbugs report&lt;/p&gt;</comment>
                    <comment id="12410332" author="j3322ptm@yahoo.de" created="Mon, 5 Sep 2005 05:14:59 +0000"  >&lt;p&gt;&amp;gt; 1,MS: org.apache.commons.math.linear.RealMatrixImpl.TOO_SMALL isn&apos;t&lt;br/&gt;
&amp;gt; final but should be&lt;br/&gt;
&amp;gt; * Should probably be fixed, but can&apos;t (backward compat.)&lt;br/&gt;
Why can&apos;t this be fixed? Is anybody likely to override this?&lt;/p&gt;

&lt;p&gt;&amp;gt; 3,FE: Test for floating point equality in&lt;br/&gt;
&amp;gt; org.apache.commons.math.analysis.BrentSolver.solve(double,double).&lt;br/&gt;
&amp;gt; * By design. Not a real problem.  J - pls confirm.&lt;br/&gt;
I copied this from the text book. The case seems mainly to deal with the&lt;br/&gt;
initial iteration and for recovering from wild truncation errors.&lt;br/&gt;
Getting an estimate so that inverse quadratic interpolation is suspect to&lt;br/&gt;
problems for abs(x0-x2)&amp;lt;estimate seems to be a rather complex problem,&lt;br/&gt;
and dealing with this properly apparently wont save much.&lt;/p&gt;</comment>
                    <comment id="12410333" author="sebb@apache.org" created="Mon, 5 Sep 2005 08:58:10 +0000"  >&lt;p&gt;numElements/internalArray/startIndex - these could perhaps be made volatile&lt;br/&gt;
instead of synchronizing the access methods.&lt;/p&gt;</comment>
                    <comment id="12410334" author="phil@steitz.com" created="Fri, 25 Nov 2005 05:17:13 +0000"  >&lt;p&gt;Created an attachment (id=17036)&lt;br/&gt;
Findbugs after fixes&lt;/p&gt;</comment>
                    <comment id="12410335" author="phil@steitz.com" created="Fri, 25 Nov 2005 05:19:15 +0000"  >&lt;p&gt;Remaining complaints are by design.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333781" name="commonsmath-fb-comments.txt" size="5615" author="phil@steitz.com" created="Mon, 5 Sep 2005 02:30:42 +0000" />
                    <attachment id="12333780" name="commonsmath-fb.txt" size="4331" author="sebb@apache.org" created="Sun, 4 Sep 2005 22:38:31 +0000" />
                    <attachment id="12333782" name="findBugs1-1-final" size="7104" author="phil@steitz.com" created="Fri, 25 Nov 2005 05:17:13 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36491</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 5 Sep 2005 02:29:18 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-73] [math] Fix style, javadoc, test coverage gaps in RandomData</title>
                <link>https://issues.apache.org/jira/browse/MATH-73</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch fixes style and javadoc errors in RandomData and&lt;br/&gt;
RandomDataImpl and gets RandomDataTest as near to 100% coverage as possible&lt;br/&gt;
(missed execution paths are traversed only with near zero probability).&lt;/p&gt;

&lt;p&gt;The patch also fixes a bug in RandomDataImpl that was, interestingly, discovered&lt;br/&gt;
while examining the Clover test coverage report. The reSeedSecure() method was&lt;br/&gt;
actually reseeding the non-secure generator.  This error could not have been&lt;br/&gt;
caught in any unit test.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340752">MATH-73</key>
            <summary>[math] Fix style, javadoc, test coverage gaps in RandomData</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 3 Jun 2003 14:08:33 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404342" author="phil@steitz.com" created="Tue, 3 Jun 2003 14:11:20 +0000"  >&lt;p&gt;Created an attachment (id=6608)&lt;br/&gt;
patches to RandomData, RandomDataImpl, RandomDataTest&lt;/p&gt;</comment>
                    <comment id="12404343" author="mdiggory@gmail.com" created="Wed, 4 Jun 2003 09:49:00 +0000"  >&lt;p&gt;Commited these patches and ran unit tests to verify that the RandomDataTest is&lt;br/&gt;
working properly.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332306" name="RandomDataPatches.txt" size="37869" author="phil@steitz.com" created="Tue, 3 Jun 2003 14:11:20 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20442</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 4 Jun 2003 09:49:00 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-71] [math] user guide additions - root finding</title>
                <link>https://issues.apache.org/jira/browse/MATH-71</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Added text to the root finding portion of the user guide.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340996">MATH-71</key>
            <summary>[math] user guide additions - root finding</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Sep 2003 02:56:11 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405161" author="brentworden" created="Wed, 24 Sep 2003 02:56:27 +0000"  >&lt;p&gt;Created an attachment (id=8320)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12405162" author="j3322ptm@yahoo.de" created="Thu, 25 Sep 2003 03:15:35 +0000"  >&lt;p&gt;Applied, thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332546" name="analysis-xdoc.txt" size="8793" author="brentworden" created="Wed, 24 Sep 2003 02:56:27 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>23367</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Sep 2003 03:15:35 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-70] [math] Why are the methods of TTest not static?</title>
                <link>https://issues.apache.org/jira/browse/MATH-70</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;To do T-tests on data &amp;#8211; for which many thanks! &amp;#8211; you currently have to do the&lt;br/&gt;
following&lt;/p&gt;

&lt;p&gt;TTest tester = new TTestImpl();&lt;br/&gt;
tester.pairedTTest( ... );&lt;/p&gt;

&lt;p&gt;There are two things that are inelegant about this implementation: you have to&lt;br/&gt;
explicitly call &quot;new TTestImpl()&quot; instead of using a factory method, and I don&apos;t&lt;br/&gt;
see why there&apos;s this whole interface-implementation paradigm at all. As far as I&lt;br/&gt;
can see, there&apos;s no state stored in the TTest implementation; why isn&apos;t it a&lt;br/&gt;
singleton class with static methods instead?&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341943">MATH-70</key>
            <summary>[math] Why are the methods of TTest not static?</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="m.e.foster@ed.ac.uk">Mary Ellen Foster</reporter>
                        <labels>
                    </labels>
                <created>Mon, 13 Dec 2004 22:56:08 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>1.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12408343" author="phil@steitz.com" created="Tue, 14 Dec 2004 06:54:29 +0000"  >&lt;p&gt;Great questions.  The interface / implementation separation is to support the &lt;br/&gt;
strategy pattern for alternative implementations.  Staying away from static &lt;br/&gt;
methods in implementations is for extensibility.  All that said, I agree that &lt;br/&gt;
the setup is a little awkward.  &lt;/p&gt;

&lt;p&gt;One way to improve usability would be to introduce a TestUtils class that &lt;br/&gt;
would work similarly to StatUtils &amp;#8211; create singleton instances of the &lt;br/&gt;
implementation classes and expose static methods that delegate to the &lt;br/&gt;
singletons.  Any better ideas?  Patches welcome.&lt;/p&gt;</comment>
                    <comment id="12408344" author="phil@steitz.com" created="Sun, 5 Jun 2005 13:08:21 +0000"  >&lt;p&gt;Added factory and static utils class.  Should be fixed in nightly builds&lt;br/&gt;
starting 5 Jun 05.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>32663</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 14 Dec 2004 06:54:29 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-69] [math] Improve numerics in BivariateRegression</title>
                <link>https://issues.apache.org/jira/browse/MATH-69</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch implements the Chan-Golub-Leveque updating formulas adapted&lt;br/&gt;
to means and regression sums of squares to improve accuracy of statistical&lt;br/&gt;
computations in BivariateRegression.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340806">MATH-69</key>
            <summary>[math] Improve numerics in BivariateRegression</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sat, 21 Jun 2003 07:41:22 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404565" author="phil@steitz.com" created="Sat, 21 Jun 2003 07:42:32 +0000"  >&lt;p&gt;Created an attachment (id=6922)&lt;br/&gt;
patches to BivariateRegression, BivariateRegressionTest&lt;/p&gt;</comment>
                    <comment id="12404566" author="mdiggory@gmail.com" created="Sat, 21 Jun 2003 09:16:53 +0000"  >&lt;p&gt;rebuilt, unit tested and commited&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332376" name="regressionUpdate.txt" size="9445" author="phil@steitz.com" created="Sat, 21 Jun 2003 07:42:32 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20979</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 21 Jun 2003 09:16:53 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-68] [math] Failure to fail when testing for exceptions in MathUtils</title>
                <link>https://issues.apache.org/jira/browse/MATH-68</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;In MathUtilsTest I found the following code:&lt;/p&gt;

&lt;p&gt;    public void testAddAndCheck() {&lt;br/&gt;
        int big = Integer.MAX_VALUE;&lt;br/&gt;
        int bigNeg = Integer.MIN_VALUE;&lt;br/&gt;
        assertEquals(big, MathUtils.addAndCheck(big, 0));&lt;br/&gt;
        try {
            int res = MathUtils.addAndCheck(big, 1);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
        try {
            int res = MathUtils.addAndCheck(bigNeg, -1);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;    public void testMulAndCheck() {&lt;br/&gt;
        int big = Integer.MAX_VALUE;&lt;br/&gt;
        int bigNeg = Integer.MIN_VALUE;&lt;br/&gt;
        assertEquals(big, MathUtils.mulAndCheck(big, 1));&lt;br/&gt;
        try {
            int res = MathUtils.mulAndCheck(big, 2);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
        try {
            int res = MathUtils.mulAndCheck(bigNeg, 2);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;    public void testSubAndCheck() {&lt;br/&gt;
        int big = Integer.MAX_VALUE;&lt;br/&gt;
        int bigNeg = Integer.MIN_VALUE;&lt;br/&gt;
        assertEquals(big, MathUtils.subAndCheck(big, 0));&lt;br/&gt;
        try {
            int res = MathUtils.subAndCheck(big, -1);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
        try {
            int res = MathUtils.subAndCheck(bigNeg, 1);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;These tests pass even if the expected excepiton is thrown. All three should be&lt;br/&gt;
reworked with fail() statements at the end of the try block like so:&lt;/p&gt;

&lt;p&gt;        try {
            int res = MathUtils.subAndCheck(big, -1);
            fail(&quot;Didn&apos;t throw exceptions when subtracting one over the maximum&quot;);
        } catch (ArithmeticException ex) {}&lt;br/&gt;
        try {
            int res = MathUtils.subAndCheck(bigNeg, 1);
            fail(&quot;Didn&apos;t throw exceptions when subtracting one over the maximum&quot;);
        } catch (ArithmeticException ex) {}&lt;/p&gt;


&lt;p&gt;I doubt there&apos;s a real bug here, but if there is, these tests won&apos;t find it.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342633">MATH-68</key>
            <summary>[math] Failure to fail when testing for exceptions in MathUtils</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="elharo@metalab.unc.edu">elharo</reporter>
                        <labels>
                    </labels>
                <created>Sat, 15 Oct 2005 00:45:44 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410621" author="phil@steitz.com" created="Sun, 16 Oct 2005 09:20:33 +0000"  >&lt;p&gt;Thanks for reporting this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37095</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 16 Oct 2005 09:20:33 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-67] [math] Completing RealMatrixImpl</title>
                <link>https://issues.apache.org/jira/browse/MATH-67</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch adds implementations for solve(), inverse() and other missing&lt;br/&gt;
method implementations in RealMatrixImpl. The patch also corrects checkstyle&lt;br/&gt;
errors and brings test path coverage to as close to 100% as practical.&lt;/p&gt;

&lt;p&gt;The one remaining missing method implementation is getRank().&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340790">MATH-67</key>
            <summary>[math] Completing RealMatrixImpl</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 15 Jun 2003 12:49:49 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404492" author="phil@steitz.com" created="Sun, 15 Jun 2003 12:51:30 +0000"  >&lt;p&gt;Created an attachment (id=6836)&lt;br/&gt;
patches to RealMatrixImpl, RealMatrix, RealMatrixImplTest&lt;/p&gt;</comment>
                    <comment id="12404493" author="mdiggory@gmail.com" created="Mon, 16 Jun 2003 00:04:36 +0000"  >&lt;p&gt;Patched and Tested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332357" name="RealMatrixPatch.txt" size="50664" author="phil@steitz.com" created="Sun, 15 Jun 2003 12:51:30 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20783</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 16 Jun 2003 00:04:36 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-65] [math] user guide additions - distribution framework</title>
                <link>https://issues.apache.org/jira/browse/MATH-65</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Added text to distribution framework portion of the user guide.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340993">MATH-65</key>
            <summary>[math] user guide additions - distribution framework</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Sep 2003 01:29:55 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405159" author="brentworden" created="Wed, 24 Sep 2003 01:30:17 +0000"  >&lt;p&gt;Created an attachment (id=8319)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12405160" author="j3322ptm@yahoo.de" created="Thu, 25 Sep 2003 03:15:44 +0000"  >&lt;p&gt;Applied, thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332545" name="stat-xdoc.txt" size="6870" author="brentworden" created="Wed, 24 Sep 2003 01:30:17 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>23361</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Sep 2003 03:15:44 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-64] [math] Cleanup and add inferential stats to BivariateRegression</title>
                <link>https://issues.apache.org/jira/browse/MATH-64</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch includes the following improvements to BivariateRegression&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Fixed all checkstyle errors and eliminated redundant NaN checks.  Now have&lt;br/&gt;
100% test path coverage.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Used distribution framework TDistribution to implement&lt;br/&gt;
getSlopeConfidenceInterval and getSignificance methods.&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340778">MATH-64</key>
            <summary>[math] Cleanup and add inferential stats to BivariateRegression</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Wed, 11 Jun 2003 01:45:27 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404446" author="phil@steitz.com" created="Wed, 11 Jun 2003 01:46:34 +0000"  >&lt;p&gt;Created an attachment (id=6739)&lt;br/&gt;
patches to BivariateRegression, BivariateRegressionTest&lt;/p&gt;</comment>
                    <comment id="12404447" author="tobrien@discursive.com" created="Wed, 11 Jun 2003 10:35:55 +0000"  >&lt;p&gt;Patch committed.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332340" name="regressionPatch.txt" size="23995" author="phil@steitz.com" created="Wed, 11 Jun 2003 01:46:34 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20657</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 11 Jun 2003 10:35:55 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-63] [math] ConplexFormat tests fail for French locale</title>
                <link>https://issues.apache.org/jira/browse/MATH-63</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The ComplexFormat tests are failing when run on a French locale system. Test&lt;br/&gt;
output reported to commons-dev by Paul Libbrecht:&lt;/p&gt;

&lt;p&gt;&amp;gt; cat  target/test-reports/TEST-&lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.txt&lt;br/&gt;
Testsuite: org.apache.commons.math.complex.ComplexFormatTest&lt;br/&gt;
Tests run: 34, Failures: 17, Errors: 0, Time elapsed: 1,09 sec&lt;/p&gt;

&lt;p&gt;Testcase: &lt;br/&gt;
testSimpleWithDecimals(org.apache.commons.math.complex.ComplexFormatTest ):   &lt;br/&gt;
FAILED&lt;br/&gt;
expected:&amp;lt;....23 + 1....&amp;gt; but was:&amp;lt;...,23 + 1,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....23 + 1....&amp;gt; but  was:&amp;lt;...,23 +&lt;br/&gt;
1,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testSimpleWithDecimals&lt;br/&gt;
(ComplexFormatTest.java:49)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testSimpleWithDecimalsTrunc(org.apache.commons.math.complex.ComplexForma tTest):&lt;br/&gt;
      FAILED&lt;br/&gt;
expected:&amp;lt;....23 + 1....&amp;gt; but was:&amp;lt;...,23 + 1,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....23 + 1....&amp;gt; but  was:&amp;lt;...,23 +&lt;br/&gt;
1,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testSimpleWithDecimals&lt;br/&gt;
Trunc(ComplexFormatTest.java:56)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testNegativeReal(org.apache.commons.math.complex.ComplexFormatTest):&lt;br/&gt;
 FAILED&lt;br/&gt;
expected:&amp;lt;....23 + 1....&amp;gt; but was:&amp;lt;...,23 + 1,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....23 + 1....&amp;gt; but  was:&amp;lt;...,23 +&lt;br/&gt;
1,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testNegativeReal(Compl&lt;br/&gt;
exFormatTest.java:63)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testNegativeImaginary(org.apache.commons.math.complex.ComplexFormatTest) :    &lt;br/&gt;
FAILED&lt;br/&gt;
expected:&amp;lt;....23 - 1....&amp;gt; but was:&amp;lt;...,23 - 1,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....23 - 1....&amp;gt; but  was:&amp;lt;...,23 -&lt;br/&gt;
1,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testNegativeImaginary(&lt;br/&gt;
ComplexFormatTest.java:70)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testNegativeBoth(org.apache.commons.math.complex.ComplexFormatTest):&lt;br/&gt;
 FAILED&lt;br/&gt;
expected:&amp;lt;....23 - 1....&amp;gt; but was:&amp;lt;...,23 - 1,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....23 - 1....&amp;gt; but  was:&amp;lt;...,23 -&lt;br/&gt;
1,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testNegativeBoth(Compl&lt;br/&gt;
exFormatTest.java:77)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testZeroReal(org.apache.commons.math.complex.ComplexFormatTest):    &lt;br/&gt;
 FAILED&lt;br/&gt;
expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testZeroReal(ComplexFo&lt;br/&gt;
rmatTest.java:84)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testZeroImaginary(org.apache.commons.math.complex.ComplexFormatTest):&lt;br/&gt;
FAILED&lt;br/&gt;
expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testZeroImaginary(Comp&lt;br/&gt;
lexFormatTest.java:91)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testStaticFormatComplex(org.apache.commons.math.complex.ComplexFormatTes t):  &lt;br/&gt;
FAILED&lt;br/&gt;
expected:&amp;lt;....22 - 342....&amp;gt; but was:&amp;lt;...,22 - 342,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;....22 - 342....&amp;gt; but  was:&amp;lt;...,22&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;342,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testStaticFormatComple&lt;br/&gt;
x(ComplexFormatTest.java:105)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt;Testcase: &lt;br/&gt;
testParseSimpleWithDecimals(org.apache.commons.math.complex.ComplexForma tTest):&lt;br/&gt;
      FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseSimpleWithDec&lt;br/&gt;
imals(ComplexFormatTest.java:147)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseSimpleWithDecimalsTrunc(org.apache.commons.math.complex.Complex&lt;br/&gt;
FormatTest):  FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseSimpleWithDec&lt;br/&gt;
imalsTrunc(ComplexFormatTest.java:158)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseNegativeReal(org.apache.commons.math.complex.ComplexFormatTest) :    &lt;br/&gt;
FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseNegativeReal(&lt;br/&gt;
ComplexFormatTest.java:169)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseNegativeImaginary(org.apache.commons.math.complex.ComplexFormat Test):&lt;br/&gt;
       FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseNegativeImagi&lt;br/&gt;
nary(ComplexFormatTest.java:180)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseNegativeBoth(org.apache.commons.math.complex.ComplexFormatTest) :    &lt;br/&gt;
FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseNegativeBoth(&lt;br/&gt;
ComplexFormatTest.java:191)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testParseZeroReal(org.apache.commons.math.complex.ComplexFormatTest):&lt;br/&gt;
FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseZeroReal(Comp&lt;br/&gt;
lexFormatTest.java:202)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseZeroImaginary(org.apache.commons.math.complex.ComplexFormatTest ):   &lt;br/&gt;
FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseZeroImaginary&lt;br/&gt;
(ComplexFormatTest.java:213)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase: &lt;br/&gt;
testParseDifferentImaginaryChar(org.apache.commons.math.complex.ComplexF&lt;br/&gt;
ormatTest):   FAILED&lt;br/&gt;
Format.parseObject(String) failed&lt;br/&gt;
junit.framework.AssertionFailedError: Format.parseObject(String) failed&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testParseDifferentImag&lt;br/&gt;
inaryChar(ComplexFormatTest.java:224)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;


&lt;p&gt;Testcase:  testFormatNumber(org.apache.commons.math.complex.ComplexFormatTest):&lt;br/&gt;
 FAILED&lt;br/&gt;
expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
junit.framework.ComparisonFailure: expected:&amp;lt;.......&amp;gt; but was:&amp;lt;...,...&amp;gt;&lt;br/&gt;
        at &lt;br/&gt;
org.apache.commons.math.complex.ComplexFormatTest.testFormatNumber(Compl&lt;br/&gt;
exFormatTest.java:330)&lt;br/&gt;
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)&lt;br/&gt;
        at &lt;br/&gt;
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor&lt;br/&gt;
Impl.java:25)&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341735">MATH-63</key>
            <summary>[math] ConplexFormat tests fail for French locale</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 21 Sep 2004 10:48:17 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12407612" author="brentworden" created="Tue, 21 Sep 2004 11:57:37 +0000"  >&lt;p&gt;Added locale support to complex format.  Added test cases for specific locales.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31325</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 21 Sep 2004 11:57:37 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-61] [math][patch] Update ComplexUtils.java</title>
                <link>https://issues.apache.org/jira/browse/MATH-61</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Index: ComplexUtils.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; ComplexUtils.java   (revision 233396)&lt;br/&gt;
+++ ComplexUtils.java   (working copy)&lt;br/&gt;
@@ -216,7 +216,10 @@&lt;/p&gt;

&lt;p&gt;         double a = z.getReal();&lt;br/&gt;
         double b = z.getImaginary();&lt;br/&gt;
-&lt;br/&gt;
+        if (a == 0.0 &amp;amp;&amp;amp; b == 0.0) {
+            return new Complex(0.0, 0.0);
+        }&lt;br/&gt;
+&lt;br/&gt;
         double t = Math.sqrt((Math.abs(a) + z.abs()) / 2.0);&lt;br/&gt;
         if (a &amp;gt;= 0.0) {&lt;br/&gt;
             return new Complex(t, b / (2.0 * t));&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342496">MATH-61</key>
            <summary>[math][patch] Update ComplexUtils.java</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Fri, 19 Aug 2005 08:29:17 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410207" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 08:30:12 +0000"  >&lt;p&gt;add zero checks to sqrt()&lt;/p&gt;</comment>
                    <comment id="12410208" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 08:30:42 +0000"  >&lt;p&gt;Created an attachment (id=16107)&lt;br/&gt;
ComplexUtils.java&lt;/p&gt;</comment>
                    <comment id="12410209" author="phil@steitz.com" created="Tue, 23 Aug 2005 06:05:34 +0000"  >&lt;p&gt;Patch looks good to me, with comment about how we handle 0. Not sure&lt;br/&gt;
computational formula is optimal, though.&lt;/p&gt;</comment>
                    <comment id="12410210" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 07:08:10 +0000"  >&lt;p&gt;Applied. This also fixes a LaguerreSolver test case.&lt;br/&gt;
Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333743" name="ComplexUtils.java" size="9116" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 08:30:42 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36266</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 23 Aug 2005 06:05:34 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-59] [math] chi-squared distribution resubmittal.</title>
                <link>https://issues.apache.org/jira/browse/MATH-59</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;This is the resubmittal of the chi-squared distribution.  This was removed &lt;br/&gt;
because of the NR references in Gamma.java.  I derived new implementations &lt;br/&gt;
based on formulas found at MathWorld and elsewhere replacing any derivation &lt;br/&gt;
from NR.&lt;/p&gt;

&lt;p&gt;If anyone cares, the series representation of incomplete gamma found in NR, is &lt;br/&gt;
derived from the confluent hypergeometric function of the first kind (what the &lt;br/&gt;
he!! is that?).&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340755">MATH-59</key>
            <summary>[math] chi-squared distribution resubmittal.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Thu, 5 Jun 2003 06:15:39 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404358" author="brentworden" created="Thu, 5 Jun 2003 06:16:24 +0000"  >&lt;p&gt;Created an attachment (id=6638)&lt;br/&gt;
path file&lt;/p&gt;</comment>
                    <comment id="12404359" author="mdiggory@gmail.com" created="Thu, 5 Jun 2003 21:08:09 +0000"  >&lt;p&gt;I&apos;ve commited these changes to the cvs and run unit testing to verify the&lt;br/&gt;
package still builds properly. Looks good.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332307" name="new-chi-squared-patch.txt" size="67875" author="brentworden" created="Thu, 5 Jun 2003 06:16:24 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20488</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 5 Jun 2003 21:08:09 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-58] [math] modify AbstractStoreUnivariate.getSortedValues to use built-in sort</title>
                <link>https://issues.apache.org/jira/browse/MATH-58</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Attached patch replaces shell sort in AbstractStoreUnivariate.getSortedValues&lt;br/&gt;
with java.util.Arrays sort.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340807">MATH-58</key>
            <summary>[math] modify AbstractStoreUnivariate.getSortedValues to use built-in sort</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sat, 21 Jun 2003 08:17:41 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404567" author="phil@steitz.com" created="Sat, 21 Jun 2003 08:18:24 +0000"  >&lt;p&gt;Created an attachment (id=6923)&lt;br/&gt;
Patch to AbstractStoreUnivariate&lt;/p&gt;</comment>
                    <comment id="12404568" author="mdiggory@gmail.com" created="Sat, 21 Jun 2003 09:19:33 +0000"  >&lt;p&gt;patched, unit tested and commited&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332377" name="abstractStoreUniariatePatch.txt" size="1675" author="phil@steitz.com" created="Sat, 21 Jun 2003 08:18:24 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20980</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 21 Jun 2003 09:19:33 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-57] [math] NaN handling in StatsUtil.min, StatsUtil.max methods</title>
                <link>https://issues.apache.org/jira/browse/MATH-57</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Data with NaN appears to be incorrectly handled in some cases when calculating &lt;br/&gt;
min and max using StatsUtil package. See examples below:&lt;/p&gt;

&lt;p&gt;data={NaN, 4.0, 5.0, NaN}&lt;br/&gt;
max (Apache)=NaN &amp;lt;-- correct.&lt;br/&gt;
min (Apache)=NaN &amp;lt;-- correct.&lt;/p&gt;

&lt;p&gt;data={4.0, 5.0, NaN}&lt;br/&gt;
max (Apache)=NaN &amp;lt;-- correct.&lt;br/&gt;
min (Apache)=NaN &amp;lt;-- correct.&lt;/p&gt;

&lt;p&gt;data={4.0, 5.0, 7.0}&lt;br/&gt;
max (Apache)=7.0 &amp;lt;-- correct.&lt;br/&gt;
min (Apache)=4.0 &amp;lt;-- correct.&lt;/p&gt;

&lt;p&gt;data={NaN, 4.0, 5.0}&lt;br/&gt;
max (Apache)=5.0 &amp;lt;-- incorrect? NaN.&lt;br/&gt;
min (Apache)=4.0 &amp;lt;-- incorrect? NaN.&lt;/p&gt;

&lt;p&gt;data={2.2343, NaN, NaN, 3435.32}&lt;br/&gt;
max (Apache)=3435.32 &amp;lt;-- incorrect? NaN.&lt;br/&gt;
min (Apache)=3435.32 &amp;lt;-- incorrect? NaN.&lt;/p&gt;

&lt;p&gt;data={3435.32, NaN, NaN, 2.2343}&lt;br/&gt;
max (Apache)=2.2343 &amp;lt;-- incorrect? NaN.&lt;br/&gt;
min (Apache)=2.2343 &amp;lt;-- incorrect? NaN.&lt;/p&gt;

&lt;p&gt;data={NaN, NaN, NaN}&lt;br/&gt;
max (Apache)=NaN &amp;lt;-- correct.&lt;br/&gt;
min (Apache)=NaN &amp;lt;-- correct.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows 2000&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342619">MATH-57</key>
            <summary>[math] NaN handling in StatsUtil.min, StatsUtil.max methods</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mark.osborn@research.ge.com">Mark Osborn</reporter>
                        <labels>
                    </labels>
                <created>Tue, 11 Oct 2005 20:58:31 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                            <version>1.0</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410584" author="phil@steitz.com" created="Tue, 11 Oct 2005 23:05:34 +0000"  >&lt;p&gt;Thanks for reporting this.  Looks like a bug.  Patches welcome &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="12410585" author="mauro@apache.org" created="Thu, 13 Oct 2005 23:07:14 +0000"  >&lt;p&gt;It&apos;s not clear from the javadocs whether any data value which is NaN&lt;br/&gt;
should result in the min/max values being NaN too. &lt;/p&gt;

&lt;p&gt;Javadocs only state that if ALL values are NaN the result is NaN.&lt;/p&gt;

&lt;p&gt;Cases can be made for both ignoring spurious NaN or for triggering a NaN result.&lt;/p&gt;

&lt;p&gt;Could this be clarified?&lt;/p&gt;</comment>
                    <comment id="12410586" author="elharo@metalab.unc.edu" created="Thu, 13 Oct 2005 23:45:29 +0000"  >&lt;p&gt;The Complex class also has some questionable and undocumented behavior with&lt;br/&gt;
respect to NaN (and Inf). It might be worthwhile considering on a general NaN&lt;br/&gt;
policy for the math classes. &lt;/p&gt;</comment>
                    <comment id="12410587" author="kim@kimvdlinde.com" created="Fri, 14 Oct 2005 00:10:10 +0000"  >&lt;p&gt;problem arrises from the underlying Max.evaluate(double[]) and&lt;br/&gt;
Min.evaluate(double[]) methods, who fail to address the Double.NaN values&lt;br/&gt;
similar to the Max.increment(double) methods, e.g. is not addressing it at all&lt;br/&gt;
(from class Max):&lt;/p&gt;

&lt;p&gt;    public void increment(final double d) {&lt;br/&gt;
        if (d &amp;gt; value || Double.isNaN(value)) {
            value = d;
        }&lt;br/&gt;
        n++;&lt;br/&gt;
    }&lt;br/&gt;
and &lt;br/&gt;
    (public double evaluate(final double[] values) is in super class, but&lt;br/&gt;
resolves to evaluate(values, 0, values.length) =&amp;gt;&lt;/p&gt;

&lt;p&gt;    public double evaluate(final double[] values, final int begin, final int&lt;br/&gt;
length) {&lt;br/&gt;
        double max = Double.NaN;&lt;br/&gt;
        if (test(values, begin, length)) {&lt;br/&gt;
            max = values&lt;span class=&quot;error&quot;&gt;&amp;#91;begin&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            for (int i = begin; i &amp;lt; begin + length; i++) {
                max = (max &amp;gt; values[i]) ? max : values[i];
            }&lt;br/&gt;
        }&lt;br/&gt;
        return max;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;Solution:&lt;/p&gt;

&lt;p&gt;    public double evaluate(final double[] values, final int begin, final int&lt;br/&gt;
length) {&lt;br/&gt;
        double max = Double.NaN;&lt;br/&gt;
        if (test(values, begin, length)) {&lt;br/&gt;
            max = values&lt;span class=&quot;error&quot;&gt;&amp;#91;begin&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            for (int i = begin; i &amp;lt; begin + length; i++) {
                max = ((max &amp;gt; values[i]) || Double.isNaN(value)) ? max : values[i];
            }&lt;br/&gt;
        }&lt;br/&gt;
        return max;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;similar to min and this will resolve issue in StatUtils.&lt;/p&gt;</comment>
                    <comment id="12410588" author="kim@kimvdlinde.com" created="Fri, 14 Oct 2005 00:26:52 +0000"  >&lt;p&gt;Ok, did some more checks, and the solution before was only dealing with half the&lt;br/&gt;
problem:&lt;/p&gt;

&lt;p&gt;    public void increment(final double d)&lt;/p&gt;
    {
	if (Double.isNaN(value) || Double.isNaN(d))
	    value = Double.NaN;
        else if (d &amp;gt; value)
            value = d;
        n++;
    }

&lt;p&gt;    public double evaluate(final double[] values, final int begin, final int length)&lt;br/&gt;
    {&lt;br/&gt;
        double max = Double.NaN;&lt;br/&gt;
        if (test(values, begin, length))&lt;br/&gt;
        {&lt;br/&gt;
            max = values&lt;span class=&quot;error&quot;&gt;&amp;#91;begin&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            for (int i = begin; i &amp;lt; begin + length; i++)&lt;/p&gt;
	    {
	        if (Double.isNaN(values[i]))
	            return Double.NaN;
                max = (max &amp;gt; values[i]) ? max : values[i];
            }
&lt;p&gt;        }&lt;br/&gt;
        return max;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;The solution I added prematurely returns the method as soon as it finds a NaN. &lt;/p&gt;</comment>
                    <comment id="12410589" author="mauro@apache.org" created="Fri, 14 Oct 2005 01:23:00 +0000"  >&lt;p&gt;A simple way of ensuring that all values are not NaN is to check in &lt;br/&gt;
AbstractUnivariateStatistic#test() and throw an IAE if ANY are.&lt;/p&gt;

&lt;p&gt;It would have the great advantage of simplicity and applicable to all&lt;br/&gt;
UnivariateStatistic impls, but could break backward compat in existing&lt;br/&gt;
users&apos; code.&lt;/p&gt;


</comment>
                    <comment id="12410590" author="phil@steitz.com" created="Fri, 14 Oct 2005 11:58:45 +0000"  >&lt;p&gt;This is definitely a bug, as the javadoc indicates clearly that NaN values&lt;br/&gt;
should have no impact on the result:&lt;br/&gt;
&quot;The result is NaN iff all values are NaN (i.e. NaN values have no impact on the&lt;br/&gt;
value of the statistic).&quot;&lt;/p&gt;</comment>
                    <comment id="12410591" author="mauro@apache.org" created="Sat, 15 Oct 2005 03:01:52 +0000"  >&lt;p&gt;Created an attachment (id=16699)&lt;br/&gt;
Patch to test and fix issue&lt;/p&gt;

&lt;p&gt;Attached is a patch which fixes issue as per Javadoc spec,&lt;br/&gt;
ie evaluate returns NaN iff all values are NaN, else&lt;br/&gt;
NaNs are ignored.&lt;/p&gt;</comment>
                    <comment id="12410592" author="phil@steitz.com" created="Sun, 16 Oct 2005 07:18:08 +0000"  >&lt;p&gt;Patch applied. Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333845" name="issue-37019-patch.txt" size="5279" author="mauro@apache.org" created="Sat, 15 Oct 2005 03:01:52 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37019</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 11 Oct 2005 23:05:34 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-56] [math][patch] Interpolation Source Files</title>
                <link>https://issues.apache.org/jira/browse/MATH-56</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;rename ExpFunction.java to Expm1Function.java and make changes to it&lt;br/&gt;
fix bug in NevilleInterpolatorTest.java&lt;br/&gt;
minor changes in PolynomialFunctionLagrangeForm.java&lt;/p&gt;

&lt;p&gt;replace these 3 files in COM-2311, others remain the same.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342464">MATH-56</key>
            <summary>[math][patch] Interpolation Source Files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Sat, 13 Aug 2005 10:54:06 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410089" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 10:54:56 +0000"  >&lt;p&gt;Created an attachment (id=16028)&lt;br/&gt;
Interpolation Source Files&lt;/p&gt;</comment>
                    <comment id="12410090" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 06:46:19 +0000"  >&lt;p&gt;Files added (without change, revision pending)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333709" name="Interpolator.zip" size="5525" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 10:54:56 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36175</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Aug 2005 06:46:19 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-55] [math][patch] Solver Source Files</title>
                <link>https://issues.apache.org/jira/browse/MATH-55</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Add RiddersSolver.java&lt;br/&gt;
Add RiddersSolverTest.java&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342487">MATH-55</key>
            <summary>[math][patch] Solver Source Files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Aug 2005 03:00:21 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:07 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:07 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410170" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 03:00:53 +0000"  >&lt;p&gt;Created an attachment (id=16084)&lt;br/&gt;
RiddersSolver.java&lt;/p&gt;</comment>
                    <comment id="12410171" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 03:01:34 +0000"  >&lt;p&gt;Created an attachment (id=16085)&lt;br/&gt;
RiddersSolverTest.java&lt;/p&gt;</comment>
                    <comment id="12410172" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 11:37:52 +0000"  >&lt;p&gt;Add MullerSolver.java&lt;br/&gt;
Add MullerSolverTest.java&lt;/p&gt;</comment>
                    <comment id="12410173" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 11:38:29 +0000"  >&lt;p&gt;Created an attachment (id=16108)&lt;br/&gt;
MullerSolver.java&lt;/p&gt;</comment>
                    <comment id="12410174" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 11:43:00 +0000"  >&lt;p&gt;Created an attachment (id=16109)&lt;br/&gt;
MullerSolverTest.java&lt;/p&gt;</comment>
                    <comment id="12410175" author="zxg_32@yahoo.com" created="Sat, 20 Aug 2005 02:10:33 +0000"  >&lt;p&gt;Created an attachment (id=16116)&lt;br/&gt;
MullerSolver.java&lt;/p&gt;

&lt;p&gt;update MullerSolver.java&lt;br/&gt;
remove two lines:&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.complex.Complex;&lt;br/&gt;
import org.apache.commons.math.complex.ComplexUtils;&lt;/p&gt;

&lt;p&gt;Maybe complex arithmetics will be added in future, but for now&lt;br/&gt;
it&apos;s not needed.&lt;/p&gt;</comment>
                    <comment id="12410176" author="zxg_32@yahoo.com" created="Sat, 20 Aug 2005 11:06:45 +0000"  >&lt;p&gt;Created an attachment (id=16125)&lt;br/&gt;
MullerSolver.java&lt;/p&gt;

&lt;p&gt;Update MullerSolver.java&lt;/p&gt;

&lt;p&gt;simplifies some branching condition statements,&lt;br/&gt;
the algorithm logic remains the same.&lt;/p&gt;</comment>
                    <comment id="12410177" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:37:40 +0000"  >&lt;p&gt;Created an attachment (id=16134)&lt;br/&gt;
MullerSolver.java&lt;/p&gt;

&lt;p&gt;update MullerSolver.java&lt;/p&gt;

&lt;p&gt;minor change, add one line&lt;br/&gt;
		oldx = Double.POSITIVE_INFINITY;&lt;/p&gt;</comment>
                    <comment id="12410178" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:38:26 +0000"  >&lt;p&gt;Add LaguerreSolver.java&lt;br/&gt;
Add LaguerreSolverTest.java&lt;/p&gt;</comment>
                    <comment id="12410179" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:38:49 +0000"  >&lt;p&gt;Created an attachment (id=16135)&lt;br/&gt;
LaguerreSolver.java&lt;/p&gt;</comment>
                    <comment id="12410180" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:39:12 +0000"  >&lt;p&gt;Created an attachment (id=16136)&lt;br/&gt;
LaguerreSolverTest.java&lt;/p&gt;</comment>
                    <comment id="12410181" author="j3322ptm@yahoo.de" created="Thu, 25 Aug 2005 06:48:06 +0000"  >&lt;p&gt;Files added (without change, revision pending)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333733" name="LaguerreSolver.java" size="12803" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:38:49 +0000" />
                    <attachment id="12333734" name="LaguerreSolverTest.java" size="7353" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:39:12 +0000" />
                    <attachment id="12333732" name="MullerSolver.java" size="11624" author="zxg_32@yahoo.com" created="Mon, 22 Aug 2005 01:37:40 +0000" />
                    <attachment id="12333731" name="MullerSolver.java" size="11574" author="zxg_32@yahoo.com" created="Sat, 20 Aug 2005 11:06:45 +0000" />
                    <attachment id="12333730" name="MullerSolver.java" size="12170" author="zxg_32@yahoo.com" created="Sat, 20 Aug 2005 02:10:33 +0000" />
                    <attachment id="12333728" name="MullerSolver.java" size="12273" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 11:38:29 +0000" />
                    <attachment id="12333729" name="MullerSolverTest.java" size="8653" author="zxg_32@yahoo.com" created="Fri, 19 Aug 2005 11:43:00 +0000" />
                    <attachment id="12333726" name="RiddersSolver.java" size="6113" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 03:00:53 +0000" />
                    <attachment id="12333727" name="RiddersSolverTest.java" size="5078" author="zxg_32@yahoo.com" created="Thu, 18 Aug 2005 03:01:34 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>9.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36233</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Aug 2005 06:48:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-54] FDistribution -- java stack overflow</title>
                <link>https://issues.apache.org/jira/browse/MATH-54</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;This bug goes back to at least the beginning of March, tested on June 5 build.&lt;br/&gt;
The following block creates a java stack overflow:&lt;/p&gt;

&lt;p&gt;try {&lt;br/&gt;
    org.apache.commons.math.distribution.FDistributionImpl fd =&lt;br/&gt;
    new org.apache.commons.math.distribution.FDistributionImpl(100000., &lt;br/&gt;
100000.);&lt;br/&gt;
    double est;&lt;br/&gt;
    est = fd.cumulativeProbability(1.);&lt;br/&gt;
    _logger.info(&quot;1.=&quot; + est);&lt;br/&gt;
} catch (Exception jle) {&lt;br/&gt;
    jle.printStackTrace();&lt;br/&gt;
    return;&lt;br/&gt;
}&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341490">MATH-54</key>
            <summary>FDistribution -- java stack overflow</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="scott@duchin.com">Scott Duchin</reporter>
                        <labels>
                    </labels>
                <created>Mon, 7 Jun 2004 00:24:50 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406750" author="brentworden" created="Fri, 11 Jun 2004 01:25:35 +0000"  >&lt;p&gt;I changed the continued fraction used in regularizedBeta resulting in faster &lt;br/&gt;
convergence.  I added the test case provided by scott and ran all units tests &lt;br/&gt;
with all of them passing.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29414</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 11 Jun 2004 01:25:35 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-53] [math] improvements to ValueServer</title>
                <link>https://issues.apache.org/jira/browse/MATH-53</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch includes the following improvements to ValueServer&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;add missing setters&lt;/li&gt;
	&lt;li&gt;add fill methods to fill double arrays with data generated by the ValueServer&lt;/li&gt;
	&lt;li&gt;close path coverage gaps&lt;/li&gt;
	&lt;li&gt;eliminate checkstyle errors&lt;/li&gt;
	&lt;li&gt;improve clarity of javadoc&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340765">MATH-53</key>
            <summary>[math] improvements to ValueServer</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Fri, 6 Jun 2003 15:47:49 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404412" author="phil@steitz.com" created="Fri, 6 Jun 2003 15:48:54 +0000"  >&lt;p&gt;Created an attachment (id=6668)&lt;br/&gt;
patches to ValueServer, ValueServerTest&lt;/p&gt;</comment>
                    <comment id="12404413" author="mdiggory@gmail.com" created="Sat, 7 Jun 2003 08:39:57 +0000"  >&lt;p&gt;Applied, Commited and tested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332329" name="valueServerPatch.txt" size="13836" author="phil@steitz.com" created="Fri, 6 Jun 2003 15:48:54 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20543</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 7 Jun 2003 08:39:57 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-51] [math] EmpiricalDistributionImpl patch to adapt to change in Univariate interface</title>
                <link>https://issues.apache.org/jira/browse/MATH-51</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The EmpiricalDistributionImpl that I submitted yesterday assumed the &quot;old&quot;&lt;br/&gt;
Univariate interface, in which getN() returned a double.  The attached patch&lt;br/&gt;
inserts the necessary casts to avoid the rounding/truncation errors that were&lt;br/&gt;
causing the EmpiricalDistribution and ValueServer unit tests to fail.&lt;/p&gt;

&lt;p&gt;The patch also adds a RandomData member variable so that getNext() does not&lt;br/&gt;
instantiate a new RandomData instance for each activation&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340721">MATH-51</key>
            <summary>[math] EmpiricalDistributionImpl patch to adapt to change in Univariate interface</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Thu, 22 May 2003 21:08:13 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404266" author="phil@steitz.com" created="Thu, 22 May 2003 21:09:17 +0000"  >&lt;p&gt;Created an attachment (id=6456)&lt;br/&gt;
Patch for EmpiricalDistributionImpl&lt;/p&gt;</comment>
                    <comment id="12404267" author="tobrien@discursive.com" created="Thu, 22 May 2003 22:46:56 +0000"  >&lt;p&gt;Patch committed, also a related issue with RandomDataTest was fixed.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332281" name="EmpiricalDistributionImplPatch.txt" size="2392" author="phil@steitz.com" created="Thu, 22 May 2003 21:09:17 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20149</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 22 May 2003 22:46:56 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-50] [math] Adding references, updating task list in xdocs</title>
                <link>https://issues.apache.org/jira/browse/MATH-50</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patches to xdocs&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;add the numerical analysis and prob/stat references that have been posted or&lt;br/&gt;
  included in javadoc recently, plus a few more generic references.&lt;/li&gt;
	&lt;li&gt;update the task list based on accomplishments and discussion&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Also updating my own contact info in project.xml&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340741">MATH-50</key>
            <summary>[math] Adding references, updating task list in xdocs</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Fri, 30 May 2003 22:24:22 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404311" author="phil@steitz.com" created="Fri, 30 May 2003 22:25:52 +0000"  >&lt;p&gt;Created an attachment (id=6567)&lt;br/&gt;
xdocs patch to include references, update task list&lt;/p&gt;</comment>
                    <comment id="12404312" author="phil@steitz.com" created="Fri, 30 May 2003 22:28:26 +0000"  >&lt;p&gt;Created an attachment (id=6568)&lt;br/&gt;
adding email contact, fixing roles xml&lt;/p&gt;</comment>
                    <comment id="12404313" author="tobrien@discursive.com" created="Fri, 30 May 2003 22:42:59 +0000"  >&lt;p&gt;patches applied&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332296" name="projectXMLPatch.txt" size="952" author="phil@steitz.com" created="Fri, 30 May 2003 22:28:26 +0000" />
                    <attachment id="12332295" name="xdocsPatch.txt" size="6279" author="phil@steitz.com" created="Fri, 30 May 2003 22:25:52 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20357</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 30 May 2003 22:42:59 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-49] [math] Non-private serialVersionUIDs</title>
                <link>https://issues.apache.org/jira/browse/MATH-49</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Many classes such as BrentSolver use non-private serialversionUIDs. e.g.&lt;/p&gt;

&lt;p&gt;    static final long serialVersionUID = 3350616277306882875L;&lt;/p&gt;

&lt;p&gt;should be&lt;/p&gt;

&lt;p&gt;    private static final long serialVersionUID = 3350616277306882875L;&lt;/p&gt;

&lt;p&gt;I&apos;ll see if I can patch this.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342647">MATH-49</key>
            <summary>[math] Non-private serialVersionUIDs</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="elharo@metalab.unc.edu">elharo</reporter>
                        <labels>
                    </labels>
                <created>Wed, 19 Oct 2005 20:43:11 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410686" author="elharo@metalab.unc.edu" created="Wed, 19 Oct 2005 20:52:38 +0000"  >&lt;p&gt;Created an attachment (id=16752)&lt;br/&gt;
privatize serialVersionUID&lt;/p&gt;

&lt;p&gt;This is the first time I&apos;ve made a patch with SVN. Plase double-check to make&lt;br/&gt;
sure I didn&apos;t do anything too stupid. Thanks.&lt;/p&gt;</comment>
                    <comment id="12410687" author="phil@steitz.com" created="Thu, 24 Nov 2005 04:16:51 +0000"  >&lt;p&gt;Patch applied to MATH_1_1 branch, to be merged into trunk.  Thanks!  Sorry for&lt;br/&gt;
the latency. &lt;/p&gt;

&lt;p&gt;In the future, it is best to make your patches from the top level src directory&lt;br/&gt;
or at least somewhere inside the project tree.&lt;/p&gt;

&lt;p&gt;Keep them coming &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333868" name="serialVersionUIDPatch" size="65432" author="elharo@metalab.unc.edu" created="Wed, 19 Oct 2005 20:52:38 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37162</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 24 Nov 2005 04:16:51 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-48] [math] chi-squared distribution (part of the distribution collection)</title>
                <link>https://issues.apache.org/jira/browse/MATH-48</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Here is the begginings of the distribution framework.  It&apos;s definately been a &lt;br/&gt;
practice in over-engineering.&lt;/p&gt;

&lt;p&gt;It starts with a distribution factory following the abstract factory pattern.  &lt;br/&gt;
The value being, if users want to swap out the default distribution &lt;br/&gt;
implementations with their own, why stop them.  The factory is responsible for &lt;br/&gt;
create the distribution instances (only continuous ones for now).&lt;/p&gt;

&lt;p&gt;Each distribution has a cummulativeProbabilty method which returns the value of &lt;br/&gt;
the CDF for a given value.  By default, via the abstract distribution base &lt;br/&gt;
class, an inverseCummulativeProbability method is all provided for all &lt;br/&gt;
distributions.  It&apos;s implementation is generically handled by applying root &lt;br/&gt;
finding techniques to the cummulativeProbability method.  That way, when new &lt;br/&gt;
distributions are added, authors only need to create the CDF method and the &lt;br/&gt;
inverse is provided automatically.&lt;/p&gt;

&lt;p&gt;Currenty, the only distributions are Chi-Squared and Gamma (one actually since &lt;br/&gt;
Chi-Squared is a specialized Gamma) but I have more planned.&lt;/p&gt;

&lt;p&gt;FYI, I took the liberty of putting these classes into separate packages to &lt;br/&gt;
limit the package clutter we&apos;re starting to experience.  As such I could not &lt;br/&gt;
create a patch file for all my changes.  I will provide a patch for what I can &lt;br/&gt;
and provide a zip archive with all the files in the new packages.&lt;/p&gt;

&lt;p&gt;Feel free to modify and include as you see fit.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340737">MATH-48</key>
            <summary>[math] chi-squared distribution (part of the distribution collection)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Wed, 28 May 2003 05:44:57 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404303" author="brentworden" created="Wed, 28 May 2003 05:46:55 +0000"  >&lt;p&gt;Created an attachment (id=6519)&lt;br/&gt;
Here&apos;s the patch to the existing packages.&lt;/p&gt;</comment>
                    <comment id="12404304" author="brentworden" created="Wed, 28 May 2003 05:50:36 +0000"  >&lt;p&gt;Created an attachment (id=6520)&lt;br/&gt;
Here&apos;s the archive of all the new files in the new packages.&lt;/p&gt;</comment>
                    <comment id="12404305" author="steitzp@yahoo.com" created="Wed, 28 May 2003 08:12:06 +0000"  >&lt;p&gt;I like the generic CDF inversion capability provided by &lt;br/&gt;
AbstractContinousDistribution, and the ContinuousDistribution interface.  &lt;br/&gt;
Personally, I do not see the implementation as over-engineered for what it does &lt;br/&gt;
and if we want to tackle the critical value problem for statistical tests &lt;br/&gt;
generically, I can&apos;t see a significantly simpler or more flexible way to do &lt;br/&gt;
it.  It would be nice to extend/modify/replace TestStatistic with a hypothesis-&lt;br/&gt;
testing capability using the distribution framework to compute critical values &lt;br/&gt;
for t (need to add this distribution), chi-square and maybe F.  We will also &lt;br/&gt;
obviously have to fill out the docs on the framework.  What will likely be most &lt;br/&gt;
useful to applications are the distribution implementations and any inferential &lt;br/&gt;
machinery that we build on top of them.&lt;/p&gt;

&lt;p&gt;I guess there is no postponing the packaging discussion.  stat is sort of &lt;br/&gt;
obvious and I guess stat.distribution makes sense, assuming we want to move &lt;br/&gt;
forward with the framework (which I personally think is a good idea).  In an &lt;br/&gt;
earlier post, I had designated something like &quot;analysis&quot; or &quot;numerical&quot;, which &lt;br/&gt;
would be a good home for the rootfinding stuff.  Probably should take this to &lt;br/&gt;
the list.&lt;/p&gt;</comment>
                    <comment id="12404306" author="tobrien@discursive.com" created="Fri, 30 May 2003 02:44:22 +0000"  >&lt;p&gt;Patches applied&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332292" name="chi-square-additions.zip" size="23257" author="brentworden" created="Wed, 28 May 2003 05:50:36 +0000" />
                    <attachment id="12332291" name="chi-square-patch.diff" size="4217" author="brentworden" created="Wed, 28 May 2003 05:46:55 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20279</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 28 May 2003 08:12:06 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-47] [math] &quot;NaN when MathUtils.round(0,2)&quot;</title>
                <link>https://issues.apache.org/jira/browse/MATH-47</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;If MathUtils.round(a + b, 2) is calledm the resutl is NaN where as it should&apos;ve&lt;br/&gt;
been 0.00&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342500">MATH-47</key>
            <summary>[math] &quot;NaN when MathUtils.round(0,2)&quot;</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ngupte@aurigalogic.com">Nikhil Gupte</reporter>
                        <labels>
                    </labels>
                <created>Mon, 22 Aug 2005 21:08:17 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410217" author="ngupte@aurigalogic.com" created="Mon, 22 Aug 2005 21:09:20 +0000"  >&lt;p&gt;Forgot to mention:&lt;/p&gt;

&lt;p&gt;If MathUtils.round(a + b, 2) is calledm the resutl is NaN where as it should&apos;ve&lt;br/&gt;
been 0.00 iff (a = b) == 0.&lt;/p&gt;</comment>
                    <comment id="12410218" author="brentworden" created="Mon, 22 Aug 2005 21:56:03 +0000"  >&lt;p&gt;Fixed in SVN Revision 234481. Applied to MATH_1_1 branch.  Fixed division by &lt;br/&gt;
zero error in rounding methods.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36300</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 22 Aug 2005 21:56:03 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-46] [math] &quot;INFINITE_WINDOW&quot; is misspelled &quot;INIFINTE_WINDOW&quot; in Univariate and its users</title>
                <link>https://issues.apache.org/jira/browse/MATH-46</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;&quot;INFINITE_WINDOW&quot; is misspelled &quot;INIFINTE_WINDOW&quot; in Univariate.java and its users, viz., &lt;br/&gt;
UnivariateImpl.java, ListUnivariateImpl.java, and StoreUnivariateImpl.java.  Looks like a copy-and-&lt;br/&gt;
paste bug originating in Univariate.java that should be fixed before it propagates further.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12340731">MATH-46</key>
            <summary>[math] &quot;INFINITE_WINDOW&quot; is misspelled &quot;INIFINTE_WINDOW&quot; in Univariate and its users</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="4" iconUrl="https://issues.apache.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hotfusionman@yahoo.com">Albert Davidson Chou</reporter>
                        <labels>
                    </labels>
                <created>Mon, 26 May 2003 14:27:18 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404289" author="tobrien@discursive.com" created="Tue, 27 May 2003 00:44:52 +0000"  >&lt;p&gt;Fixed - the dangers of code completion in a tool like Eclipse....&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20234</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 27 May 2003 00:44:52 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-45] [math] Matrix operations make unecessary copies</title>
                <link>https://issues.apache.org/jira/browse/MATH-45</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The following methods in RealMatrixImpl, BigMatrixImpl make unecessary copies of&lt;br/&gt;
the data in the external operands:&lt;/p&gt;

&lt;p&gt;  add&lt;br/&gt;
  multiply&lt;br/&gt;
  preMultiply&lt;br/&gt;
  solve&lt;br/&gt;
  subtract&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341805">MATH-45</key>
            <summary>[math] Matrix operations make unecessary copies</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Thu, 14 Oct 2004 11:20:20 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12407795" author="phil@steitz.com" created="Mon, 8 Nov 2004 04:26:59 +0000"  >&lt;p&gt;Committed changes replacing copy - array reference with getEntry. &lt;/p&gt;

&lt;p&gt;We may eventually want to add overloads for RealMatrixImpl/BigMatrixImpl&lt;br/&gt;
operands that use getDataRef, which will be faster. This was changed to getData&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;resulting in extra copies - when getDataRef was removed from the RealMatrix&lt;br/&gt;
interface.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31713</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-44] [math] Contradictory asserts in javadoc comments of TTest  and TTestImpl</title>
                <link>https://issues.apache.org/jira/browse/MATH-44</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Found in javadoc comment of method : &lt;br/&gt;
  public double tTest( X, X )&lt;br/&gt;
&apos;For a one-sided test, divide the returned value by 2.&apos;&lt;/p&gt;

&lt;p&gt;But found in javadoc comment for method :&lt;br/&gt;
  public boolean tTest( X, X, double alpha)&lt;br/&gt;
&apos;To perform a 1-sided test, use &amp;lt;code&amp;gt;alpha / 2&amp;lt;/code&amp;gt;&apos;&lt;/p&gt;

&lt;p&gt;where it should be:&lt;br/&gt;
&apos;To perform a 1-sided test, use &amp;lt;code&amp;gt;alpha * 2&amp;lt;/code&amp;gt;&apos;&lt;/p&gt;

&lt;p&gt;confirmed by code of the boolean valued function:&lt;br/&gt;
return (tTest(sampleStats1, sampleStats2) &amp;lt; alpha);&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342116">MATH-44</key>
            <summary>[math] Contradictory asserts in javadoc comments of TTest  and TTestImpl</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gillesgaillard@compuserve.com">Gilles Gaillard</reporter>
                        <labels>
                    </labels>
                <created>Thu, 14 Apr 2005 20:30:29 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12408894" author="phil@steitz.com" created="Sun, 17 Apr 2005 06:48:28 +0000"  >&lt;p&gt;Thank you for pointing out this error.  &lt;br/&gt;
Fixed in nightly builds starting 4/16/05.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>34448</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 17 Apr 2005 06:48:28 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-43] [math] Adding percentiles to StoredUnivariate, AbstractStoreUnivariate</title>
                <link>https://issues.apache.org/jira/browse/MATH-43</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Attached patches add getPercentile, getSortedValues to StoredUnivariate&lt;br/&gt;
interface and provide implementation in AbstractStoreUnivariate.&lt;/p&gt;

&lt;p&gt;Sort uses simple shell sort performed directly on a double[] array copy returned&lt;br/&gt;
by getValues. &lt;/p&gt;

&lt;p&gt;Percentile definition used does linear interpolation after computing target&lt;br/&gt;
position.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340744">MATH-43</key>
            <summary>[math] Adding percentiles to StoredUnivariate, AbstractStoreUnivariate</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sat, 31 May 2003 07:13:50 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404320" author="phil@steitz.com" created="Sat, 31 May 2003 07:15:38 +0000"  >&lt;p&gt;Created an attachment (id=6577)&lt;br/&gt;
patches to StoreUnivariate, AbstractStoreUnivariate&lt;/p&gt;</comment>
                    <comment id="12404321" author="phil@steitz.com" created="Sat, 31 May 2003 07:18:12 +0000"  >&lt;p&gt;Created an attachment (id=6578)&lt;br/&gt;
patch to StoreUnivariateImplTest&lt;/p&gt;</comment>
                    <comment id="12404322" author="mdiggory@gmail.com" created="Wed, 4 Jun 2003 09:28:13 +0000"  >&lt;p&gt;I&apos;ve applied both patches to the StoreUnivariate** and verified that the Unit&lt;br/&gt;
Tests work with the Ant build.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332299" name="StoreUnivariatePatches.txt" size="5191" author="phil@steitz.com" created="Sat, 31 May 2003 07:15:38 +0000" />
                    <attachment id="12332300" name="StoreUnivariateTestPatch.txt" size="7921" author="phil@steitz.com" created="Sat, 31 May 2003 07:18:12 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20377</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 4 Jun 2003 09:28:13 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-42] [math] Function &quot;Fraction math.fraction.FractionFormat.parse(String, ParsePosition) &quot; does not handle parsing the numerater properly</title>
                <link>https://issues.apache.org/jira/browse/MATH-42</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Hello,&lt;/p&gt;

&lt;p&gt;While testing function &quot;Fraction math.fraction.FractionFormat.parse(String, &lt;br/&gt;
ParsePosition) &quot;, I found it did not handle properly the case the input string &lt;br/&gt;
passed in is incorrect. &lt;/p&gt;

&lt;p&gt;When I passed in a String that represented a Fraction to be parsed, if the &lt;br/&gt;
Fraction embedded in the String had a whole value, while either the numerator &lt;br/&gt;
or denominator had the negative sign, the function just returned &lt;br/&gt;
1/abs(denomitator).&lt;/p&gt;

&lt;p&gt;Please see the following code segment for more details:&lt;/p&gt;

&lt;p&gt;&quot;   &lt;br/&gt;
  NumberFormat nf = null; &lt;/p&gt;

&lt;p&gt;  FractionFormat properFormat = FractionFormat.getProperInstance&lt;br/&gt;
(Locale.getDefault());&lt;br/&gt;
  FractionFormat improperFormat = FractionFormat.getImproperInstance&lt;br/&gt;
(Locale.getDefault());&lt;/p&gt;

&lt;p&gt;//Test 1 : fail &lt;br/&gt;
public void testParseNegative(){&lt;/p&gt;

&lt;p&gt;   String source = &quot;1 -2 / 3&quot;;&lt;br/&gt;
   ParsePosition pos = new ParsePosition(0);&lt;/p&gt;

&lt;p&gt;   Fraction actual = properFormat.parse(source, pos);&lt;br/&gt;
   assertNull(actual);&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;// Test2: success&lt;br/&gt;
public void testParseNegative(){&lt;/p&gt;

&lt;p&gt;   String source = &quot;1 -2 / 3&quot;;&lt;br/&gt;
   ParsePosition pos = new ParsePosition(0);&lt;/p&gt;

&lt;p&gt;   Fraction actual = properFormat.parse(source, pos);  // return Fraction 1/3&lt;br/&gt;
   assertEquals(1, source.getNumerator());&lt;br/&gt;
   assertEquals(3, source.getDenominator());&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;&quot;&lt;/p&gt;

&lt;p&gt;Note: Similarly, when I passed in the following inputs: &lt;br/&gt;
  input 2: (source = &amp;ldquo;1 2 / -3&amp;rdquo;, pos = 0)&lt;br/&gt;
  input 3: ( source = &amp;rdquo; -1 -2 / 3&amp;rdquo;, pos = 0)&lt;/p&gt;

&lt;p&gt;Function &quot;Fraction parse(String, ParsePosition)&quot; returned Fraction 1/3 (means &lt;br/&gt;
the result Fraction had numerator = 1 and  denominator = 3)for all 3 inputs &lt;br/&gt;
above.&lt;/p&gt;

&lt;p&gt;I think the function does not handle parsing the numberator/ denominator &lt;br/&gt;
properly incase input string provides negative numerator or negative &lt;br/&gt;
denominator while there is the whole value.&lt;/p&gt;

&lt;p&gt;Thank you!&lt;br/&gt;
Nhung&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12343082">MATH-42</key>
            <summary>[math] Function &quot;Fraction math.fraction.FractionFormat.parse(String, ParsePosition) &quot; does not handle parsing the numerater properly</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="nhung.nnguyen@gmail.com">nhung.nnguyen</reporter>
                        <labels>
                    </labels>
                <created>Sun, 14 May 2006 05:08:05 +0000</created>
                <updated>Sat, 14 Oct 2006 02:45:36 +0000</updated>
                    <resolved>Mon, 5 Jun 2006 10:17:24 +0000</resolved>
                            <version>1.1</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12442135" author="nhung.nnguyen@gmail.com" created="Sat, 14 Oct 2006 02:45:36 +0000"  >
&lt;p&gt;   [[ Old comment, sent by email on Mon, 5 Jun 2006 23:54:56 -0500 ]]&lt;/p&gt;

&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Thanks to let me know.&lt;/p&gt;

&lt;p&gt;Have a good night, and best regards,&lt;br/&gt;
Nhung&lt;/p&gt;

</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="12310000">
                <name>Duplicate</name>
                                <outwardlinks description="duplicates">
                            <issuelink>
            <issuekey id="12343081">MATH-60</issuekey>
        </issuelink>
                    </outwardlinks>
                                            </issuelinktype>
                    </issuelinks>
                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>39576</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                        <customfield id="customfield_12310222" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time in Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[MATH-41] [math] Wrong implementation of the spline interpolator</title>
                <link>https://issues.apache.org/jira/browse/MATH-41</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Here is the (hopefully) correct implementation of the spline interpolator.&lt;/p&gt;

&lt;p&gt;        if (c == null) {&lt;br/&gt;
            // Number of intervals. The number of data points is N+1.&lt;br/&gt;
            int n = xval.length - 1;&lt;br/&gt;
            // Check whether the xval vector has ascending values.&lt;br/&gt;
            // Separation should be checked too (not implemented: which &lt;br/&gt;
criteria?).&lt;br/&gt;
            for (int i = 0; i &amp;lt; n; i++) {&lt;br/&gt;
                if (xval&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; &amp;gt;= xval&lt;span class=&quot;error&quot;&gt;&amp;#91;i + 1&amp;#93;&lt;/span&gt;) {
                    throw new IllegalArgumentException(&quot;Dataset must specify 
sorted, ascending x values.&quot;);
                }&lt;br/&gt;
            }&lt;br/&gt;
            // Vectors for the equation system. There are n-1 equations for the &lt;br/&gt;
unknowns s&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; (1&amp;lt;=i&amp;lt;=N-1),&lt;br/&gt;
            // which are second order derivatives for the spline at xval&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt;. At &lt;br/&gt;
the end points, s&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;=s&lt;span class=&quot;error&quot;&gt;&amp;#91;N&amp;#93;&lt;/span&gt;=0.&lt;br/&gt;
            // Vectors are offset by -1, except the lower diagonal vector which &lt;br/&gt;
is offset by -2. Layout:&lt;br/&gt;
            // d&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;+u&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;                                           = b&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;&lt;br/&gt;
            // l&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;+d&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;+u&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;                                 = b&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;&lt;br/&gt;
            //           l&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;+d&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;+u&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt;                       = b&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;&lt;br/&gt;
            //                           ...&lt;br/&gt;
            //                     l&lt;span class=&quot;error&quot;&gt;&amp;#91;N-4&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;N-3&amp;#93;&lt;/span&gt;+d&lt;span class=&quot;error&quot;&gt;&amp;#91;N-3&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;N-2&amp;#93;&lt;/span&gt;+u&lt;span class=&quot;error&quot;&gt;&amp;#91;N-3&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;N-1&amp;#93;&lt;/span&gt; = b&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;N-3&amp;#93;&lt;/span&gt;&lt;br/&gt;
            //                                   l&lt;span class=&quot;error&quot;&gt;&amp;#91;N-3&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;N-2&amp;#93;&lt;/span&gt;+d&lt;span class=&quot;error&quot;&gt;&amp;#91;N-2&amp;#93;&lt;/span&gt;*s&lt;span class=&quot;error&quot;&gt;&amp;#91;N-1&amp;#93;&lt;/span&gt; = b&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;N-2&amp;#93;&lt;/span&gt;&lt;br/&gt;
            // Vector b is the right hand side (RHS) of the system.&lt;br/&gt;
            double b[] = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 1&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            // Vector d is diagonal of the matrix and also holds the computed &lt;br/&gt;
solution.&lt;br/&gt;
            double d[] = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;n + 1&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            // Setup right hand side and diagonal.&lt;br/&gt;
            double dquot = (yval&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; - yval&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;) / (xval&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; - xval&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;);&lt;br/&gt;
            for (int i = 0; i &amp;lt; n - 1; i++) {
                // TODO avoid recomputing the term
                //    (yval[i + 2] - yval[i + 1]) / (xval[i + 2] - xval[i + 1])
                // take it from the previous loop pass. Note: the interesting 
part of performance
                // loss is the range check in the array access, not the 
computation itself.
                double dquotNext = 
                    (yval[i + 2] - yval[i + 1]) / (xval[i + 2] - xval[i + 1]);
                b[i] = 6.0 * (dquotNext - dquot);
                d[i+1] = 2.0 * (xval[i + 2] - xval[i]);
                dquot = dquotNext;
            }&lt;br/&gt;
            // u[] and l[] (for the upper and lower diagonal respectively) are &lt;br/&gt;
not&lt;br/&gt;
            // really needed, the computation is folded into the system solving &lt;br/&gt;
loops.&lt;br/&gt;
            // Keep this for documentation purposes:&lt;br/&gt;
            //double u[] = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 2&amp;#93;&lt;/span&gt;; // upper diagonal&lt;br/&gt;
            //double l[] = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 2&amp;#93;&lt;/span&gt;; // lower diagonal&lt;br/&gt;
            // Set up upper and lower diagonal. Keep the offsets in mind.&lt;br/&gt;
            //for (int i = 0; i &amp;lt; n - 2; i++) {
            //  u[i] = xval[i + 2] - xval[i + 1];
            //  l[i] = xval[i + 2] - xval[i + 1];
            //}&lt;br/&gt;
            // Solve the system: forward pass.&lt;br/&gt;
            for (int i = 0; i &amp;lt; n - 2; i++) {
                double delta = xval[i + 2] - xval[i + 1];
                double deltaquot = delta / d[i+1];
                d[i + 2] -= delta * deltaquot;
                b[i + 1] -= b[i] * deltaquot;
            }&lt;br/&gt;
            // Solve the system: backward pass.&lt;br/&gt;
            d&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 1&amp;#93;&lt;/span&gt; = b&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 2&amp;#93;&lt;/span&gt; / d&lt;span class=&quot;error&quot;&gt;&amp;#91;n - 1&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            for (int i = n - 3; i &amp;gt;= 0; i--) {
                d[i+1] = (b[i] - (xval[i + 2] - xval[i + 1]) * d[i + 2]) / d
[i+1];
            }&lt;br/&gt;
            // Compute coefficients as usual polynomial coefficients.&lt;br/&gt;
            // Not the best with respect to roundoff on evaluation, but simple.&lt;br/&gt;
            c = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;n&amp;#93;&lt;/span&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt;;&lt;br/&gt;
            // set the start values (this is for a natural spline)&lt;br/&gt;
            d&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; = d&lt;span class=&quot;error&quot;&gt;&amp;#91;n&amp;#93;&lt;/span&gt; = 0;&lt;/p&gt;

&lt;p&gt;            double delta;&lt;br/&gt;
            for (int i = 0; i &amp;lt; n; i++) {
                delta = xval[i + 1] - xval[i];
                c[i][3] = (d[i+1] - d[i]) / delta / 6.0;
                c[i][2] = d[i] / 2.0;
                c[i][1] =
                    (yval[i + 1] - yval[i]) / delta -
                        (d[i+1] + 2.0 * d[i]) * delta / 6.0;
                c[i][0] = yval[i];
            }&lt;br/&gt;
        }&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341143">MATH-41</key>
            <summary>[math] Wrong implementation of the spline interpolator</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="2" iconUrl="https://issues.apache.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="georg.lucas@heidelberg.com">Georg Lucas</reporter>
                        <labels>
                    </labels>
                <created>Mon, 8 Dec 2003 16:18:43 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405615" author="brentworden" created="Mon, 8 Dec 2003 23:14:34 +0000"  >&lt;p&gt;If you&apos;d be so kind, could you provide an example spline problem, preferably &lt;br/&gt;
one online, that you used to determine the coding error?  We could then add &lt;br/&gt;
this to the unit tests.&lt;/p&gt;</comment>
                    <comment id="12405616" author="georg.lucas@heidelberg.com" created="Wed, 10 Dec 2003 04:48:22 +0000"  >&lt;p&gt;Created an attachment (id=9468)&lt;br/&gt;
New test case for spline interpolator&lt;/p&gt;</comment>
                    <comment id="12405617" author="georg.lucas@heidelberg.com" created="Wed, 10 Dec 2003 04:49:41 +0000"  >&lt;p&gt;Created an attachment (id=9469)&lt;br/&gt;
Error correction for last x-value&lt;/p&gt;</comment>
                    <comment id="12405618" author="mdiggory@gmail.com" created="Tue, 27 Jan 2004 03:57:12 +0000"  >&lt;p&gt;Sigh,&lt;/p&gt;

&lt;p&gt;There are now issues with this fix and the fact that first/secondDerivatives are&lt;br/&gt;
not in the UnivariateRealFunction interface. With all the code flying around,&lt;br/&gt;
did we come to a conclusion on how to handle Derivatves and UnivariateRealFunctions?&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;</comment>
                    <comment id="12405619" author="brentworden" created="Tue, 27 Jan 2004 05:37:03 +0000"  >&lt;p&gt;I thought we were going to introduce an new inteface to denote differentiable &lt;br/&gt;
functions and morph the spline interpolator to use it.&lt;/p&gt;</comment>
                    <comment id="12405620" author="phil@steitz.com" created="Sat, 3 Apr 2004 05:57:39 +0000"  >&lt;p&gt;Implementation has been fixed in CVS and tests have been added, verifying&lt;br/&gt;
coefficients and consistency.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332651" name="CubicSplineFunction.java" size="7028" author="georg.lucas@heidelberg.com" created="Wed, 10 Dec 2003 04:49:41 +0000" />
                    <attachment id="12332650" name="InterpolatorTest.java" size="16262" author="georg.lucas@heidelberg.com" created="Wed, 10 Dec 2003 04:48:22 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>25278</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 8 Dec 2003 23:14:34 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-40] [math] binomail distribution patch</title>
                <link>https://issues.apache.org/jira/browse/MATH-40</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I created the binomial distribution.  along with this, I created a discrete &lt;br/&gt;
distribution heirarchy similar to the continuous case.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340913">MATH-40</key>
            <summary>[math] binomail distribution patch</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Fri, 15 Aug 2003 23:25:34 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404883" author="brentworden" created="Fri, 15 Aug 2003 23:25:50 +0000"  >&lt;p&gt;Created an attachment (id=7834)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404884" author="j3322ptm@yahoo.de" created="Sun, 17 Aug 2003 00:09:45 +0000"  >&lt;p&gt;Patch applied, compiled, unit tested and committed.&lt;br/&gt;
Thanks!&lt;/p&gt;</comment>
                    <comment id="12404885" author="mdiggory@gmail.com" created="Sun, 17 Aug 2003 00:24:11 +0000"  >&lt;p&gt;Just a heads up. Maybe we should make it a practice to take ownership of these&lt;br/&gt;
tickets when we work on them so that others do not attempt the same. I attempted&lt;br/&gt;
to commit this patch during / just after your commit and got all kinds of&lt;br/&gt;
conflict errors. If its status had changed ownership eariler I would not have&lt;br/&gt;
gone through the process while you were working on it too. &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;-Mark&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332463" name="binomial-distribution-patch.txt" size="35298" author="brentworden" created="Fri, 15 Aug 2003 23:25:50 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>22464</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 17 Aug 2003 00:09:45 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-39] [math] replace build.xml with maven-generated version</title>
                <link>https://issues.apache.org/jira/browse/MATH-39</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The current version of build.xml is missing commons-beanutils and associated&lt;br/&gt;
dependencies.  The attached patch replaces the original with a maven-generated&lt;br/&gt;
version that includes a target that gets the dependent jars.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340748">MATH-39</key>
            <summary>[math] replace build.xml with maven-generated version</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 2 Jun 2003 00:02:02 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404330" author="phil@steitz.com" created="Mon, 2 Jun 2003 00:03:20 +0000"  >&lt;p&gt;Created an attachment (id=6587)&lt;br/&gt;
patch to build.xml&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332303" name="buildPatch.txt" size="14841" author="phil@steitz.com" created="Mon, 2 Jun 2003 00:03:20 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20396</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-36] [math] t-test statistic proposal</title>
                <link>https://issues.apache.org/jira/browse/MATH-36</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Adds the one sample, t-test statistic to TestStatistic and implementations.&lt;br/&gt;
Also add unit tests.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12340730">MATH-36</key>
            <summary>[math] t-test statistic proposal</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Mon, 26 May 2003 13:48:19 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404286" author="brentworden" created="Mon, 26 May 2003 13:58:05 +0000"  >&lt;p&gt;Created an attachment (id=6493)&lt;br/&gt;
t-test patch file.&lt;/p&gt;</comment>
                    <comment id="12404287" author="brentworden" created="Mon, 26 May 2003 14:00:38 +0000"  >&lt;p&gt;Created an attachment (id=6494)&lt;br/&gt;
t-test unit test patch file.&lt;/p&gt;</comment>
                    <comment id="12404288" author="tobrien@discursive.com" created="Tue, 27 May 2003 00:36:47 +0000"  >&lt;p&gt;Brent, thanks for the patch.  It has been applied.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332287" name="t-test-unit.diff" size="1831" author="brentworden" created="Mon, 26 May 2003 14:00:38 +0000" />
                    <attachment id="12332286" name="t-test.diff" size="3441" author="brentworden" created="Mon, 26 May 2003 13:58:05 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20231</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 27 May 2003 00:36:47 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-35] Proposal for Poisson distributuion</title>
                <link>https://issues.apache.org/jira/browse/MATH-35</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Support for the Poisson distributuion should be added to the commons-math package.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12341803">MATH-35</key>
            <summary>Proposal for Poisson distributuion</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="frno@bredband.net">Fredrik Norin</reporter>
                        <labels>
                    </labels>
                <created>Wed, 13 Oct 2004 14:34:57 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:06 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:06 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12407787" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:37:21 +0000"  >&lt;p&gt;Created an attachment (id=13060)&lt;br/&gt;
Proposed interface for the Poisson distribution&lt;/p&gt;</comment>
                    <comment id="12407788" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:38:39 +0000"  >&lt;p&gt;Created an attachment (id=13061)&lt;br/&gt;
Implementation of the Poisson distribution&lt;/p&gt;</comment>
                    <comment id="12407789" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:41:13 +0000"  >&lt;p&gt;Created an attachment (id=13062)&lt;br/&gt;
JUnit test for the Poisson distribution implementation&lt;/p&gt;</comment>
                    <comment id="12407790" author="brentworden" created="Tue, 2 Nov 2004 09:37:19 +0000"  >&lt;p&gt;Few comments:&lt;/p&gt;

&lt;p&gt;1) The createFormat method uses replaceAll, a JDK 1.4 call.  I think &lt;span class=&quot;error&quot;&gt;&amp;#91;math&amp;#93;&lt;/span&gt; is &lt;br/&gt;
meant to be compatible with JDK 1.3 if not JDK 1.2.&lt;/p&gt;

&lt;p&gt;2) I see createFormat is being used to force precision on the inverse &lt;br/&gt;
cumulative probs.  Is there a reason this is being done on intermediate &lt;br/&gt;
results?  Is it necessary at all?&lt;/p&gt;

&lt;p&gt;3) For the probability method, I would suggest using the ol&apos; Exp[Log&lt;span class=&quot;error&quot;&gt;&amp;#91;f(x)&amp;#93;&lt;/span&gt;] &lt;br/&gt;
trick to avoid numerical overflow.  n! is a very volatile method for even &lt;br/&gt;
moderate n values.&lt;/p&gt;

&lt;p&gt;4) Can the parameter be renamed to something a little more descriptive?  I &lt;br/&gt;
would suggest mean.&lt;/p&gt;

&lt;p&gt;5) I think the cumulative probability method can be optimized one of two ways, &lt;br/&gt;
or by utilizing both.  Cumulative probabilities for Poisson can be expressed in &lt;br/&gt;
terms of the regularized gamma function which we already have implemented.  The &lt;br/&gt;
performance of this approach would not deteriorate for large x as the current &lt;br/&gt;
loop does.  At a minimum, instead of making calls to probability for each &lt;br/&gt;
summation term, the ratio of successive terms should be used to alleviate the &lt;br/&gt;
need to call n! for every term.&lt;/p&gt;

&lt;p&gt;6) Is there a compelling reason not to use the inverseCumulativeProbability &lt;br/&gt;
method provided by the AbstractDiscreteDistribution class?&lt;/p&gt;</comment>
                    <comment id="12407791" author="phil@steitz.com" created="Tue, 2 Nov 2004 13:29:13 +0000"  >&lt;p&gt;Brent,&lt;/p&gt;

&lt;p&gt;I agree with all of your points.&lt;/p&gt;

&lt;p&gt;1)-2) I think the &quot;rounding&quot; should be removed. To document clearly what the&lt;br/&gt;
contract means with the implementation in the patch would be difficult and would&lt;br/&gt;
depart from the specification in the interface.&lt;/p&gt;

&lt;p&gt;3) Using MathUtils.factorialDouble in place of factorial will accomplish this.&lt;/p&gt;

&lt;p&gt;4) Mean sounds good to me too.&lt;/p&gt;

&lt;p&gt;5) I would favor just using the regularized gamma.&lt;/p&gt;

&lt;p&gt;6) At first I thought that this would not work well since we would have to start&lt;br/&gt;
the bisection with top endpoint Integer.MAX_VALUE; but that&apos;s only 32 cuts out,&lt;br/&gt;
so I agree here too.&lt;/p&gt;

&lt;p&gt;I will make these changes prior to committing.&lt;/p&gt;</comment>
                    <comment id="12407792" author="phil@steitz.com" created="Sun, 7 Nov 2004 11:35:28 +0000"  >&lt;p&gt;Patches with modifications above have been committed.  Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333167" name="PoissonDistribution.java" size="1623" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:37:21 +0000" />
                    <attachment id="12333168" name="PoissonDistributionImpl.java" size="5875" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:38:39 +0000" />
                    <attachment id="12333169" name="PoissonDistributionTest.java" size="3908" author="frno@bredband.net" created="Wed, 13 Oct 2004 14:41:13 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>3.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31688</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 2 Nov 2004 09:37:19 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-32] [math] MathUtils  round Method issues</title>
                <link>https://issues.apache.org/jira/browse/MATH-32</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I was trying to use this class to round my float values.&lt;br/&gt;
class ==&amp;gt; org.apache.commons.math.util.MathUtils&lt;br/&gt;
method ==&amp;gt; round(float,scale)&lt;br/&gt;
Input 30.095 output 30.09 - ( i think should be  30.1)&lt;br/&gt;
Input 33.095 putput 33.1 - Correct&lt;br/&gt;
Input 50.085 output 50.08 - should have been 50.09&lt;br/&gt;
Input 50.185 output 50.19 - Correct&lt;br/&gt;
Input 50.005 output 50.01 - correct&lt;br/&gt;
Input 30.005 out put 30.0 - wrong&lt;br/&gt;
30.645 output - 30.65 - correct&lt;br/&gt;
So it seems there is some inconsistency. Not sure if its because of the how &lt;br/&gt;
BigDecimal.ROUND_HALF_UP works. but still the data is inconsistent.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows XP&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342410">MATH-32</key>
            <summary>[math] MathUtils  round Method issues</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="vemurys@hotmail.com">Srinivas Vemury</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Jul 2005 05:36:07 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:03 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:03 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12409923" author="phil@steitz.com" created="Thu, 28 Jul 2005 22:25:26 +0000"  >&lt;p&gt;Looks like an byproduct of the BigDecimal conversions, as this should not be the&lt;br/&gt;
default behavior.  Thanks for reporting this. Junit test cases would be great.&lt;/p&gt;</comment>
                    <comment id="12409924" author="phil@steitz.com" created="Sat, 30 Jul 2005 16:31:40 +0000"  >&lt;p&gt;The problem was due to the (documented) &quot;unpredictable&quot; behavior of BigDecimal&lt;br/&gt;
constructor when supplied double values.  As a workaround, I changed the&lt;br/&gt;
implementation to pass a string argument instead. &lt;/p&gt;

&lt;p&gt;I am leaving this open, since I think we should eliminate use of BigDecimal&lt;br/&gt;
altogether and code the algorithms directly.  &lt;/p&gt;</comment>
                    <comment id="12409925" author="brentworden" created="Sat, 13 Aug 2005 12:53:03 +0000"  >&lt;p&gt;Fixed.  SVN Revision 231029.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>35904</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 28 Jul 2005 22:25:26 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-31] [math} Adding random sampling and permutations</title>
                <link>https://issues.apache.org/jira/browse/MATH-31</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch adds the following two capabilities to RandomData:&lt;/p&gt;

&lt;p&gt;1. Generating random permutations of integers &lt;/p&gt;

&lt;p&gt;2. Generating random samples (returned as Object arrays) from Collections&lt;/p&gt;

&lt;p&gt;Tests validate expected sample distribtution using chi-square tests&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340738">MATH-31</key>
            <summary>[math} Adding random sampling and permutations</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Wed, 28 May 2003 21:08:26 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:03 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:03 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404307" author="phil@steitz.com" created="Wed, 28 May 2003 21:09:32 +0000"  >&lt;p&gt;Created an attachment (id=6546)&lt;br/&gt;
Patches to RandomData, RandomDataImpl, RandomDataTest&lt;/p&gt;</comment>
                    <comment id="12404308" author="phil@steitz.com" created="Wed, 28 May 2003 21:19:58 +0000"  >&lt;p&gt;Created an attachment (id=6547)&lt;br/&gt;
DOH!  forgot the test patch &amp;#8211; here &apos;tis&lt;/p&gt;</comment>
                    <comment id="12404309" author="tobrien@discursive.com" created="Fri, 30 May 2003 02:48:03 +0000"  >&lt;p&gt;Patches applied&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332294" name="RandomDataTestPatch.txt" size="5590" author="phil@steitz.com" created="Wed, 28 May 2003 21:19:58 +0000" />
                    <attachment id="12332293" name="randomDataPatches.txt" size="8230" author="phil@steitz.com" created="Wed, 28 May 2003 21:09:32 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20303</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 30 May 2003 02:48:03 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-30] [math] RandomDataImpl not using Random</title>
                <link>https://issues.apache.org/jira/browse/MATH-30</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;There&apos;s one call in RandomDataImpl using Math.random() and not the wrapped &lt;br/&gt;
Random object.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340759">MATH-30</key>
            <summary>[math] RandomDataImpl not using Random</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Fri, 6 Jun 2003 00:11:32 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:03 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:03 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404372" author="brentworden" created="Fri, 6 Jun 2003 00:11:57 +0000"  >&lt;p&gt;Created an attachment (id=6651)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404373" author="phil@steitz.com" created="Fri, 6 Jun 2003 01:34:11 +0000"  >&lt;p&gt;Don&apos;t ask me how that got in there &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;Nice catch.&lt;/p&gt;
</comment>
                    <comment id="12404374" author="mdiggory@gmail.com" created="Fri, 6 Jun 2003 02:04:56 +0000"  >&lt;p&gt;Applied the patch. Passed JUnit test...&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332311" name="random-patch.txt" size="809" author="brentworden" created="Fri, 6 Jun 2003 00:11:57 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20514</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 6 Jun 2003 01:34:11 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-29] [math] Adding MathUtils class, including binomial coefficients, factorials</title>
                <link>https://issues.apache.org/jira/browse/MATH-29</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I am attaching source for a new utility class, org.apache.commons.math.MathUtils&lt;br/&gt;
to house useful formulas, extending those that java.lang.Math provides.  Initial&lt;br/&gt;
contents are binomial coefficient and factorial methods.  For each of these,&lt;br/&gt;
three methods are provided, returning  &lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;value as a long&lt;/li&gt;
	&lt;li&gt;value as a double&lt;/li&gt;
	&lt;li&gt;log of the value as a double&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Limits on actual parameters for the first two (full value representations) are&lt;br/&gt;
specified in the javadoc.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340747">MATH-29</key>
            <summary>[math] Adding MathUtils class, including binomial coefficients, factorials</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 1 Jun 2003 14:49:15 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:03 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:03 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404327" author="phil@steitz.com" created="Sun, 1 Jun 2003 14:51:28 +0000"  >&lt;p&gt;Created an attachment (id=6582)&lt;br/&gt;
Source for MathUtils&lt;/p&gt;</comment>
                    <comment id="12404328" author="phil@steitz.com" created="Sun, 1 Jun 2003 14:53:41 +0000"  >&lt;p&gt;Created an attachment (id=6583)&lt;br/&gt;
Source for MathUtilsTest&lt;/p&gt;</comment>
                    <comment id="12404329" author="mdiggory@gmail.com" created="Wed, 4 Jun 2003 09:34:27 +0000"  >&lt;p&gt;Added both files tot he cvs and ran the UnitTests to verify build works correctly.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332301" name="MathUtils.java" size="10143" author="phil@steitz.com" created="Sun, 1 Jun 2003 14:51:28 +0000" />
                    <attachment id="12332302" name="MathUtilsTest.java" size="10841" author="phil@steitz.com" created="Sun, 1 Jun 2003 14:53:41 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20390</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 4 Jun 2003 09:34:27 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-28] Factorial method throws exception for zero</title>
                <link>https://issues.apache.org/jira/browse/MATH-28</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The MathUtils.factorial(final int n) method throws an IllegalArgumentException&lt;br/&gt;
for n=0 which is clearly incorrect since 0!=1 by definition.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12341802">MATH-28</key>
            <summary>Factorial method throws exception for zero</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="frno@bredband.net">Fredrik Norin</reporter>
                        <labels>
                    </labels>
                <created>Wed, 13 Oct 2004 14:07:06 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                            <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31687</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-27] [math][patch] Integration Source Files</title>
                <link>https://issues.apache.org/jira/browse/MATH-27</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Update TrapezoidIntegratorTest.java&lt;br/&gt;
Update SimpsonIntegratorTest.java&lt;br/&gt;
Update RombergIntegratorTest.java&lt;/p&gt;

&lt;p&gt;Some comments changes&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342457">MATH-27</key>
            <summary>[math][patch] Integration Source Files</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Fri, 12 Aug 2005 02:38:23 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410064" author="zxg_32@yahoo.com" created="Fri, 12 Aug 2005 02:38:55 +0000"  >&lt;p&gt;Created an attachment (id=16012)&lt;br/&gt;
Integration Source Files&lt;/p&gt;</comment>
                    <comment id="12410065" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 09:04:18 +0000"  >&lt;p&gt;Created an attachment (id=16027)&lt;br/&gt;
Integration Source Files&lt;/p&gt;</comment>
                    <comment id="12410066" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:53:48 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-2289 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12410067" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:54:20 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-2269 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12410068" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:54:48 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-2268 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12410069" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:55:18 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-2292 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12410070" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:55:45 +0000"  >&lt;ul&gt;
	&lt;li&gt;
	&lt;ul&gt;
		&lt;li&gt;
		&lt;ul&gt;
			&lt;li&gt;COM-2304 has been marked as a duplicate of this bug. ***&lt;/li&gt;
		&lt;/ul&gt;
		&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="12410071" author="phil@steitz.com" created="Sun, 14 Aug 2005 15:56:43 +0000"  >&lt;p&gt;Patches applied with one small change - copyright dates all fixed to be 2005.&lt;br/&gt;
Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333702" name="Integration.zip" size="5467" author="zxg_32@yahoo.com" created="Sat, 13 Aug 2005 09:04:18 +0000" />
                    <attachment id="12333701" name="Integration.zip" size="3651" author="zxg_32@yahoo.com" created="Fri, 12 Aug 2005 02:38:55 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36148</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 14 Aug 2005 15:53:48 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-26] Wiki link points to old Commons Wiki</title>
                <link>https://issues.apache.org/jira/browse/MATH-26</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;&lt;a href=&quot;http://jakarta.apache.org/commons/math/&quot;&gt;http://jakarta.apache.org/commons/math/&lt;/a&gt; has a link to&lt;br/&gt;
&lt;a href=&quot;http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaCommonsProjectPages&quot;&gt;http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaCommonsProjectPages&lt;/a&gt;, let&apos;s&lt;br/&gt;
change this to point to &lt;a href=&quot;http://wiki.apache.org/jakarta-commons&quot;&gt;http://wiki.apache.org/jakarta-commons&lt;/a&gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341487">MATH-26</key>
            <summary>Wiki link points to old Commons Wiki</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tobrien@discursive.com">Tim O&apos;Brien</reporter>
                        <labels>
                    </labels>
                <created>Fri, 4 Jun 2004 21:59:57 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406737" author="dirkv" created="Sat, 5 Jun 2004 05:47:08 +0000"  >&lt;p&gt;Menu has been updated in cvs, a simple site update will fix this&lt;/p&gt;</comment>
                    <comment id="12406738" author="rdonkin@apache.org" created="Wed, 9 Jun 2004 03:29:16 +0000"  >&lt;p&gt;This one&apos;s fixed now (but not by me). &lt;/p&gt;

&lt;p&gt;Robert&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29394</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 5 Jun 2004 05:47:08 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-25] [math] RandomDataTest#testConfig() requires SUN security provider</title>
                <link>https://issues.apache.org/jira/browse/MATH-25</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;RandomDataTest#testConfig() assumes SUN will be available as a&lt;br/&gt;
provider for the SHA-1 PRNG. Depending on your JDK, this may cause&lt;br/&gt;
test (and therefore, build) failures.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342787">MATH-25</key>
            <summary>[math] RandomDataTest#testConfig() requires SUN security provider</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 11 Dec 2005 06:19:01 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12411052" author="jwcarman" created="Sun, 11 Dec 2005 08:55:37 +0000"  >&lt;p&gt;Updated summary.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>37862</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 11 Dec 2005 08:55:37 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-24] [math] ChiSquareTest incorrectly rejects tables containing zeros</title>
                <link>https://issues.apache.org/jira/browse/MATH-24</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The isNonNegative(long[][] in) function defined in&lt;br/&gt;
o.a.c.m.inference.ChiSquareTest incorrectly rejects 0 as well as negative&lt;br/&gt;
counts. This causes 2-way tables containing 0 counts to be incorrectly rejected&lt;br/&gt;
(methods throw IllegalArgumentException).&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341918">MATH-24</key>
            <summary>[math] ChiSquareTest incorrectly rejects tables containing zeros</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 5 Dec 2004 05:13:00 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12408246" author="phil@steitz.com" created="Sun, 5 Dec 2004 05:58:52 +0000"  >&lt;p&gt;Changes to fix this problem have been committed.&lt;/p&gt;

&lt;p&gt;Thanks to Hans van der Heijden for reporting this bug.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>32531</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-23] [math] refactored distributions to use new solver framework</title>
                <link>https://issues.apache.org/jira/browse/MATH-23</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Changed abstract distribution to use default solver.&lt;/li&gt;
	&lt;li&gt;Removed bisection method from RootFinding.&lt;/li&gt;
	&lt;li&gt;Added BisectionSolver&lt;/li&gt;
	&lt;li&gt;Fixed some javadoc and checkstyle complaints&lt;/li&gt;
	&lt;li&gt;Added, ran, and passed BisectionSolver tests&lt;/li&gt;
	&lt;li&gt;Ran and passed all other tests.&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340838">MATH-23</key>
            <summary>[math] refactored distributions to use new solver framework</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Thu, 3 Jul 2003 22:11:36 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404667" author="brentworden" created="Thu, 3 Jul 2003 22:11:53 +0000"  >&lt;p&gt;Created an attachment (id=7083)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404668" author="mdiggory@gmail.com" created="Sun, 6 Jul 2003 01:08:34 +0000"  >&lt;p&gt;Applied and Commited.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332406" name="bisection-patch.diff" size="41829" author="brentworden" created="Thu, 3 Jul 2003 22:11:53 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21313</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Jul 2003 01:08:34 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-22] [math][patch] Update Complex.java</title>
                <link>https://issues.apache.org/jira/browse/MATH-22</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Index: Complex.java&lt;br/&gt;
===================================================================&lt;br/&gt;
&amp;#8212; Complex.java	(revision 233018)&lt;br/&gt;
+++ Complex.java	(working copy)&lt;br/&gt;
@@ -66,7 +66,19 @@&lt;br/&gt;
         if (isNaN()) {
             return Double.NaN;
         }&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;return Math.sqrt(squareSum());&lt;br/&gt;
+        if (Math.abs(real) &amp;lt; Math.abs(imaginary)) &lt;div class=&quot;error&quot;&gt;&lt;span class=&quot;error&quot;&gt;Unknown macro: {+            if (imaginary == 0.0) {
+                return Math.abs(real);
+            }+            double q = real / imaginary;+            return (Math.abs(imaginary) * Math.sqrt(1 + q*q));+        }&lt;/span&gt; &lt;/div&gt; else &lt;div class=&quot;error&quot;&gt;&lt;span class=&quot;error&quot;&gt;Unknown macro: {+            if (real == 0.0) {
+                return Math.abs(imaginary);
+            }+            double q = imaginary / real;+            return (Math.abs(real) * Math.sqrt(1 + q*q));+        }&lt;/span&gt; &lt;/div&gt;&lt;br/&gt;
     }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;     /**&lt;br/&gt;
@@ -108,17 +120,29 @@&lt;br/&gt;
         if (isNaN() || rhs.isNaN()) {
             return NaN;
         }&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;&lt;/li&gt;
	&lt;li&gt;if (Math.abs(rhs.getReal()) &amp;lt; Math.abs(rhs.getImaginary())) {&lt;/li&gt;
	&lt;li&gt;double q = rhs.getReal() / rhs.getImaginary();&lt;/li&gt;
	&lt;li&gt;double d = (rhs.getReal() * q) + rhs.getImaginary();&lt;/li&gt;
	&lt;li&gt;return new Complex(((real * q) + imaginary) / d,&lt;/li&gt;
	&lt;li&gt;((imaginary * q) - real) / d);&lt;br/&gt;
+&lt;br/&gt;
+        double c = rhs.getReal();&lt;br/&gt;
+        double d = rhs.getImaginary();&lt;br/&gt;
+        if (c == 0.0 &amp;amp;&amp;amp; d == 0.0) {
+            throw new ArithmeticException(&quot;Error: division by zero.&quot;);
+        }&lt;br/&gt;
+&lt;br/&gt;
+        if (Math.abs(c) &amp;lt; Math.abs(d)) &lt;div class=&quot;error&quot;&gt;&lt;span class=&quot;error&quot;&gt;Unknown macro: {+            if (d == 0.0) {
+                return new Complex(real/c, imaginary/c);
+            }+            double q = c / d;+            double denominator = c * q + d;+            return new Complex((real * q + imaginary) / denominator,+                (imaginary * q - real) / denominator);         }&lt;/span&gt; &lt;/div&gt; else {&lt;/li&gt;
	&lt;li&gt;double q = rhs.getImaginary() / rhs.getReal();&lt;/li&gt;
	&lt;li&gt;double d = (rhs.getImaginary() * q) + rhs.getReal();&lt;/li&gt;
	&lt;li&gt;return new Complex(((imaginary * q) + real) / d,&lt;/li&gt;
	&lt;li&gt;(imaginary - (real * q)) / d);&lt;br/&gt;
+            if (c == 0.0) {
+                return new Complex(imaginary/d, -real/c);
+            }&lt;br/&gt;
+            double q = d / c;&lt;br/&gt;
+            double denominator = d * q + c;&lt;br/&gt;
+            return new Complex((imaginary * q + real) / denominator,&lt;br/&gt;
+                (imaginary - real * q) / denominator);&lt;br/&gt;
         }&lt;br/&gt;
     }&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342477">MATH-22</key>
            <summary>[math][patch] Update Complex.java</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zxg_32@yahoo.com">Xiaogang Zhang</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Aug 2005 02:21:17 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410118" author="zxg_32@yahoo.com" created="Wed, 17 Aug 2005 02:21:45 +0000"  >&lt;p&gt;Created an attachment (id=16064)&lt;br/&gt;
Complex.java&lt;/p&gt;</comment>
                    <comment id="12410119" author="zxg_32@yahoo.com" created="Wed, 17 Aug 2005 02:24:31 +0000"  >&lt;p&gt;rewrite and optimize Complex.java to address the issues of&lt;br/&gt;
division by zero and overflow&lt;/p&gt;</comment>
                    <comment id="12410120" author="brentworden" created="Wed, 17 Aug 2005 14:13:39 +0000"  >&lt;p&gt;Patch applied.  SVN Revision 233126.  Applied to branch MATH_1_1.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333721" name="Complex.java" size="8127" author="zxg_32@yahoo.com" created="Wed, 17 Aug 2005 02:21:45 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36205</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 17 Aug 2005 14:13:39 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-21] [math] Initial submission for User Guide</title>
                <link>https://issues.apache.org/jira/browse/MATH-21</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch plus tar provides a shell for the User Guide based on the&lt;br/&gt;
previously posted outline and most of the content for the Data Generation section.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340835">MATH-21</key>
            <summary>[math] Initial submission for User Guide</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Wed, 2 Jul 2003 21:50:08 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404661" author="phil@steitz.com" created="Wed, 2 Jul 2003 21:51:02 +0000"  >&lt;p&gt;Created an attachment (id=7055)&lt;br/&gt;
Patch to existing xdocs&lt;/p&gt;</comment>
                    <comment id="12404662" author="phil@steitz.com" created="Wed, 2 Jul 2003 21:51:57 +0000"  >&lt;p&gt;Created an attachment (id=7056)&lt;br/&gt;
New files to add to xdocs/userguide&lt;/p&gt;</comment>
                    <comment id="12404663" author="mdiggory@gmail.com" created="Sun, 6 Jul 2003 00:04:30 +0000"  >&lt;p&gt;This is great work!  I added them and tested the site generation to verify html&lt;br/&gt;
gets generated properly. Thanks Phil &lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332404" name="userguide.tar" size="40960" author="phil@steitz.com" created="Wed, 2 Jul 2003 21:51:57 +0000" />
                    <attachment id="12332403" name="xdocPatch.txt" size="7548" author="phil@steitz.com" created="Wed, 2 Jul 2003 21:51:02 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21277</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 6 Jul 2003 00:04:30 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-20] [math] bivariate regression submission</title>
                <link>https://issues.apache.org/jira/browse/MATH-20</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached tar includes an implementation of ordinary least squares regression&lt;br/&gt;
with one independent variable. The implementation uses running sums and does not&lt;br/&gt;
require the data to be stored in memory.  Since I could not conceive of any&lt;br/&gt;
significantly different implementation strategies that did not amount to just&lt;br/&gt;
improving efficiency or numerical accuracy of what I am submitting, I did not&lt;br/&gt;
abstract the interface.&lt;/p&gt;

&lt;p&gt;The test cases validate the computations against NIST reference data and&lt;br/&gt;
verified computations. The slope, intercept, their standard errors and r-square&lt;br/&gt;
estimates are accurate to within 10E-12 against the reference data set.  MSE and&lt;br/&gt;
other ANOVA stats are good at least to within 10E-8.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340729">MATH-20</key>
            <summary>[math] bivariate regression submission</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Sun, 25 May 2003 21:59:35 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404284" author="phil@steitz.com" created="Sun, 25 May 2003 22:01:22 +0000"  >&lt;p&gt;Created an attachment (id=6487)&lt;br/&gt;
tar fiie containing BivariateRegression, BivariateRegressionTest&lt;/p&gt;</comment>
                    <comment id="12404285" author="tobrien@discursive.com" created="Mon, 26 May 2003 09:14:53 +0000"  >&lt;p&gt;Patch committed&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332285" name="regression.tar" size="30720" author="phil@steitz.com" created="Sun, 25 May 2003 22:01:22 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20224</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Mon, 26 May 2003 09:14:53 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-19] [math] patch to fix percentile bug.</title>
                <link>https://issues.apache.org/jira/browse/MATH-19</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description></description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341003">MATH-19</key>
            <summary>[math] patch to fix percentile bug.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Sat, 27 Sep 2003 11:56:35 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405174" author="brentworden" created="Sat, 27 Sep 2003 11:56:58 +0000"  >&lt;p&gt;Created an attachment (id=8366)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12405175" author="mdiggory@gmail.com" created="Thu, 16 Oct 2003 22:18:15 +0000"  >&lt;p&gt;About time I got to this. Thanks Brent&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332550" name="percentile-bug.txt" size="1587" author="brentworden" created="Sat, 27 Sep 2003 11:56:58 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>23453</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 16 Oct 2003 22:18:15 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-18] [math] ComplexFormat ignores imaginaryFormat</title>
                <link>https://issues.apache.org/jira/browse/MATH-18</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Constructors for ComplexFormat allow different custom NumberFormats to be&lt;br/&gt;
specified for real and imaginary parts.  These are stored in instance fields&lt;br/&gt;
realFormat and imaginaryFormat.  The private method formatDouble that formats&lt;br/&gt;
real and imaginary parts ignores the actual parameter specifying the format,&lt;br/&gt;
using realFormat all the time.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12342827">MATH-18</key>
            <summary>[math] ComplexFormat ignores imaginaryFormat</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 2 Jan 2006 14:37:16 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12411185" author="brentworden" created="Wed, 4 Jan 2006 00:32:03 +0000"  >&lt;p&gt;Fixed in revision 365663.  ComplexFormat was not formatting double values with &lt;br/&gt;
the provided NumberFormat.  Instead, the real part format was always used.&lt;/p&gt;</comment>
                    <comment id="12411186" author="brentworden" created="Wed, 4 Jan 2006 01:48:24 +0000"  >&lt;p&gt;actually fixed in revision 365680.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>38091</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 4 Jan 2006 00:32:03 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-17] [math] Add significance tests</title>
                <link>https://issues.apache.org/jira/browse/MATH-17</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch adds t- and chi-square tests to TestStatistic.  It also fixes&lt;br/&gt;
checkstyle and clover test coverage gaps.  Tests are implemented using the&lt;br/&gt;
distribution framework to provide exact p-values as well as fixed significance&lt;br/&gt;
tests, using double[] data arrays or Univariates to describe sample data.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340809">MATH-17</key>
            <summary>[math] Add significance tests</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jun 2003 07:09:40 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404570" author="phil@steitz.com" created="Mon, 23 Jun 2003 07:10:38 +0000"  >&lt;p&gt;Created an attachment (id=6932)&lt;br/&gt;
patches to TestStatistic, TestStatisticImpl, TestStatisticTest&lt;/p&gt;</comment>
                    <comment id="12404571" author="mdiggory@gmail.com" created="Wed, 25 Jun 2003 08:37:45 +0000"  >&lt;p&gt;applied, tested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332378" name="testStatisticPatch.txt" size="51490" author="phil@steitz.com" created="Mon, 23 Jun 2003 07:10:38 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21003</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 25 Jun 2003 08:37:45 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-16] [math] Add dimension checks to RealMatrixImpl solve and LUDecompose</title>
                <link>https://issues.apache.org/jira/browse/MATH-16</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch adds a check to RealMatrixImpl.solve() to make sure that the&lt;br/&gt;
coefficient matrix is square and a check to RealMatrixImpl.LUDecompose() to make&lt;br/&gt;
sure that the row dimension of the matrix is &amp;gt;= the column dimension.  Thanks to&lt;br/&gt;
Al Chou for pointing out these gaps.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340810">MATH-16</key>
            <summary>[math] Add dimension checks to RealMatrixImpl solve and LUDecompose</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jun 2003 10:52:48 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404572" author="phil@steitz.com" created="Mon, 23 Jun 2003 10:54:13 +0000"  >&lt;p&gt;Created an attachment (id=6934)&lt;br/&gt;
patches to RealMatrix (javadoc), RealMatrixImpl, RealMatrixImplTest&lt;/p&gt;</comment>
                    <comment id="12404573" author="mdiggory@gmail.com" created="Wed, 25 Jun 2003 08:42:14 +0000"  >&lt;p&gt;applied and tested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332379" name="realMatrixPatch.txt" size="3660" author="phil@steitz.com" created="Mon, 23 Jun 2003 10:54:13 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21005</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 25 Jun 2003 08:42:14 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-15] [math] patch - license spelling correction, convergence exception change</title>
                <link>https://issues.apache.org/jira/browse/MATH-15</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The Apache license misspelled acknowledgement.  Made correction to license file &lt;br/&gt;
and to all source file headings.&lt;/p&gt;

&lt;p&gt;Made ConvergenceException extend MathException and moved ConvergenceException &lt;br/&gt;
to the org.apache.commons.math packages.&lt;/p&gt;

&lt;p&gt;The change of exception heirarchy forced changes in other parts of commons-&lt;br/&gt;
math.  All affected, low level routines (gamma, beta, cf, ...) now throw a &lt;br/&gt;
MathException.  All affected, distribution routines now catch a MathException &lt;br/&gt;
and return NaN.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341026">MATH-15</key>
            <summary>[math] patch - license spelling correction, convergence exception change</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Fri, 10 Oct 2003 11:43:29 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405256" author="brentworden" created="Fri, 10 Oct 2003 11:44:07 +0000"  >&lt;p&gt;Created an attachment (id=8520)&lt;br/&gt;
patch file containing all the changes.&lt;/p&gt;</comment>
                    <comment id="12405257" author="mdiggory@gmail.com" created="Thu, 16 Oct 2003 22:28:27 +0000"  >&lt;p&gt;Had to do some reverse patch trickery to get this applied, please doublecheck my&lt;br/&gt;
work by running the tests.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332576" name="license-spelling.txt" size="293628" author="brentworden" created="Fri, 10 Oct 2003 11:44:07 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>23716</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 16 Oct 2003 22:28:27 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-14] [patch] Gamma.logGamma performance</title>
                <link>https://issues.apache.org/jira/browse/MATH-14</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;I did some profiling on a project and found a lot of time spent in&lt;br/&gt;
Gamma.logGamma() (I&apos;m doing a lot of t-tests.)  I found some tweaks to the code&lt;br/&gt;
that give me a 65% performance increase.  I&apos;m using JDK 1.5.&lt;/p&gt;

&lt;p&gt;Let&apos;s see if I can attach a patch here...&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12341770">MATH-14</key>
            <summary>[patch] Gamma.logGamma performance</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="kgeis">Ken Geis</reporter>
                        <labels>
                    </labels>
                <created>Mon, 4 Oct 2004 14:17:49 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12407706" author="kgeis" created="Mon, 4 Oct 2004 14:19:12 +0000"  >&lt;p&gt;Created an attachment (id=12924)&lt;br/&gt;
logGamma performance patch&lt;/p&gt;</comment>
                    <comment id="12407707" author="kgeis" created="Mon, 4 Oct 2004 14:21:18 +0000"  >&lt;p&gt;I would attribute the performance increase as follows: 2 or 3% from reversing&lt;br/&gt;
the loop order, and even improvements (~30% each) from moving the log(PI) out of&lt;br/&gt;
the function and merging two calls to log.&lt;/p&gt;</comment>
                    <comment id="12407708" author="phil@steitz.com" created="Fri, 8 Oct 2004 12:55:49 +0000"  >&lt;p&gt;Patch applied.  Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12333149" name="gamma-performance.diff" size="1209" author="kgeis" created="Mon, 4 Oct 2004 14:19:12 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>31522</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 8 Oct 2004 12:55:49 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-13] [math] changed the univariate real solver factory</title>
                <link>https://issues.apache.org/jira/browse/MATH-13</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Made the UnivariateRealSolverFactory an abstract factory with one concrete &lt;br/&gt;
factory: UnivariateRealSolverFactoryImpl.&lt;/p&gt;

&lt;p&gt;Removed the solve() convience methods from the factory and created a new &lt;br/&gt;
UnivariateRealSolverUtil class.&lt;/p&gt;

&lt;p&gt;Added a few javadoc comments.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340877">MATH-13</key>
            <summary>[math] changed the univariate real solver factory</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Thu, 31 Jul 2003 04:54:19 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404765" author="brentworden" created="Thu, 31 Jul 2003 04:54:46 +0000"  >&lt;p&gt;Created an attachment (id=7594)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404766" author="tobrien@discursive.com" created="Thu, 31 Jul 2003 05:14:25 +0000"  >&lt;p&gt;Patch applied and site regenerated to boot.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332436" name="solver-factory.diff" size="41764" author="brentworden" created="Thu, 31 Jul 2003 04:54:46 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>22002</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 31 Jul 2003 05:14:25 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-12] [math] RunTimeException in EmpiricalDistributionImpl.load(double[])</title>
                <link>https://issues.apache.org/jira/browse/MATH-12</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Overview Description: &lt;/p&gt;

&lt;p&gt;I get the following RunTimeException when loading data into an instance of&lt;br/&gt;
EmpiricalDistributionImpl:&lt;/p&gt;

&lt;p&gt;java.lang.RuntimeException: Index: 1000, Size: 1000&lt;br/&gt;
     at org.apache.commons.math.random.EmpiricalDistributionImpl.load&lt;br/&gt;
(EmpiricalDistributionImpl.java:111)&lt;br/&gt;
     at BreakEmpiricalDistributionImpl.main(BreakEmpiricalDistributio&lt;br/&gt;
nImpl.java:7)&lt;br/&gt;
Exception in thread &quot;main&quot;&lt;/p&gt;

&lt;p&gt;Here is a small program to reproduce the problem:&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.random.EmpiricalDistributionImpl;&lt;/p&gt;

&lt;p&gt;public class BreakEmpiricalDistributionImpl {&lt;/p&gt;

&lt;p&gt;  public static void main(String[] args) {&lt;br/&gt;
    double[] x = new double[] {9474.94326071674, 2080107.8865462579};&lt;br/&gt;
    new EmpiricalDistributionImpl().load&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;;&lt;br/&gt;
  }&lt;/p&gt;

&lt;p&gt;}&lt;/p&gt;

&lt;p&gt;Build Date &amp;amp; Platform: &lt;/p&gt;

&lt;p&gt;Build 2005-08-31 on Windows 2000 with Sun JDK 1.4.2_09&lt;/p&gt;

&lt;p&gt;    Additional Builds and Platforms:&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Windows 2000&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12342524">MATH-12</key>
            <summary>[math] RunTimeException in EmpiricalDistributionImpl.load(double[])</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="keithmcdonald@sympatico.ca">Keith McDonald</reporter>
                        <labels>
                    </labels>
                <created>Thu, 1 Sep 2005 05:17:16 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12410309" author="phil@steitz.com" created="Thu, 1 Sep 2005 14:27:24 +0000"  >&lt;p&gt;The code should probably include a guard for this and throw a more meaningful&lt;br/&gt;
exception, but this class is not designed to be used with very small data sets.&lt;br/&gt;
Are you trying to produce random draws from a discrete distribution with point&lt;br/&gt;
masses on the two values?  This class is designed to use empirical data to&lt;br/&gt;
simulate continuous distributions (see the reference in the class header comment).  &lt;/p&gt;

&lt;p&gt;As stated in the Usage Notes section of the header comment, the binCount should&lt;br/&gt;
be set to a number smaller than than the sample size. In this case, 1 is the&lt;br/&gt;
only possible value; but this will not work, since bins of size 1 have no&lt;br/&gt;
variance.  So the minimum possible acceptable values are effectively 4&lt;br/&gt;
datapoints with binCount = 2. &lt;/p&gt;

&lt;p&gt;The javadoc should probably be updated to make this clear and a binCount -&lt;br/&gt;
sample size guard should be added.&lt;/p&gt;</comment>
                    <comment id="12410310" author="keithmcdonald@sympatico.ca" created="Thu, 1 Sep 2005 20:55:27 +0000"  >&lt;p&gt;Thank you for responding to this bug report so quickly!&lt;/p&gt;

&lt;p&gt;I hit the problem with a larger sample size than the two samples that I gave in&lt;br/&gt;
the code for reproducing the problem. I just wanted to provide a small program&lt;br/&gt;
that could reproduce the problem easily. I think the problem is caused by the&lt;br/&gt;
limitations of the precision of the variable &quot;delta&quot;. &lt;/p&gt;

&lt;p&gt;When delta is produced by dividing (max - min) / binCount in the method&lt;br/&gt;
fillBinStats, regardless of how many samples you have, it is possible to get a&lt;br/&gt;
number that, when multiplied by binCount, is slightly smaller than (max - min).&lt;br/&gt;
So, when inputArray&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; is equal to max, (inputArray&lt;span class=&quot;error&quot;&gt;&amp;#91;i&amp;#93;&lt;/span&gt; - min) / delta equals a&lt;br/&gt;
number slightly larger than binCount. When the Math.ceil method is applied to&lt;br/&gt;
this number, you get binCount + 1, which , even after subtracting 1 as is done&lt;br/&gt;
in the computeBinStats methods, is too large for binStats.get to take as an&lt;br/&gt;
argument and this leads to the RunTimeException.&lt;/p&gt;

&lt;p&gt;My suggestion for fixing this would be to add a call to Math.min(x,&lt;br/&gt;
binStats.size()-1) before passing the result to binStats.get, where x is the&lt;br/&gt;
current expression in computeBinStats whose result is being passed to&lt;br/&gt;
binStats.get. This change would need to go into two places: the computeBinStats&lt;br/&gt;
method of ArrayDataAdapter and the computeBinStats method of StreamDataAdapter.&lt;/p&gt;

&lt;p&gt;Here is a replacement program that reproduces the problem with 10,000 samples.&lt;/p&gt;

&lt;p&gt;import org.apache.commons.math.random.EmpiricalDistributionImpl;&lt;/p&gt;

&lt;p&gt;public class BreakEmpiricalDistributionImpl {&lt;/p&gt;

&lt;p&gt;  public static void main(String[] args) {&lt;br/&gt;
    final int NUMBER_OF_SAMPLES = 10000;&lt;br/&gt;
    double[] x = new double&lt;span class=&quot;error&quot;&gt;&amp;#91;NUMBER_OF_SAMPLES&amp;#93;&lt;/span&gt;;&lt;br/&gt;
    x&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; = 9474.94326071674;&lt;br/&gt;
    x&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; = 2080107.8865462579;&lt;br/&gt;
    for (int i = 2; i &amp;lt; NUMBER_OF_SAMPLES; i++) {
      x[i] = Math.max(Math.min(x[0] + x[1] * Math.random(), x[1]), x[0]);
    }&lt;br/&gt;
    new EmpiricalDistributionImpl().load&lt;img class=&quot;emoticon&quot; src=&quot;https://issues.apache.org/jira/images/icons/emoticons/error.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;;&lt;br/&gt;
  }&lt;/p&gt;

&lt;p&gt;}&lt;/p&gt;</comment>
                    <comment id="12410311" author="phil@steitz.com" created="Fri, 2 Sep 2005 22:40:12 +0000"  >&lt;p&gt;Thanks for the clarification.  Yes, this looks like a bug. &lt;/p&gt;</comment>
                    <comment id="12410312" author="phil@steitz.com" created="Sun, 4 Sep 2005 09:41:53 +0000"  >&lt;p&gt;Fixed in svn r267527, nightly builds starting 9/3/05 and 1.1 RC3.&lt;br/&gt;
Thanks!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>36450</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 1 Sep 2005 14:27:24 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-11] SplineInterpolator gives bad interpolation</title>
                <link>https://issues.apache.org/jira/browse/MATH-11</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The CubicSplineFunction does not fit on each interval:&lt;/p&gt;

&lt;p&gt;&amp;gt; Replace&lt;br/&gt;
&amp;gt;             double dquot = (yval&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; - yval&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;) / (xval&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; - xval&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;);&lt;br/&gt;
&amp;gt;             for (int i = 0; i &amp;lt; n - 1; i++) {
&amp;gt;                               double dquotNext =
&amp;gt;                                      (yval[i + 2] - yval[i + 1]) / (xval[i
&amp;gt; + 2] - xval[i + 1]);
&amp;gt;                             b[i] = 6.0 * (dquotNext - dquot);
&amp;gt;                             d[i] = 2.0 * (xval[i + 2] - xval[i]);
&amp;gt;                             dquot = dquotNext;
&amp;gt;                   }&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; With&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt;             //Source: &lt;a href=&quot;http://mathworld.wolfram.com/CubicSpline.html&quot;&gt;http://mathworld.wolfram.com/CubicSpline.html&lt;/a&gt;&lt;br/&gt;
&amp;gt;             for (int i = 0; i &amp;lt; n - 1; i++) {
&amp;gt;                   b[i] = 3.0 * (yval[i+1] - yval[i]);
&amp;gt;                   d[i] = (i&amp;gt;0 &amp;amp;&amp;amp; i&amp;lt;n-2)? 4.0: 2.0 ;
&amp;gt;             }&lt;br/&gt;
&amp;gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341376">MATH-11</key>
            <summary>SplineInterpolator gives bad interpolation</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jfreyss@hotmail.com">Joel Freyss</reporter>
                        <labels>
                    </labels>
                <created>Tue, 30 Mar 2004 00:14:17 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406378" author="phil@steitz.com" created="Sat, 3 Apr 2004 05:55:13 +0000"  >&lt;p&gt;The implementation has been fixed and tests have been added to verify&lt;br/&gt;
consistency (interpolator assigns correct values at knot points, polynomial&lt;br/&gt;
derivatives agree, etc.) &lt;/p&gt;

&lt;p&gt;Fixed in nightly builds starting 4/2/04.&lt;/p&gt;

&lt;p&gt;Thanks for reporting this problem.  Reopen if you still get bad results.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>28019</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sat, 3 Apr 2004 05:55:13 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-10] [math] fixed some checkstyle warnings</title>
                <link>https://issues.apache.org/jira/browse/MATH-10</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Also, added maven.javadoc.links to project.properties so, when maven is used to &lt;br/&gt;
produce javadoc, references to external API&apos;s will have valid links.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340850">MATH-10</key>
            <summary>[math] fixed some checkstyle warnings</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Fri, 11 Jul 2003 22:44:27 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404694" author="brentworden" created="Fri, 11 Jul 2003 22:45:19 +0000"  >&lt;p&gt;Created an attachment (id=7247)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404695" author="tobrien@discursive.com" created="Fri, 11 Jul 2003 23:02:49 +0000"  >&lt;p&gt;Patch applied, thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332412" name="cleanup-patch.diff" size="21342" author="brentworden" created="Fri, 11 Jul 2003 22:45:19 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21516</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Fri, 11 Jul 2003 23:02:49 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-9] [PATCH] [math] Natural spline interpolation</title>
                <link>https://issues.apache.org/jira/browse/MATH-9</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Appended a tgz with new files for interpolation with an natural cubic spline.&lt;br/&gt;
Caveats: several TODOs in the source, and the unit tests must be reworked.&lt;br/&gt;
The patch depends on the UnivariateRealFunction interface.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340813">MATH-9</key>
            <summary>[PATCH] [math] Natural spline interpolation</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="j3322ptm@yahoo.de">J.Pietschmann</reporter>
                        <labels>
                    </labels>
                <created>Tue, 24 Jun 2003 01:28:43 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404582" author="j3322ptm@yahoo.de" created="Tue, 24 Jun 2003 01:30:43 +0000"  >&lt;p&gt;Created an attachment (id=6940)&lt;br/&gt;
Proposed patch&lt;/p&gt;</comment>
                    <comment id="12404583" author="hotfusionman@yahoo.com" created="Tue, 24 Jun 2003 10:40:29 +0000"  >&lt;p&gt;Created an attachment (id=6949)&lt;br/&gt;
Proposed enhancement to SplineInterpolator (persistence of c[][] array as instance variable)&lt;/p&gt;</comment>
                    <comment id="12404584" author="mdiggory@gmail.com" created="Wed, 25 Jun 2003 08:16:54 +0000"  >&lt;p&gt;I&apos;ll apply this, but its really alot easier to apply &quot;cvs generated patches&quot;&lt;br/&gt;
over tarballs or unix diff. I would prefer this format over all others.&lt;/p&gt;

&lt;p&gt;Not only does cvs diff generate patches directly against the cvs copies,&lt;br/&gt;
assuring your diffing against whats presently in the cvs, but you can also add&lt;br/&gt;
files using it. In otherwords, if you create a file and the run cvs diff on the&lt;br/&gt;
directory, when I apply the patch, the file will be created.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332384" name="SplineInterpolator.diff.gz" size="2116" author="hotfusionman@yahoo.com" created="Tue, 24 Jun 2003 10:40:29 +0000" />
                    <attachment id="12332383" name="m.tar.gz" size="4780" author="j3322ptm@yahoo.de" created="Tue, 24 Jun 2003 01:30:43 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>2.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>21023</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Tue, 24 Jun 2003 10:40:29 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-8] [math]TTest should not throw IllegalArgumentException for small samples</title>
                <link>https://issues.apache.org/jira/browse/MATH-8</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Currently, the TTest implementation requires that the minimum of the two sample&lt;br/&gt;
sizes be at least 5.  This is too restrictive.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341455">MATH-8</key>
            <summary>[math]TTest should not throw IllegalArgumentException for small samples</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 18 May 2004 11:29:10 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406626" author="phil@steitz.com" created="Sun, 23 May 2004 12:08:01 +0000"  >&lt;p&gt;The minimum sample size has been reduced to 2.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29050</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-7] [math] user guide additions - special functions</title>
                <link>https://issues.apache.org/jira/browse/MATH-7</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;Adds text to the special function portion of the user guide.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341001">MATH-7</key>
            <summary>[math] user guide additions - special functions</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Sep 2003 22:17:49 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12405169" author="brentworden" created="Wed, 24 Sep 2003 22:18:09 +0000"  >&lt;p&gt;Created an attachment (id=8331)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12405170" author="j3322ptm@yahoo.de" created="Thu, 25 Sep 2003 03:15:58 +0000"  >&lt;p&gt;Applied, thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332548" name="special-xdoc.txt" size="3298" author="brentworden" created="Wed, 24 Sep 2003 22:18:09 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>23389</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Thu, 25 Sep 2003 03:15:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-6] [math] Remove dependency on commons-lang</title>
                <link>https://issues.apache.org/jira/browse/MATH-6</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The attached patch copies implementation from&lt;br/&gt;
o.a.c.l.Exception.NestableException and its dependencies into MathException. &lt;br/&gt;
Test cases from o.a.c.l.AbstractNestableTestCase are also added to&lt;br/&gt;
MathExceptionTest.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12341558">MATH-6</key>
            <summary>[math] Remove dependency on commons-lang</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Wed, 7 Jul 2004 20:01:25 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:02 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:02 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12406973" author="phil@steitz.com" created="Wed, 7 Jul 2004 20:02:25 +0000"  >&lt;p&gt;Created an attachment (id=12053)&lt;br/&gt;
Patch to add implementation code from commons-lang&lt;/p&gt;</comment>
                    <comment id="12406974" author="phil@steitz.com" created="Mon, 26 Jul 2004 01:30:55 +0000"  >&lt;p&gt;Changes based on &lt;span class=&quot;error&quot;&gt;&amp;#91;collections&amp;#93;&lt;/span&gt; FunctorException committed.  Dependency has been&lt;br/&gt;
removed.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332975" name="exceptionPatch" size="46609" author="phil@steitz.com" created="Wed, 7 Jul 2004 20:02:25 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>29948</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-4] [math] Sources will not compile using JDK 1.3</title>
                <link>https://issues.apache.org/jira/browse/MATH-4</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The following classes contain JDK 1.4-dependent code&lt;br/&gt;
MatrixExeption, InvalidMatrixException (nested exception support)&lt;br/&gt;
BeanTransformer (Expression)&lt;br/&gt;
CertifiedDataAbstractTest (Expression)&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
            <key id="12341920">MATH-4</key>
            <summary>[math] Sources will not compile using JDK 1.3</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="phil@steitz.com">Phil Steitz</reporter>
                        <labels>
                    </labels>
                <created>Mon, 6 Dec 2004 14:19:22 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:01 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:01 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12408251" author="phil@steitz.com" created="Mon, 6 Dec 2004 14:54:36 +0000"  >&lt;p&gt;Changes to eliminate JDK 1.4 dependencies have been committed. &lt;br/&gt;
InvalidMatrixException and MatrixIndexException no longer support nesting.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>32538</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[MATH-3] [math] Corrections to Constructor Fraction(double)</title>
                <link>https://issues.apache.org/jira/browse/MATH-3</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;The constructor for Fraction fails for doubles which are almost integer.&lt;/p&gt;

&lt;p&gt;examples should be inserted in th etest case:&lt;/p&gt;

&lt;p&gt;    public void testConstructorDouble() {&lt;br/&gt;
        try {
.....            
            assertFraction(0, 1, new Fraction(0.00000000000001));
            assertFraction(2, 5, new Fraction(0.40000000000001));
            assertFraction(15, 1, new Fraction(15.0000000000001));
            
        } catch (ConvergenceException ex) {
            fail(ex.getMessage());
        }&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;The fix for this problem is to include the following code in the constructor:&lt;/p&gt;


&lt;p&gt;        int n = 0;&lt;br/&gt;
        boolean stop = false;&lt;/p&gt;

&lt;p&gt;        // check for (almost) integer arguments, which should not go&lt;br/&gt;
        // to iterations.&lt;br/&gt;
        if (Math.abs(a0 - value)&amp;lt;epsilon){
            this.numerator = a0;
            this.denominator = 1;
            return;
        }&lt;br/&gt;
        do {&lt;br/&gt;
            ++n;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
            <key id="12342327">MATH-3</key>
            <summary>[math] Corrections to Constructor Fraction(double)</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="j.weimar@tu-bs.de">J&#246;rg Weimar</reporter>
                        <labels>
                    </labels>
                <created>Mon, 20 Jun 2005 21:14:47 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:01 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:01 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12409655" author="phil@steitz.com" created="Sun, 26 Jun 2005 10:55:04 +0000"  >&lt;p&gt;Patches applied. Thanks.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>0.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>35434</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Sun, 26 Jun 2005 10:55:04 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-2] [math] fixed some javadoc and checkstyle warnings</title>
                <link>https://issues.apache.org/jira/browse/MATH-2</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description></description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340773">MATH-2</key>
            <summary>[math] fixed some javadoc and checkstyle warnings</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Tue, 10 Jun 2003 03:21:25 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:01 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:01 +0000</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404430" author="brentworden" created="Tue, 10 Jun 2003 03:21:56 +0000"  >&lt;p&gt;Created an attachment (id=6718)&lt;br/&gt;
Freq.java patch&lt;/p&gt;</comment>
                    <comment id="12404431" author="brentworden" created="Tue, 10 Jun 2003 03:22:23 +0000"  >&lt;p&gt;Created an attachment (id=6719)&lt;br/&gt;
BeanListUnivariateImpl.java patch&lt;/p&gt;</comment>
                    <comment id="12404432" author="brentworden" created="Tue, 10 Jun 2003 03:22:56 +0000"  >&lt;p&gt;Created an attachment (id=6720)&lt;br/&gt;
RandomDataImpl.java patch&lt;/p&gt;</comment>
                    <comment id="12404433" author="mdiggory@gmail.com" created="Wed, 11 Jun 2003 08:36:02 +0000"  >&lt;p&gt;Brent, these patches are each on multiple files spanning the entire math&lt;br/&gt;
directory, I want to verify that this was this your intention.&lt;/p&gt;

&lt;p&gt;The first patch attempts to add the files getting patched were previously added&lt;br/&gt;
by your last F-dist patch. It also &quot;gutts&quot; the contents of some of the tests&lt;br/&gt;
(the FixedDoubleArrayTest class for one).&lt;/p&gt;

&lt;p&gt;Was it your intention to have multiple files altered in each of these patches?&lt;/p&gt;</comment>
                    <comment id="12404434" author="brentworden" created="Wed, 11 Jun 2003 12:54:02 +0000"  >&lt;p&gt;Oops.  I summitted these things I hast.  I&apos;ll clean them up and reopen the &lt;br/&gt;
issue later.&lt;/p&gt;</comment>
                    <comment id="12404435" author="brentworden" created="Wed, 11 Jun 2003 13:51:15 +0000"  >&lt;p&gt;Created an attachment (id=6750)&lt;br/&gt;
Latest patch (KEEP)&lt;/p&gt;</comment>
                    <comment id="12404436" author="brentworden" created="Wed, 11 Jun 2003 13:52:48 +0000"  >&lt;p&gt;I&apos;ve attached a leaner patch file.  Try applying &quot;Latest patch&quot;.  The others &lt;br/&gt;
can be ignored.&lt;/p&gt;</comment>
                    <comment id="12404437" author="mdiggory@gmail.com" created="Wed, 11 Jun 2003 18:32:07 +0000"  >&lt;p&gt;Applied the last patch successfully. Ran Unit tests successfully. thanks Brent&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332334" name="beanlistunivariateimpl-checkstyle-patch.txt" size="118354" author="brentworden" created="Tue, 10 Jun 2003 03:22:23 +0000" />
                    <attachment id="12332336" name="checkstyle-patch.txt" size="15716" author="brentworden" created="Wed, 11 Jun 2003 13:51:15 +0000" />
                    <attachment id="12332333" name="freq-checkstyle-patch.txt" size="116522" author="brentworden" created="Tue, 10 Jun 2003 03:21:56 +0000" />
                    <attachment id="12332335" name="randomdataimpl-checkstyle-patch.txt" size="128595" author="brentworden" created="Tue, 10 Jun 2003 03:22:56 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>4.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>20627</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 11 Jun 2003 08:36:02 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[MATH-1] [math] new approach to testing against certified data sets.</title>
                <link>https://issues.apache.org/jira/browse/MATH-1</link>
                <project id="12310485" key="MATH">Commons Math</project>
                        <description>&lt;p&gt;With the talk of testing commons-math against additional data sets, I wanted to &lt;br/&gt;
try to make our certified data tests a little more flexible in terms of the &lt;br/&gt;
data they can load and the summary statistics they can verify.&lt;/p&gt;

&lt;p&gt;What I&apos;ve initially come up with is a simple data format similar to the &lt;br/&gt;
existing NIST data set files.  The valid data file consists of blank lines, # &lt;br/&gt;
style comment lines, certified summary statistic lines, and data value lines.&lt;/p&gt;

&lt;p&gt;For statistic verification, blank lines and comments are ignored.&lt;/p&gt;

&lt;p&gt;A line is deem a certified summary statistic values if it contains an &apos;=&apos; &lt;br/&gt;
character.  Theses lines are parsed into name/value pairs.  The name &lt;br/&gt;
corresponds to a property of DescriptiveStatistics and/or SummaryStatistics and &lt;br/&gt;
the value is the expected value of the summary statistic.&lt;/p&gt;

&lt;p&gt;All other lines not identified as one of the previous three types is deemed a &lt;br/&gt;
data value line.  With these lines a double value is extracted from the line &lt;br/&gt;
and added to both a DescriptiveStatistics object and a SummaryStatistics object.&lt;/p&gt;

&lt;p&gt;The actual verification process used bean introspection to access the actual &lt;br/&gt;
summary statistic properties from the loaded DescriptiveStatistics and &lt;br/&gt;
SummaryStatistics objects.  These actual values are then compared to the &lt;br/&gt;
expected summary statistic values.&lt;/p&gt;

&lt;p&gt;I&apos;ll attach a patch which contains all the changes.  I&apos;ll hold off on &lt;br/&gt;
committing it until everyone has had a chance to look it over and provide some &lt;br/&gt;
feedback.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: other&lt;br/&gt;
Platform: Other&lt;/p&gt;</environment>
            <key id="12340666">MATH-1</key>
            <summary>[math] new approach to testing against certified data sets.</summary>
                <type id="1" iconUrl="https://issues.apache.org/jira/images/icons/bug.gif">Bug</type>
                                <priority id="3" iconUrl="https://issues.apache.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="https://issues.apache.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Fixed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="brentworden">Brent Worden</reporter>
                        <labels>
                    </labels>
                <created>Tue, 16 Mar 2004 13:42:23 +0000</created>
                <updated>Thu, 23 Apr 2009 02:26:01 +0000</updated>
                    <resolved>Thu, 23 Apr 2009 02:26:01 +0000</resolved>
                            <version>Nightly Builds</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                                    <comments>
                    <comment id="12404114" author="brentworden" created="Tue, 16 Mar 2004 13:42:48 +0000"  >&lt;p&gt;Created an attachment (id=10800)&lt;br/&gt;
patch file&lt;/p&gt;</comment>
                    <comment id="12404115" author="phil@steitz.com" created="Wed, 17 Mar 2004 11:18:58 +0000"  >&lt;p&gt;This is very nice.  The one small additional improvement that I would suggest&lt;br/&gt;
would be to have CertifiedDataTest expose a &quot;tolerance&quot; property that individual&lt;br/&gt;
tests could override &amp;#8211; i.e. get rid of the hard-coded 10E-5 in&lt;br/&gt;
testCertifiedValues(). &lt;/p&gt;</comment>
                    <comment id="12404116" author="brentworden" created="Thu, 18 Mar 2004 13:57:26 +0000"  >&lt;p&gt;I went ahead and checking in the changes.  I took you&apos;re advice and added a &lt;br/&gt;
getMaximumAbsoluteError method to provide a more flexible tolerance check.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12332235" name="new-certified-test-data-approach.diff" size="17571" author="brentworden" created="Tue, 16 Mar 2004 13:42:48 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_12310310" key="com.atlassian.jira.toolkit:attachments">
                <customfieldname>Attachment count</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>1.0</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10010" key="com.atlassian.jira.plugin.system.customfieldtypes:importid">
                <customfieldname>Bugzilla Id</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>27692</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_12310220" key="com.atlassian.jira.ext.charting:firstresponsedate">
                <customfieldname>Date of First Response</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>Wed, 17 Mar 2004 11:18:58 +0000</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>
</channel>
</rss>