[jira] Commented: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ https://issues.apache.org/jira/browse/MATH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511356 ] Luc Maisonobe commented on MATH-160: The applied fix added new public methods to the interface. This is considered an incompatible API change by the clirr maven plugin which now fails when comparing with version 1.1. Should the next version been bumped to 2.0 ? Previous discussions on the version numbering missed the point with this issue. > Chi-Square Test for Comparing two binned Data Sets > -- > > Key: MATH-160 > URL: https://issues.apache.org/jira/browse/MATH-160 > Project: Commons Math > Issue Type: New Feature >Reporter: Matthias Hummel >Priority: Minor > Fix For: 1.2 > > Attachments: commons-math.patch > > > Current Chi-Square test implementation only supports standard Chi-Square > testing with respect to known distribution. We needed testing for comparison > of two sample data sets where the distribution can be unknown. For this case > the Chi-Square test has to be computed in a different way so that both error > contributions (one for each sample data set) are taken into account. See > Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MATH-156) Brent solver is non-optimal, because it doesn't use the user's guess.
[ https://issues.apache.org/jira/browse/MATH-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-156. Resolution: Fixed Fix Version/s: (was: 1.2) Nightly Builds fixed in SVN revision 536283 (checked in 2007-05-08) > Brent solver is non-optimal, because it doesn't use the user's guess. > - > > Key: MATH-156 > URL: https://issues.apache.org/jira/browse/MATH-156 > Project: Commons Math > Issue Type: Improvement >Reporter: Tyler Ward > Assigned To: Luc Maisonobe > Fix For: Nightly Builds > > > Hi guys, I noticed that your brent solver isn't using the initial guess given > by the user. This can often radically improve the performance of the solver. > In my tests, it improved it by roughly 30% or more, with a decent guess. > Basically, we should try the guess first. If that's close enough, rreturn it. > Otherwise, try one of the end points. If that's close enough, return it. Then > if that brackets, go into the main loop. If that doesn't bracket, then we > instead try the other endpoint. If that's close enough, return it. If that > doesn't bracket, throw an exception. If it does bracket, go into the main > loop with all three trial points available, allowing the quadratic > interpolation to be used immediately. > Worst case scenario, the initial guess doesn't bracket. In that case it is > better than the default algorithm only if the user's initial guess is better > than linear interpolation, which I imagine it almost always would be. If the > user can't guess better than linear interpolation, presumably they wouldn't > provide a guess at all, and then nothing would change. > It's a small addition, less than 100 lines of code. I can't send it in due to > legal at work, but from the above ideas, you should be able to put it in > easily. One caveat. You may need to slightly modify the baisic solve(double, > double) method to linearly interpolate a good beginning point and then break > out a six double (solve(x0, y0, x1, y1, x2, y2)) method that both solve(min, > max) and solve(min, max, initial) can use. If you don't do this, then > solve(min, max) will bisect on its first iteration rather than intepolating, > which could cost performance. If you do break it out like so, then this will > always perform better than the current implementation. > As a good case study, here's our situation from work. > We are trying to compute a root, we know it falls in a VERY large interval > (in this case -1.0 to 1.0), but more than 99% of the time it will be between > (say) 1.04 and 1.07. We can guess with stunning accuracy, at least 90% of the > time we can come to within 10^-4 for very little cost (a very nice cubic > approximation of the more complicated function), but we really need it to > within 10^-8 or better. In addition, that 1% of the time, it can fall in very > strange areas (0.9, or -0.3 or so), and our guess isn't very good when that > happens. So we can't tighten down the interval, because that would cause > spurious errors, and at the same time your linear interpolation isn't going > to be very good at all. It easily takes you 3 or 4 steps to get as close as > our first guess. Using the first guess in this manner would cut the steps to > convergence from about 8-10 to about 3-5. A speed up of around 100%, with no > loss in accuracy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-165) Simplify use of "EstimationProblem"
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe updated MATH-165:
---
Fix Version/s: 1.2
> Simplify use of "EstimationProblem"
>
>
> Key: MATH-165
> URL: https://issues.apache.org/jira/browse/MATH-165
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
> Assigned To: Luc Maisonobe
>Priority: Minor
> Fix For: 1.2
>
>
> The use of the "EstimationProblem" interface could be simplified by providing
> a helper (abstract) class that would implement
> the "getMeasurements" "getAllParameters" and "getUnboundParameters" methods.
> Currently, each new implementation of the interface has to do it even if they
> are typically only called from the "Estimator" class (and not by the user
> code).
> That same helper class could also take care of storing the partial
> derivatives.
> A skeleton for the requested class could be as follows:
> public abstract class SimpleEstimationProblem
> implements EstimationProblem {
> // ... storage for measurements and partial derivatives ...
>
> protected void addParameter(EstimatedParameter p,
> ComputableFunction partial,
> boolean isBound) {
> // ...
> }
> protected void addParameter(EstimatedParameter p,
> ComputableFunction partial) {
> addParameter(p, partial, false);
> }
> protected double getPartial(EstimatedParameter p,
> double x) {
> // ...
> }
> protected void addMeasurement(WeightedMeasurement m) {
> _observations.add(m);
> }
> public WeightedMeasurement[] getMeasurements() {
> // ...
> }
> public EstimatedParameter[] getAllParameters() {
> // ...
> }
> public EstimatedParameter[] getUnboundParameters() {
> // ...
> }
> }
> Best,
> Gilles
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-165) Simplify use of "EstimationProblem"
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496925
]
Luc Maisonobe commented on MATH-165:
This seems a great idea to me. It could be easily implemented for 1.2 we are
going to release.
> Simplify use of "EstimationProblem"
>
>
> Key: MATH-165
> URL: https://issues.apache.org/jira/browse/MATH-165
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
> Assigned To: Luc Maisonobe
>Priority: Minor
>
> The use of the "EstimationProblem" interface could be simplified by providing
> a helper (abstract) class that would implement
> the "getMeasurements" "getAllParameters" and "getUnboundParameters" methods.
> Currently, each new implementation of the interface has to do it even if they
> are typically only called from the "Estimator" class (and not by the user
> code).
> That same helper class could also take care of storing the partial
> derivatives.
> A skeleton for the requested class could be as follows:
> public abstract class SimpleEstimationProblem
> implements EstimationProblem {
> // ... storage for measurements and partial derivatives ...
>
> protected void addParameter(EstimatedParameter p,
> ComputableFunction partial,
> boolean isBound) {
> // ...
> }
> protected void addParameter(EstimatedParameter p,
> ComputableFunction partial) {
> addParameter(p, partial, false);
> }
> protected double getPartial(EstimatedParameter p,
> double x) {
> // ...
> }
> protected void addMeasurement(WeightedMeasurement m) {
> _observations.add(m);
> }
> public WeightedMeasurement[] getMeasurements() {
> // ...
> }
> public EstimatedParameter[] getAllParameters() {
> // ...
> }
> public EstimatedParameter[] getUnboundParameters() {
> // ...
> }
> }
> Best,
> Gilles
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-164) Complex - Issue with non-compliance to C99!
[ https://issues.apache.org/jira/browse/MATH-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494375 ] Luc Maisonobe commented on MATH-164: I confirm the issue. Currently, the multiplication operator is implemented using a single check for NaN and using the simple rules on real and imaginary parts if the check succeeds. A quick check shows that there are several other related problems. For example, the isInfinite method checks for isNaN first and checks for infinite parts only afterwards. However, C99 explicitely states that a complex is considered to be an infinity as soon as one part is infinity, even if the other one is NaN. So it appears that the handling of special values like NaN and infinity in the Complex class is not compliant with C99 at several places. Solving this needs some forethought. Thanks for reporting it. > Complex - Issue with non-compliance to C99! > --- > > Key: MATH-164 > URL: https://issues.apache.org/jira/browse/MATH-164 > Project: Commons Math > Issue Type: Wish >Affects Versions: 1.1 >Reporter: Richard Lyon >Priority: Minor > > Complex z1, z2, z3; > > // assign values to the two complex numbers > z1 = new Complex(1.0, 0.0); > z2 = new Complex(Double.POSITIVE_INFINITY, Double.POSITIVE_INFINITY); > > // multiply the two complex numbers > z3 = z1.multiply(z2); > The result is that both the real and imaginary part of z3 are NaN. Isn't it > somewhat desirable that both parts of the complex should be Infinity? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-82) [math] FractionFormatTest doesn't compile under JDK 1.3
[ https://issues.apache.org/jira/browse/MATH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478135 ] Luc Maisonobe commented on MATH-82: --- The FractionFormatTest patch has been applied almost one year ago. The problem with ComplexUtilsTest seems OS-specific and not related to commons-math. Could we close this bug ? > [math] FractionFormatTest doesn't compile under JDK 1.3 > > > Key: MATH-82 > URL: https://issues.apache.org/jira/browse/MATH-82 > Project: Commons Math > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Operating System: All > Platform: All >Reporter: Niall Pemberton >Priority: Minor > Attachments: math_FractionFormatTest_JDK13.patch, > TEST-org.apache.commons.math.complex.ComplexUtilsTest.txt > > > FractionFormatTest uses NumberFormat.getIntegerInstance() which is a JDK 1.4 > method. Changing this to use getInstance() instead and then using > setParseIntegerOnly(true) allows it to compile under JDK 1.3 - and the test > runs and passes. > Its probably a moot point though since ComplexUtilsTest fails using JDK > 1.3.1_04 (on both W2K and Windows XP). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-162) update to mantissa 7.0
[ http://issues.apache.org/jira/browse/MATH-162?page=all ] Luc Maisonobe updated MATH-162: --- Attachment: mantissa.patch this patch updates the mantissa components that are in the commons-math source tree to version 7.0 of mantissa > update to mantissa 7.0 > -- > > Key: MATH-162 > URL: http://issues.apache.org/jira/browse/MATH-162 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: all >Reporter: Luc Maisonobe >Priority: Trivial > Attachments: mantissa.patch > > > I have released Mantissa 7.0 recently. > The mantissa version that is being integrated into commons-math is based on > version 6.4. > Version 7.0 is safer since many low level small objects are now guaranteed to > be completely immutable, so commons-maths should be updated. > I will provide a patch soon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-162) update to mantissa 7.0
update to mantissa 7.0 -- Key: MATH-162 URL: http://issues.apache.org/jira/browse/MATH-162 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: all Reporter: Luc Maisonobe Priority: Trivial I have released Mantissa 7.0 recently. The mantissa version that is being integrated into commons-math is based on version 6.4. Version 7.0 is safer since many low level small objects are now guaranteed to be completely immutable, so commons-maths should be updated. I will provide a patch soon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-161) patch for Mantissa
[ http://issues.apache.org/jira/browse/MATH-161?page=all ] Luc Maisonobe updated MATH-161: --- Attachment: mantissa.patch the patch by itself > patch for Mantissa > -- > > Key: MATH-161 > URL: http://issues.apache.org/jira/browse/MATH-161 > Project: Commons Math > Issue Type: Improvement > Environment: all >Reporter: Luc Maisonobe >Priority: Trivial > Attachments: mantissa.patch > > > Here is the patch for Mantissa, it includes the following items: > - fix a problem when switching functions triggered derivatives > discontinuities > - remove methods and classes that were deprecated in Mantissa >and do not need to be preserved in commons-math as upward compatibility >is not a problem for this newly integrated code > - changed Vector3D and Rotation to immutable classes for ease of use > - improved some javadoc in class Rotation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-60) [math] Function math.fraction.ProperFractionFormat.parse(String, ParsePosition) return illogical result
[
http://issues.apache.org/jira/browse/MATH-60?page=comments#action_12442653 ]
Luc Maisonobe commented on MATH-60:
---
doesn't the answers provided by Phil Steitz suit you ? This issue is marked as
closed, do you want to reopen it ?
> [math] Function math.fraction.ProperFractionFormat.parse(String,
> ParsePosition) return illogical result
> ---
>
> Key: MATH-60
> URL: http://issues.apache.org/jira/browse/MATH-60
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 1.1 Final
> Environment: Operating System: other
> Platform: Other
>Reporter: nhung.nnguyen
>
> Hello,
> I find illogical returned result from function "Fraction parse(String source,
> ParsePostion pos)" (in class ProperFractionFormat of the Fraction Package) of
> the Commons Math library. Please see the following code segment for more
> details:
> "
> ProperFractionFormat properFormat = new ProperFractionFormat();
> result = null;
> String source = "1 -1 / 2";
> ParsePosition pos = new ParsePosition(0);
> //Test 1 : fail
> public void testParseNegative(){
>
>String source = "-1 -2 / 3";
>ParsePosition pos = new ParsePosition(0);
>Fraction actual = properFormat.parse(source, pos);
>assertNull(actual);
> }
> // Test2: success
> public void testParseNegative(){
>
>String source = "-1 -2 / 3";
>ParsePosition pos = new ParsePosition(0);
>Fraction actual = properFormat.parse(source, pos); // return Fraction 1/3
>assertEquals(1, source.getNumerator());
>assertEquals(3, source.getDenominator());
> }
> "
> Note: Similarly, when I passed in the following inputs:
> input 2: (source = 1 2 / -3, pos = 0)
> input 3: ( source = -1 -2 / 3, pos = 0)
> Function "Fraction parse(String, ParsePosition)" returned Fraction 1/3 (means
> the result Fraction had numerator = 1 and denominator = 3)for all 3 inputs
> above.
>
> I think the function does not handle parsing the numberator/ denominator
> properly incase input string provide invalid numerator/denominator.
> Thank you!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ http://issues.apache.org/jira/browse/MATH-160?page=comments#action_12442651 ] Luc Maisonobe commented on MATH-160: I'm affraid code from any of the Numerical Recipes book cannot be included in commons-math. See the redistribution conditions in the NR site here: http://www.numerical-recipes.com/infotop.html#distinfo If the code is a well known algorithm with public references independant from NR, then it is OK. But the comments in your patch directly references the NR book in C++. Of course, this only my point of view, could anybody else give an advice on this topic ? > Chi-Square Test for Comparing two binned Data Sets > -- > > Key: MATH-160 > URL: http://issues.apache.org/jira/browse/MATH-160 > Project: Commons Math > Issue Type: New Feature >Reporter: Matthias Hummel >Priority: Minor > Attachments: commons-math.patch > > > Current Chi-Square test implementation only supports standard Chi-Square > testing with respect to known distribution. We needed testing for comparison > of two sample data sets where the distribution can be unknown. For this case > the Chi-Square test has to be computed in a different way so that both error > contributions (one for each sample data set) are taken into account. See > Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-85) [math] SimpleRegression getSumSquaredErrors
[ http://issues.apache.org/jira/browse/MATH-85?page=all ]
Luc Maisonobe updated MATH-85:
--
Attachment: math-85.patch
patch adding a test case for issue MATH-85
> [math] SimpleRegression getSumSquaredErrors
>
>
> Key: MATH-85
> URL: http://issues.apache.org/jira/browse/MATH-85
> Project: Commons Math
> Type: Bug
> Versions: 1.1.0
> Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Mark Osborn
> Attachments: math-85.patch
>
> getSumSquaredErrors returns -ve value. See test below:
> public void testSimpleRegression() {
> double[] y = { 8915.102, 8919.302, 8923.502};
> double[] x = { 1.107178495, 1.107264895, 1.107351295};
> double[] x2 = { 1.107178495E2, 1.107264895E2, 1.107351295E2};
> SimpleRegression reg = new SimpleRegression();
> for (int i = 0; i < x.length; i++) {
> reg.addData(x[i],y[i]);
> }
> assertTrue(reg.getSumSquaredErrors() >= 0.0); // OK
> reg.clear();
> for (int i = 0; i < x.length; i++) {
> reg.addData(x2[i],y[i]);
> }
> assertTrue(reg.getSumSquaredErrors() >= 0.0); // FAIL
>
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
[
http://issues.apache.org/jira/browse/MATH-85?page=comments#action_12419184 ]
Luc Maisonobe commented on MATH-85:
---
The problem is related to computation accuracy in a corner case.
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.
If instead of checking reg.getSumSquaredErrors() >= 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.
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).
I suggest to consider this is not a bug.
I will add a patch with a slightly modified test case in a few minutes.
> [math] SimpleRegression getSumSquaredErrors
>
>
> Key: MATH-85
> URL: http://issues.apache.org/jira/browse/MATH-85
> Project: Commons Math
> Type: Bug
> Versions: 1.1.0
> Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Mark Osborn
>
> getSumSquaredErrors returns -ve value. See test below:
> public void testSimpleRegression() {
> double[] y = { 8915.102, 8919.302, 8923.502};
> double[] x = { 1.107178495, 1.107264895, 1.107351295};
> double[] x2 = { 1.107178495E2, 1.107264895E2, 1.107351295E2};
> SimpleRegression reg = new SimpleRegression();
> for (int i = 0; i < x.length; i++) {
> reg.addData(x[i],y[i]);
> }
> assertTrue(reg.getSumSquaredErrors() >= 0.0); // OK
> reg.clear();
> for (int i = 0; i < x.length; i++) {
> reg.addData(x2[i],y[i]);
> }
> assertTrue(reg.getSumSquaredErrors() >= 0.0); // FAIL
>
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-151) MathUtils.round incorrect result
[ http://issues.apache.org/jira/browse/MATH-151?page=all ] Luc Maisonobe updated MATH-151: --- Attachment: math-151.patch This patch is an attempt to solve the issue. 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. Note that if someone REALLY wants to round a number like 39.24499974420461512636 and NOT 39.245, we will produce a wrong result. I didn'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. I understand the user problem but do not really like answering like that, it seems more like an ad hoc trick to me. I'm not very proud of my first patch :-( > MathUtils.round incorrect result > > > Key: MATH-151 > URL: http://issues.apache.org/jira/browse/MATH-151 > Project: Commons Math > Type: Bug > Versions: 1.1 Final > Environment: Win2K, Sun JDK1.5.0_05 b05 > Reporter: Buza Zoltán > Attachments: math-151.patch > > MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with > default rounding mode BigDecimal.ROUND_HALF_UP. > I found that internally MathUtils.round multiplies the given number by > 10^scale. > 39.245 * 100.0 results 3924.4...5 , and after this the calculation is > not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12416287 ] Luc Maisonobe commented on MATH-151: I was looking for a way to characterize those "bad" IEEE754 representations. Here is one proposal: 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: static double nextAfter(double d, double direction) 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(x) and round(nextAfter(x)) 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. 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. I have written an implementation of nextAfter. It is based on Double.doubleToLongBits, bits twiddling, and Double.longBitsToDouble. > MathUtils.round incorrect result > > > Key: MATH-151 > URL: http://issues.apache.org/jira/browse/MATH-151 > Project: Commons Math > Type: Bug > Versions: 1.1 Final > Environment: Win2K, Sun JDK1.5.0_05 b05 > Reporter: Buza Zoltán > > MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with > default rounding mode BigDecimal.ROUND_HALF_UP. > I found that internally MathUtils.round multiplies the given number by > 10^scale. > 39.245 * 100.0 results 3924.4...5 , and after this the calculation is > not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415733 ] Luc Maisonobe commented on MATH-151: The point is neither on the rounding method not on the scale factor, it is rather on the initial number itself. 39.245 has no exact representation in IEE754. it lies between two representable numbers (I forgot 4 bits in my previous post): 0x139f5c28f5c28f * 2^-47 < 39.245 < 0x139f5c28f5c290 * 2^-47 or 0x27.3eb851eb851e < 39.245 < 27.3eb851eb8520 or 39.24499974420461512636... < 39.245 < 39.24500045474735088646... 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'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. In the case discussed here, the value was the low one (i.e. 0x27.3EB851EB851E, or 39.24499974420461...). 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). Going back to the initial problem, and assuming we now start from 39.24499974420461..., we want to round this number 2 digits after the decimal point. MathUtils.round answer is 39.24 (really 39.2419895...), which is "only" 0.00499954525264... away from out number. Answering 39.25 (which CAN be represented exactly in IEEE754) would be "0.0050002557953848..." 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). > MathUtils.round incorrect result > > > Key: MATH-151 > URL: http://issues.apache.org/jira/browse/MATH-151 > Project: Commons Math > Type: Bug > Versions: 1.1 Final > Environment: Win2K, Sun JDK1.5.0_05 b05 > Reporter: Buza Zoltán > > MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with > default rounding mode BigDecimal.ROUND_HALF_UP. > I found that internally MathUtils.round multiplies the given number by > 10^scale. > 39.245 * 100.0 results 3924.4...5 , and after this the calculation is > not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415048 ] Luc Maisonobe commented on MATH-151: I think this behaviour is normal. 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) : 0x27.3EB851EB851EB851EB851... Note that the pattern EB851 repeats itself ad infinitum, in base 2 it is a 20 bits pattern. If this number could be represented in a virtual infinite register, multiplying it by 100.0 (base 10) would be multiplying it by 0x64 (base 16) and the result would be 0xF54.8 which is 3924.5 as could be rounded as expected. 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: 0x27.3EB851EB851 hence, when this number is multiplied by 100, we get the result: 0xF54.7A4 or 3924.499477040546480566263198... So the error is exactly 0x0.05C or 92/16^11 which is approximately 5.229e-12. The problem comes from the fact the original number cannot be represented exactly (it is not what is sometimes called a "floating-point number" or "normal number"), and in this case the first neglected hexadecimal digit is large (E) which explains the large error (7 wrong bits after the multiplication). I would say this is not an issue with commons-math but with IEE754, we cannot do anything about it. 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.450126700065666 and the error appoximately 4.987e-18 (92/16^16), but still lesser than 3924.5 > MathUtils.round incorrect result > > > Key: MATH-151 > URL: http://issues.apache.org/jira/browse/MATH-151 > Project: Commons Math > Type: Bug > Versions: 1.1 Final > Environment: Win2K, Sun JDK1.5.0_05 b05 > Reporter: Buza Zoltán > > MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with > default rounding mode BigDecimal.ROUND_HALF_UP. > I found that internally MathUtils.round multiplies the given number by > 10^scale. > 39.245 * 100.0 results 3924.4...5 , and after this the calculation is > not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
