600+ BigDecimal tests

600+ BigDecimal tests

[Anthony Green]

I've just committed the following change...

2002-12-22  Anthony Green  <green@redhat.com>

        * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file.

It's over 100k, so I'm not going to post it as a patch.

It contains a large number of BigDecimal test cases.  I generated it
by hacking on DiagBigDecimal.java from IBM's ICU project.

The ICU project uses a very liberal license (which I copied into the
test source), so it seems like fair game for Mauve.

AG

Re: 600+ BigDecimal tests

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Hi,

On Sun, 2002-12-22 at 23:59, Anthony Green wrote:
> I've just committed the following change...
> 
> 2002-12-22  Anthony Green  <green@redhat.com>
> 
>         * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file.
> 
> It's over 100k, so I'm not going to post it as a patch.
> 
> It contains a large number of BigDecimal test cases.  I generated it
> by hacking on DiagBigDecimal.java from IBM's ICU project.

I have been removing inner classes from the test cases since libgcj uses
Mauve in a way that cannot handle those. Normally that is easy (just use
the test class itself instead of creating a new inner class). But in the
case of DiagBigDecimal I had to make a bit more changes. The changes
mostly just remove the old test framework that IBM was using.

        * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java (diagrun): 
        Return void.
        (DiagException): Remove and use RuntimeException if necessary.
        (summary): Removed.
        (Test): Removed.

Would it be OK to commit this?

If you have a way to track changes from the original test could you send
me the script you are using then I can hack that.

Cheers,

Mark

[-- Attachment #2: DiagBigDecimal.diff --]
[-- Type: text/x-patch, Size: 13298 bytes --]

Index: gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java
===================================================================
RCS file: /cvs/mauve/mauve/gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java,v
retrieving revision 1.1
diff -u -r1.1 DiagBigDecimal.java
--- gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java	22 Dec 2002 22:56:32 -0000	1.1
+++ gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java	3 Jan 2003 01:34:04 -0000
@@ -200,23 +200,20 @@
   * detected, or <0 if an unexpected Exception was signalled.
   */
  
- public int diagrun(TestHarness harness){
-  int fails;
+ public void diagrun(TestHarness harness){
   int num=0;
-  DiagException de=null;
+  RuntimeException de=null;
   java.lang.RuntimeException e=null;
   java.lang.String rest=null;
   
-  fails=0; // count of failures
   try{num=1;num:for(;num<=testcount;num++){ // [testcount is constant set above]
    try{
     dotest(harness, num);
    }
-   catch (DiagException $1){de=$1;
+   catch (RuntimeException $1){de=$1;
     say(harness);
     harness.verbose("**** Failed:"+" "+de.getMessage()+" "+"****");
     say(harness);
-    fails=fails+de.failcount;
    }
   }
   }
@@ -224,10 +221,10 @@
    say(harness);
    harness.verbose("**** Failed: unexpected exception ****");
    e.printStackTrace();
-   return -1;
+   return;
   }/*num*/
   
-  return fails;
+  return;
  }
 
  /* Run test by number -- method for development/private switching */
@@ -1193,7 +1190,6 @@
   }/*checknull*/
   harness.check (flag, "cst301");
   
-  summary("Constructors", harness);
   return;
   }
 
@@ -1208,7 +1204,6 @@
    harness.check ((one.toString()).equals("1"), "cuc002");
    harness.check ((ten.toString()).equals("10"), "cuc003");
   
-  summary("No mutation", harness);
   return;}
 
  
@@ -1237,7 +1232,6 @@
   harness.check (((new BigDecimal("0.01")).abs().toString()).equals("0.01"), "abs015");
   harness.check (((new BigDecimal("-0.01")).abs().toString()).equals("0.01"), "abs016");
 
-  summary("abs", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1367,7 +1361,6 @@
   }/*checknull*/
   harness.check (flag, "add200");
   
-  summary("add", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -1393,7 +1386,6 @@
   }/*checknull*/
   harness.check (flag, "cpt100");
   
-  summary("compareTo", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -1462,7 +1454,6 @@
   }/*div0*/
   harness.check (flag, "div204");
 
-  summary("divide", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1488,7 +1479,6 @@
    flag=true;
   }/*checknull*/
   harness.check (flag, "max010");
-  summary("max", harness);
   return;}
 
  /** Test the {@link BigDecimal#min} method. */
@@ -1515,7 +1505,6 @@
   }/*checknull*/
   harness.check (flag, "min010");
   
-  summary("min", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1624,7 +1613,6 @@
   }/*checknull*/
   harness.check (flag, "mul200");
   
-  summary("multiply", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -1790,7 +1778,6 @@
   }/*checknull*/
   harness.check (flag, "sub200");
   
-  summary("subtract", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1853,7 +1840,6 @@
   // 244
   // 245
   
-  summary("byteValue+", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1891,7 +1877,6 @@
   }
   harness.check (flag, "cto102");
 
-  summary("compareTo(Obj)", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1914,7 +1899,6 @@
   harness.check (((new BigDecimal(val)).doubleValue())==java.lang.Double.POSITIVE_INFINITY, "dov006");
   val="-1e1000";
   harness.check (((new BigDecimal(val)).doubleValue())==java.lang.Double.NEGATIVE_INFINITY, "dov007");
-  summary("doubleValue", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -1928,7 +1912,6 @@
   harness.check ((!(d.equals((java.lang.Object)(new BigDecimal(66))))), "equ003");
   harness.check (d.equals((java.lang.Object)d), "equ004");
   harness.check (d.equals((java.lang.Object)((new BigDecimal(10)).add(new BigDecimal(7)))), "equ005");
-  summary("equals", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -1956,7 +1939,6 @@
   harness.check (((new BigDecimal(val)).floatValue())==java.lang.Float.POSITIVE_INFINITY, "flv008");
   val="-1e1000";
   harness.check (((new BigDecimal(val)).floatValue())==java.lang.Float.NEGATIVE_INFINITY, "flv009");
-  summary("floatValue", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -1975,7 +1957,6 @@
   hs="126.5E+200";
   d=new BigDecimal(hs);
   harness.check ((d.hashCode())!=(hs.hashCode()), "has003");
-  summary("hashCode", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -2026,7 +2007,6 @@
   harness.check (((5))==((new BigDecimal("5.0")).intValue()), "inv108");
   harness.check (((-5))==((new BigDecimal("-5.0")).intValue()), "inv109");
   
-  summary("intValue+", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2078,7 +2058,6 @@
   harness.check ((((long)5))==((new BigDecimal("5.0")).longValue()), "lov108");
   harness.check ((((long)-5))==((new BigDecimal("-5.0")).longValue()), "lov109");
   
-  summary("longValue+", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2118,7 +2097,6 @@
   harness.check (((new BigDecimal("0.5E+1")).movePointLeft(+5).toString()).equals("0.00005"), "mpl035");
   harness.check (((new BigDecimal("0.5E+1")).movePointLeft(+10).toString()).equals("0.0000000005"), "mpl036");
   
-  summary("movePointLeft", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -2157,7 +2135,6 @@
   harness.check (((new BigDecimal("0.5E+1")).movePointRight(-5).toString()).equals("0.00005"), "mpr035");
   harness.check (((new BigDecimal("0.5E+1")).movePointRight(-10).toString()).equals("0.0000000005"), "mpr036");
   
-  summary("movePointRight", harness);
   return;}
 /* ----------------------------------------------------------------- */
  
@@ -2181,7 +2158,6 @@
   harness.check (((new BigDecimal("-0.1")).scale())==1, "sca015");
   harness.check (((new BigDecimal("-0.12")).scale())==2, "sca016");
   harness.check (((new BigDecimal("-0.123")).scale())==3, "sca017");
-  summary("scale", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2226,7 +2202,6 @@
    flag=(e.getMessage()).equals("Rounding necessary");
   }/*checkrunn*/
   harness.check (flag, "ssc102");
-  summary("setScale", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2252,7 +2227,6 @@
   harness.check (((smin))==((new BigDecimal(smax+1)).shortValue()), "shv011");
   harness.check (((smax))==((new BigDecimal(smin-1)).shortValue()), "shv012");
   
-  summary("shortValue+", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2278,7 +2252,6 @@
   harness.check (1==((new BigDecimal("1")).signum()), "sig015");
   harness.check (1==((new BigDecimal("1e+12")).signum()), "sig016");
   harness.check (0==((new BigDecimal("00e+12")).signum()), "sig017");
-  summary("signum", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2336,7 +2309,6 @@
   harness.check (((new BigDecimal("1E-1000")).toBigInteger().toString()).equals("0"), "tbi044");
   harness.check (((new BigDecimal("-1E-1000")).toBigInteger().toString()).equals("0"), "tbi045");
   
-  summary("toBigInteger+", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2358,7 +2330,6 @@
   harness.check (str.equals((java.lang.Object)cs), "tos004");
   harness.check ((cs instanceof java.lang.String), "tos005");
   harness.check ((d.toString() instanceof java.lang.String), "tos006");
-  summary("toString", harness);
   return;}
 
  /* ----------------------------------------------------------------- */
@@ -2414,40 +2385,6 @@
   }/*checkscale*/
   harness.check (flag, "val100");
   
-  summary("valueOf", harness);
-  return;}
-
- /* ------------------------------------------------------------------ */
- /* Support routines and minor classes follow                          */
- /* ------------------------------------------------------------------ */
- 
- /* ----------------------------------------------------------------- */
- /* Method called to summarise pending tests                          */
- /* ----------------------------------------------------------------- */
- /* Arg1 is section name */
- 
- private void summary(java.lang.String section, TestHarness harness){
-  int bad;
-  int count;
-  int i=0;
-  Test item=null;
-  bad=0;
-  count=Tests.size();
-  {int $144=count;i=0;i:for(;$144>0;$144--,i++){
-   item=(Test)(Tests.elementAt(i));
-   if ((!item.ok)) 
-    {
-     bad++;
-     harness.verbose("Failed:"+" "+item.name);
-    }
-   }
-  }/*i*/
-  totalcount=totalcount+count;
-  Tests=new java.util.Vector(100); // reinitialize
-  if (bad==0) 
-   say("OK"+" "+left(section,14)+" "+right("["+count+" "+"tests]",12), harness);
-  else 
-   throw new DiagException(section+" "+"[failed"+" "+bad+" "+"of"+" "+count+" "+"tests]",bad);
   return;}
 
  
@@ -2505,91 +2442,4 @@
     diagrun (harness);
   }
 
-/* ------------------------------------------------------------------ */
-/* Test -- represents a test and its status                           */
-/* ------------------------------------------------------------------ */
-/* Copyright IBM Corporation 1998, 2000.  All rights reserved.        */
-/* Author: Mike Cowlishaw                                             */
-/* ------------------------------------------------------------------ */
-/* 1998.07.15 Initial version                                         */
-/* 2000.03.27 Change to javadoc comments                              */
-
-/**
- * The <code>Test</code> class is used to record a specific test.
- * When constructed, it notes the name of the test and adds the test
- * to the list of tests held by the parent.
- *
- * Its <code>ok</flag> is assigned directly to record whether the
- * test succeeded (1) or failed (0).
- *
- * @see     com.ibm.icu.math.DiagBigDecimal
- * @version 1.00 2000.03.27
- * @author  Mike Cowlishaw
- */
- 
- public class Test{
-  private final transient java.lang.String $0="DiagBigDecimal.nrx";
-  /* properties shared transient */
- /** The name of the test. */
-  transient java.lang.String name;
- /** Success flag; will be set to 1 (true) if the test succeeded, or 0
-  * (false) if the test failed.
-  */
-  transient boolean ok;
-
- 
- /**
-  * Constructs a new <code>Test</code> with a specified name.
-  *
-  * @param testname The <code>String</code> naming the test.
-  */
-  
-  public Test(java.lang.String testname){super();
-   name=testname; // save the name
-   DiagBigDecimal.this.Tests.addElement((java.lang.Object)this); // and add to parent's list
-   return;}
-  }
-
- /* ------------------------------------------------------------------ */
- /* DiagException                                                      */
- /* ------------------------------------------------------------------ */
- /* Copyright IBM Corporation 1996, 2000.  All rights reserved.        */
- /* Author: Mike Cowlishaw                                             */
- /* ------------------------------------------------------------------ */
- /* 1996.05.27 Initial version in NetRexx (as DiagX)                   */
- /* 1998.06.25 Copied from NetRexx test suite                          */
- /* 1999.07.03 Add fail count                                          */
- /* 2000.03.27 Change to javadoc comments                              */
- 
- /**
-  * The <code>DiagException</code> class is used to signal the failure
-  * of a test group.  It records the number of failures in the group.
-  *
-v  * @see     com.ibm.icu.math.DiagBigDecimal
-  * @version 1.00 2000.03.27
-  * @author  Mike Cowlishaw
-  */
- 
- public static class DiagException extends java.lang.RuntimeException{
-  private final transient java.lang.String $0="DiagBigDecimal.nrx";
- 
-  /* properties shared transient */
- /** the count of failed tests in the group which signalled this
-   * exception.
-   */
-  transient int failcount=0;
- // number of tests which failed
- 
- /**
-  * Constructs a new <code>DiagException</code> with a message and
-  * failure count.  This is thrown when a group of tests fails.
-  *
-  * @param message The <code>String</code> message describing the group.
-  * @param fails   The <code>int</code> number of failed tests in the  group.
-  */
-  
-  public DiagException(java.lang.String message,int fails){
-   super(message);
-   failcount=fails;
-   return;}
- }}
+ }

Re: 600+ BigDecimal tests

[Mark Wielaard]

Hi Anthony,

On Fri, 2003-01-03 at 02:35, Mark Wielaard wrote:
> On Sun, 2002-12-22 at 23:59, Anthony Green wrote:
> > I've just committed the following change...
> > 
> > 2002-12-22  Anthony Green  <green@redhat.com>
> > 
> >         * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file.
> > 
> > It's over 100k, so I'm not going to post it as a patch.
> > 
> > It contains a large number of BigDecimal test cases.  I generated it
> > by hacking on DiagBigDecimal.java from IBM's ICU project.
> 
> I have been removing inner classes from the test cases since libgcj uses
> Mauve in a way that cannot handle those. Normally that is easy (just use
> the test class itself instead of creating a new inner class). But in the
> case of DiagBigDecimal I had to make a bit more changes. The changes
> mostly just remove the old test framework that IBM was using.
> 
>         * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java (diagrun): 
>         Return void.
>         (DiagException): Remove and use RuntimeException if necessary.
>         (summary): Removed.
>         (Test): Removed.
> 
> Would it be OK to commit this?
> 
> If you have a way to track changes from the original test could you send
> me the script you are using then I can hack that.

Could you take a look at the above and tell me if it would be OK to
checkin this change?

BTW. I currently get the following failures with gcj. Are those expected
(bugs in Classpath/gcj?). I get the same failures with Kissme. :

FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div377 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc101 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc102 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val008 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val013 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1)

Couldn't cross check against kaffe since that gives:
FAIL: uncaught exception loading
gnu.testlet.java.math.BigDecimal.DiagBigDecimaljava.lang.ExceptionInInitializerError: [exception was kaffe.util.NotImplemented]

Thanks,

Mark

Re: 600+ BigDecimal tests

[Dalibor Topic]

Hi Mark,

--- Mark Wielaard <mark@klomp.org> wrote:

> Couldn't cross check against kaffe since that gives:
> FAIL: uncaught exception loading
>
gnu.testlet.java.math.BigDecimal.DiagBigDecimaljava.lang.ExceptionInInitializerError:
> [exception was kaffe.util.NotImplemented]

Aah, that's a "known defect" ;) You need to install
the gnu mp libs for arbitrary precision mathematics
first ( http://www.swox.com/gmp/ ), and then recompile
kaffe to pick it up. I've posted a patch on the kaffe
mailing list last week that would allow to fall back
on classpath's pure java implementation if gnu mp can
not be found. It should enter the kaffe CVS next week.

cheers,
dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: 600+ BigDecimal tests

[Mark Wielaard]

Hi,

On Sat, 2003-01-18 at 16:27, Dalibor Topic wrote:
> Aah, that's a "known defect" ;) You need to install
> the gnu mp libs for arbitrary precision mathematics
> first ( http://www.swox.com/gmp/ ), and then recompile
> kaffe to pick it up.

Thanks. I just used the kaffe 1.0.7 Debian package which has the correct
dependencies. Results:

FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov013 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov014 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov015 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov016 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov017 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov019 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov105 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov106 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov109 (number 1)
14 of 285 tests failed

I have now also tried the Blackdown-1.4.1-beta which gives:

FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div376 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has002 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: sca007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1)
11 of 600 tests failed

And here are the Classpath ones again just for comparison:

FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div377 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr007 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc005 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc006 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc101 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc102 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val008 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val013 (number 1)
FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1)
21 of 338 tests failed

Hmmm. This will be fun figuring out what goes wrong where and wether it
is the testcase or the implementation that is incorrect (has001, lov007
and lov107 at least look suspicious since all three implementations get
those wrong).

Note that you will need my patch to get these results, without it both
the gcj and kaffe version give up almost immediatly with a
NumberFormatException that is never caught.

Cheers,

Mark

Re: 600+ BigDecimal tests

[Stephen Crawley]

Folks,

I've been looking at DiagBigDecimal and the "bugs" that it shows up.

Some are genuine, but some are questionable.  (The following is from memory
... YMMV)

  * There is a bug with the parse methods barffing with a "+" in the 
    exponent in strings like "123.4E+5".

I think this is the bug that Mark has patched.

  * There is a bug in the toString() method that doesn't add a leading
    zero in some cases; e.g. it produces ".1234" instead of "0.1234".

I have a fix for this.  [I'll submit it tonight.]

  * Some of the other tests check exception message strings, and are
    failing because the messages are different. 

I don't know whether this is a bug or not.  Is Classpath aiming to
give the same exception messages as the Sun JDK implementation ???

  * The 'has001' failure is due to differences in the way that 
    Classpath and the SUN JDK are calculating hashcodes.

I don't know whether this is a bug or not.  Is Classpath aiming to
give the same hash code values as the Sun JDK implementation ???

-- Steve

Re: 600+ BigDecimal tests

[Anthony Green]

On Thu, 2003-01-02 at 17:35, Mark Wielaard wrote:
> Would it be OK to commit this?

Yes, of course.  Thanks, and sorry for the delay.

> If you have a way to track changes from the original test could you send
> me the script you are using then I can hack that.

I don't have anything like that.

Thanks again.

AG

Re: 600+ BigDecimal tests

[Anthony Green]

On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote:
>   * Some of the other tests check exception message strings, and are
>     failing because the messages are different. 
> 
> I don't know whether this is a bug or not.  Is Classpath aiming to
> give the same exception messages as the Sun JDK implementation ???

I don't think so (could be wrong).  I suppose we should remove these
tests.

> 
>   * The 'has001' failure is due to differences in the way that 
>     Classpath and the SUN JDK are calculating hashcodes.
> 
> I don't know whether this is a bug or not.  Is Classpath aiming to
> give the same hash code values as the Sun JDK implementation ???

I know that some people have spent time figuring out how Sun hashes
various objects, although I don't know if this is a policy. 

AG

Re: 600+ BigDecimal tests

[Stephen Crawley]

> On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote:
> >   * Some of the other tests check exception message strings, and are
> >     failing because the messages are different. 
> > 
> > I don't know whether this is a bug or not.  Is Classpath aiming to
> > give the same exception messages as the Sun JDK implementation ???
> 
> I don't think so (could be wrong).  I suppose we should remove these
> tests.

Assuming that we are not aiming for identical exception messages, the
correct approach is to change the tests to just check that the
correct exceptions are raised.  (Currently, at least some of them
don't check this!)

BTW.  Has this question been debated / decided in the past?  The reason
I ask is that application code may rely on exception message strings to 
discriminate exception cases.  IMO, this is a BAD THING (tm), but in some
cases, the application programmer may have little choice.

-- Steve

Re: 600+ BigDecimal tests

[Artur Biesiadowski]

Stephen Crawley wrote:

> BTW.  Has this question been debated / decided in the past?  The reason
> I ask is that application code may rely on exception message strings to 
> discriminate exception cases.  IMO, this is a BAD THING (tm), but in some
> cases, the application programmer may have little choice.

This is doomed to failure from very start. Exception strings generated 
by system should be localized (so they can be shown to user in worst 
case). So there is no way to write language-portable program which looks 
at details of exception messages.


Artur

Re: 600+ BigDecimal tests

[Stephen Crawley]

> Stephen Crawley wrote:
> 
> > BTW.  Has this question been debated / decided in the past?  The reason
> > I ask is that application code may rely on exception message strings to 
> > discriminate exception cases.  IMO, this is a BAD THING (tm), but in some
> > cases, the application programmer may have little choice.
> 
> This is doomed to failure from very start. Exception strings generated 
> by system should be localized (so they can be shown to user in worst 
> case). So there is no way to write language-portable program which looks 
> at details of exception messages.

True ... but this doesn't stop programmers doing this kind of thing out of
ignorance or desperation.  Still, I'm convinced that there is little value
in busting a gut to get identical exception messages.

-- Steve

Re: 600+ BigDecimal tests

[Dalibor Topic]

--- Anthony Green <green@redhat.com> wrote:
> On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote:
> >   * Some of the other tests check exception
> message strings, and are
> >     failing because the messages are different. 
> > 
> > I don't know whether this is a bug or not.  Is
> Classpath aiming to
> > give the same exception messages as the Sun JDK
> implementation ???
> 
> I don't think so (could be wrong).  I suppose we
> should remove these
> tests.

I'd vote for a change to catch the exception and
ignore the message. After all, free implementations
may (have) come up with more understandable,
localized, superior messages to those provided by
Sun's implementation. It would be counterproductive to
force them to change them  to Sun's version.

> > 
> >   * The 'has001' failure is due to differences in
> the way that 
> >     Classpath and the SUN JDK are calculating
> hashcodes.
> > 
> > I don't know whether this is a bug or not.  Is
> Classpath aiming to
> > give the same hash code values as the Sun JDK
> implementation ???
> 
> I know that some people have spent time figuring out
> how Sun hashes
> various objects, although I don't know if this is a
> policy. 

I think the essential question here is: can having
different hash methods bite you in some way? Beside
obvious hashing performance considerations, I doubt
it.

best regards,
dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com