date:20040524

Re: [math][proposal] Drop serialization from selected classes

2004-05-24 Thread Phil Steitz

Mark R. Diggory wrote:
These are all used either in stats or tests of stats.
AbstractDescriptiveStatistics
Should not have been on the list, not currently Serializable and as an
abstract factory, makes no sense to serialize.
DefaultTransformer
DescriptiveStatistics
Also a factory, why serialize?
DescriptiveStatisticsImpl
SummaryStatisticsImpl
TransformerMap
But, like Stephen pointed out, I'd recommend adding serialversionUID's
over removing Serialization Interfaces across the entire math package.

I've written simplified serialization/deserialization test support into
the TestUtils. As such, its very easy to write tests that simply call
this method, then test if all the values are still correct in the Object
returned.

http://jakarta.apache.org/commons/math/xref-test/org/apache/commons/math/TestUtils.html#71

The point is not so much just testing, but also the backward compatability
issues and extra burden when extending. If you feel that the classes
above must implement Serializable, then yes, please generate and add the
serialization IDs where they are missing. Can I assume that there are no
objections to removing serialization from the classes below? If so,
please provide a reason that the class should implenment Serializable.

BisectionSolver
BrentSolver
ChiSquareTestImpl
DistributionFactoryImpl
Erf
Gamma
NewtonSolver
SecantSolver
SplineInterpolator
TTestImpl
TransformerMap
UnivariateRealSolverFactoryImpl
UnivariateRealSolverImpl
ValueServer
Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java

2004-05-24 Thread ggregory

ggregory2004/05/23 21:55:33

  Modified:codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java
  Log:
  Make code less twisty.
  
  Revision  ChangesPath
  1.23  +26 -30
jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java
  
  Index: DoubleMetaphone.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- DoubleMetaphone.java  24 May 2004 00:28:10 -  1.22
  +++ DoubleMetaphone.java  24 May 2004 04:55:33 -  1.23
  @@ -869,21 +869,20 @@
* Complex condition 0 for 'M'
*/
   private boolean conditionM0(String value, int index) {
  -if (charAt(value, index + 1) == 'M') {
  -return true;
  -} else {
  -return contains(value, index - 1, 3, UMB) 
  -((index + 1) == value.length() - 1 || 
  - contains(value, index + 2, 2, ER));
  -}
  -}
  + if (charAt(value, index + 1) == 'M') {
  + return true;
  + }
  + return contains(value, index - 1, 3, UMB)
  +  ((index + 1) == value.length() - 1 || 
contains(value,
  + index + 2, 2, ER));
  + }
   
   //-- BEGIN HELPER FUNCTIONS --//
   
   /**
  - * Determines whether or not a value is of slavo-germanic orgin.  A value is
  - * of slavo-germanic origin if it contians any of 'W', 'K', 'CZ', or 'WITZ'.
  - */
  +  * Determines whether or not a value is of slavo-germanic orgin. A value is
  +  * of slavo-germanic origin if it contians any of 'W', 'K', 'CZ', or 'WITZ'.
  +  */
   private boolean isSlavoGermanic(String value) {
   return value.indexOf('W')  -1 || value.indexOf('K')  -1 || 
   value.indexOf(CZ)  -1 || value.indexOf(WITZ)  -1;
  @@ -916,29 +915,26 @@
* Cleans the input
*/
   private String cleanInput(String input) {
  -if (input == null) {
  -return null;
  -} else {
  -input = input.trim();
  -if (input.length() == 0) {
  -return null;
  -} else {
  -return input.toUpperCase();
  -}
  -}
  -}
  + if (input == null) {
  + return null;
  + }
  + input = input.trim();
  + if (input.length() == 0) {
  + return null;
  + }
  + return input.toUpperCase();
  + }
   
   /**
  - * Gets the character at index codeindex/code if available, otherwise it
  - * returns codeCharacter.MIN_VALUE/code so that there is some sort of a
  - * default
  - */
  +  * Gets the character at index codeindex/code if available, otherwise
  +  * it returns codeCharacter.MIN_VALUE/code so that there is some sort
  +  * of a default
  +  */
   protected char charAt(String value, int index) {
   if (index  0 || index = value.length()) {
   return Character.MIN_VALUE;
  -} else {
  -return value.charAt(index);
  -}
  +} 
  +return value.charAt(index);
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language Metaphone.java

2004-05-24 Thread ggregory

ggregory2004/05/23 21:56:29

  Modified:codec/src/java/org/apache/commons/codec/language
Metaphone.java
  Log:
  Make code less twisty.
  
  Revision  ChangesPath
  1.19  +2 -3  
jakarta-commons/codec/src/java/org/apache/commons/codec/language/Metaphone.java
  
  Index: Metaphone.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/language/Metaphone.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- Metaphone.java24 May 2004 00:22:45 -  1.18
  +++ Metaphone.java24 May 2004 04:56:29 -  1.19
  @@ -141,9 +141,8 @@
   if ( isPreviousChar(local, n, 'M')  
isLastChar(wdsz, n) ) { // B is silent if word ends in MB
break;
  -} else {
  -code.append(symb);
   }
  +code.append(symb);
   break;
   case 'C' : // lots of C special cases
   /* discard if SCI, SCE or SCY */
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/codec/src/java/org/apache/commons/codec/language RefinedSoundex.java

2004-05-24 Thread ggregory

ggregory2004/05/23 21:57:24

  Modified:codec/src/java/org/apache/commons/codec/language
RefinedSoundex.java
  Log:
  Make code less twisty.
  
  Revision  ChangesPath
  1.20  +2 -3  
jakarta-commons/codec/src/java/org/apache/commons/codec/language/RefinedSoundex.java
  
  Index: RefinedSoundex.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/language/RefinedSoundex.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- RefinedSoundex.java   24 May 2004 00:23:17 -  1.19
  +++ RefinedSoundex.java   24 May 2004 04:57:24 -  1.20
  @@ -139,9 +139,8 @@
   char getMappingCode(char c) {
   if (!Character.isLetter(c)) {
   return 0;
  -} else {
  -return this.soundexMapping[Character.toUpperCase(c) - 'A'];
   }
  +return this.soundexMapping[Character.toUpperCase(c) - 'A'];
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [general] improvements to the charter

2004-05-24 Thread Stephen Colebourne

I would suggest that we stick to the voted decision of this list, lazily
approved by the PMC, which includes removing sections 2 and 3.

Perhaps Jakarta as a whole doesn't have a mechanism for having a charter
different from a proposal. Whatever, that is what makes sense for commons.
And as the history shows, this file has already been changed before in
significant ways.

Thus:
- the charter is the amended document as voted on
- we should provide a link to the original proposal

Stephen

- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
 2 + 3 are both a bit pointless in a charter, they only seem to have a
 point in a proposal for a sub-project. I'll keep them in however. 4 is
 also quite pointless for a charter, so leaving them in for a later
 discussion on removing all 3.

 How would you change:

 The following charter for Jakarta Commons was initially approved by the
 Jakarta Project Management Committee on March 19, 2001. The latest
 version, 1.1, was approved by the PMC on _date_.

 to represent your second paragraph?

 We could link to the CVS history page;


http://cvs.apache.org/viewcvs.cgi/jakarta-commons/commons-build/xdocs/charte
r.xml

 Hen

 On Sun, 23 May 2004, Rodney Waldhoff wrote:

  Sections 2 and 3 are part of the form requested by the Jakarta PMC as
  part of a sub-project proposal (this info used to live at
  http://jakarta.apache.org/site/newproject.html before the incubator
  came into being.)  I'm not sure why we'd want to remove this
information,
  although it might make sense to note where reality deviated from the
plan.
 
  Also note the comment at the top the charter page.  This was the
specific
  proposal approved by the PMC.  If we want to make revisions or comments
to
  that charter, so be it, but let's not pretend that the revision is the
  history.
 
  On Fri, 14 May 2004, Henri Yandell wrote:
 
  
   [hopefully all these general emails won't mean that only one turns
into a
   living thread]
  
   I'd like to try and get us moving forward on the Commons charter a
bit.
   It's easy to turn this into a long series of misunderstood arguments,
so
   my first suggestion is hopefully something very unargumentative.
  
   [cf http://jakarta.apache.org/commons/charter.html]
  
   I'm proposing that we:
  
   **
   Remove (1.5.2) as it has never happened and is nothing our community
is
   striving to make happen. This also involves a FAQ entry on the
directory
   being removed.
  
   Remove (2) as this is not relevant to the charter nowadays, plus it's
not
   even an accurate representation of the original components. If this
   information is deemed useful, we need to ask Craig to give us another
   history lesson and make some notes, probably elsewhere.
  
   Remove (3) as it is no longer relevant and should be documented in an
   available resources section. [ie) can a new Commons component use
JIRA,
   where is our wiki etc].
   **
  
   I don't believe any of these are too big a deal and getting things
moving
   will give us a foundation for future discussions. I think that a
typical 3
   +1 and no -1 vote should be fine for such a thing [unless anyone knows
of
   obscure rules], and will plan to send out such a vote on the above if
no
   discussion occurs.
  
   Hen
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  --
  - Rod http://radio.weblogs.com/0122027/
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/stat/inference TTest.java TTestImpl.java

2004-05-24 Thread psteitz

psteitz 2004/05/23 22:29:05

  Modified:math/src/java/org/apache/commons/math/stat/inference
TTest.java TTestImpl.java
  Log:
  Added support for paired t-tests.
  PR #29049
  Reported by: Joel Freyss
  
  Revision  ChangesPath
  1.4   +245 -151  
jakarta-commons/math/src/java/org/apache/commons/math/stat/inference/TTest.java
  
  Index: TTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/stat/inference/TTest.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TTest.java23 May 2004 05:45:11 -  1.3
  +++ TTest.java24 May 2004 05:29:05 -  1.4
  @@ -24,6 +24,100 @@
* @version $Revision$ $Date$ 
*/
   public interface TTest {
  +
  +
  +/**
  + * Computes a paired, 2-sample t-statistic based on the data in the input 
  + * arrays.  The t-statistic returned is equivalent to what would be returned by
  + * computing the one-sample t-statistic [EMAIL PROTECTED] #t(double, 
double[])}, with
  + * codemu = 0/code and the sample array consisting of the (signed) 
  + * differences between corresponding entries in codesample1/code and 
  + * codesample2./code
  + * p
  + * strongPreconditions/strong: ul
  + * liThe input arrays must have the same length and their common length
  + * must be at least 2.
  + * /li/ul
  + *
  + * @param sample1 array of sample data values
  + * @param sample2 array of sample data values
  + * @return t statistic
  + * @throws IllegalArgumentException if the precondition is not met
  + * @throws MathException if the statistic can not be computed do to a
  + * convergence or other numerical error.
  + */
  +double pairedT(double[] sample1, double[] sample2) 
  +throws IllegalArgumentException, MathException;
  +
  +/**
  + * Returns the iobserved significance level/i, or 
  + * a href=http://www.cas.lancs.ac.uk/glossary_v1.1/hyptest.html#pvalue;
  + * p-value/a, associated with a paired, two-sample, two-tailed t-test 
  + * based on the data in the input arrays.
  + * p
  + * The number returned is the smallest significance level
  + * at which one can reject the null hypothesis that the mean of the paired
  + * differences is 0 in favor of the two-sided alternative that the mean paired 
  + * difference is not equal to 0. For a one-sided test, divide the returned 
  + * value by 2.
  + * p
  + * This test is equivalent to a one-sample t-test computed using
  + *  [EMAIL PROTECTED] #tTest(double, double[])} with codemu = 0/code and 
the sample array
  + *  consisting of the signed differences between corresponding elements of 
  + * codesample1/code and codesample2./code
  + * p
  + * strongUsage Note:/strongbr
  + * The validity of the p-value depends on the assumptions of the parametric
  + * t-test procedure, as discussed 
  + * a 
href=http://www.basic.nwu.edu/statguidefiles/ttest_unpaired_ass_viol.html;here/a
  + * p
  + * strongPreconditions/strong: ul
  + * liThe input array lengths must be the same and their common length must
  + * be at least 2.
  + * /li/ul
  + *
  + * @param sample1 array of sample data values
  + * @param sample2 array of sample data values
  + * @return p-value for t-test
  + * @throws IllegalArgumentException if the precondition is not met
  + * @throws MathException if an error occurs computing the p-value
  + */
  +double pairedTTest(double[] sample1, double[] sample2)
  +throws IllegalArgumentException, MathException;
  +
  +/**
  + * Performs a paired t-test/a evaluating that null hypothesis that the 
  + * mean of the paired differences between codesample1/code and
  + * codesample2/code is 0 in favor of the two-sided alternative that the 
  + * mean paired difference is not equal to 0, with significance level 
  + * codealpha/code.
  + * p
  + * Returns codetrue/code iff the null hypothesis can be rejected with 
  + * confidence code1 - alpha/code.  To perform a 1-sided test, use 
  + * codealpha / 2/code
  + * p
  + * strongUsage Note:/strongbr
  + * The validity of the test depends on the assumptions of the parametric
  + * t-test procedure, as discussed 
  + * a 
href=http://www.basic.nwu.edu/statguidefiles/ttest_unpaired_ass_viol.html;here/a
  + * p
  + * strongPreconditions/strong: ul
  + * liThe input array lengths must be the same and their common length must be 
at least 2.
  + * /li
  + * li code 0  alpha  0.5 /code
  + * /li/ul
  + *
  + * @param sample1 array of sample data values
  + * @param sample2 array of sample data values
  + * @param alpha significance level of the test

[Jakarta Commons Wiki] Updated: LocalSpellingWords

2004-05-24 Thread commons-dev

   Date: 2004-05-24T02:47:27
   Editor: DirkVerbeeck [EMAIL PROTECTED]
   Wiki: Jakarta Commons Wiki
   Page: LocalSpellingWords
   URL: http://wiki.apache.org/jakarta-commons/LocalSpellingWords

   no comment

Change Log:

--
@@ -90,3 +90,5 @@
 Sperrmechanismus
 
 apache jakarta mail2 toolkit website
+
+com datastructure dbcp Evictable evictor int javadocs junit pdf png poolable Poolable 
tomcat

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: LocalSpellingWords

2004-05-24 Thread commons-dev

   Date: 2004-05-24T02:48:49
   Editor: DirkVerbeeck [EMAIL PROTECTED]
   Wiki: Jakarta Commons Wiki
   Page: LocalSpellingWords
   URL: http://wiki.apache.org/jakarta-commons/LocalSpellingWords

   no comment

Change Log:

--
@@ -92,3 +92,5 @@
 apache jakarta mail2 toolkit website
 
 com datastructure dbcp Evictable evictor int javadocs junit pdf png poolable Poolable 
tomcat
+
+deprecated deprecation initialsize Min min refactoring transactional

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[FileUpload] Utilclass for storing files in a specified directory

2004-05-24 Thread Matthias Wessendorf

I developed a class, that contains two methods, that store files to a
specified  dir.

one methode takes only FormFile as argument, it loads that path for
storing form a properties-file.

the second takes FormFile and a String, which contains the desired path
for storing,
if not a properties-file is given ...

would it be usefull, to have such a util-class directly in
FileUpload-Project ?
(i didn't figured out a methode like this...)

snip

/**
 * 
 * Saves a Jakarta FormFile to a confiured place.
 * 
 * @param file - the FormFile to store
 * @return place of file
 */ public static String saveFile(FormFile file){
String retVal = null;

try {
//retrieve the file data
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
InputStream stream = file.getInputStream();
Properties props = new Properties();

//properties must exist

props.load(Thread.currentThread().getContextClassLoader().getResourceAsS
tream(fileupload.properties));
String place= props.getProperty(uploadPath);

if(!place.endsWith(/))
place = new
StringBuffer(place).insert(place.length(),/).toString();
retVal = place+file.getFileName();

//write the file to the file specified
OutputStream bos = new FileOutputStream(retVal);
int bytesRead = 0;
byte[] buffer = file.getFileData();
while ((bytesRead = stream.read(buffer)) != -1)
{
bos.write(buffer, 0, bytesRead);
}
bos.close();

//close the stream
stream.close();
}
catch (FileNotFoundException fnfe) {
fnfe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}



return retVal;
}

/**
 * 
 * Saves a Jakarta FormFile to a desired place.
 * 
 * @param file - the FormFile to store
 * @param place - the desired place for the file
 * @return place of file
 */
public static String saveFile(FormFile file, String place) {
String retVal = null;

try {
//retrieve the file data
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
InputStream stream = file.getInputStream();

Properties props = new Properties();

//properties must exist

props.load(Thread.currentThread().getContextClassLoader().getResourceAsS
tream(ecards.properties));
String tomcatVerzeichnis=
props.getProperty(uploadPath);



retVal = tomcatVerzeichnis+place;

System.out.println(FILE: +retVal);

//write the file to the file specified
OutputStream bos = new FileOutputStream(retVal);
int bytesRead = 0;
byte[] buffer = file.getFileData();
while ((bytesRead = stream.read(buffer)) != -1)
{
bos.write(buffer, 0, bytesRead);
}
bos.close();

//close the stream
stream.close();
}
catch (FileNotFoundException fnfe) {
fnfe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}



return retVal;
}


/snip

Cheers, Matze
--
Matthias Weßendorf
Aechterhoek 18
D-48282 Emsdetten
Germany
Email: matthias AT wessendorf DOT net
URL: http://www.wessendorf.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math][proposal] Drop serialization from selected classes

2004-05-24 Thread Mark R. Diggory

Phil Steitz wrote:
The point is not so much just testing, 
I'm just showing that effort has been put into making this a testable 
feature of our packages.

but also the backward compatability  issues and extra burden when 
extending.  
I'm not convinced there is an extra burden. If a user wants to assure 
they can serialize a class that extends something in our library, its 
actually less of a burden for them if we can show the library supports 
it. If the users don't use serialization, then they are under no burden 
to assure its applicable to their objects and there is no impact to them.

The real burden is that users who actually want to use serialization 
will not use our library because we arn't supporting it. Fewer users = 
Less feedback.

If you feel that the classes above must implement Serializable, then 
yes, please generate and add the serialization IDs where they are 
missing.  Can I assume that there are no objections to removing 
serialization from the classes below?  If so, please provide a reason 
that the class should implenment Serializable.

It behoves us to look over these classes as well and determine if there 
are any restictions to their being serializable. The restictions I would 
apply are the following

1.) If I can see is if there is a static object that is altered by any 
method.
2.) If any FileInput/OutputStream or file handle is maintained in field 
outside of a method.
3.) If any threading is used.
4.) If underlying Collections exists with questionable objects.

org.apache.commons.math.analysis - none
org.apache.commons.math.complex - none
org.apache.commons.math.distributions - none
org.apache.commons.math.linear - none
org.apache.commons.math.random  -  Yes, ValueServer maintains files and 
streams. Solution mark these as transient and use 
serialization/deserialization methods to maintain state. 
EmpiricalDistribution uses an ArrayList of generic objects
org.apache.commons.math.special - none
org.apache.commons.math.stat - Yes Frequency has an underlying 
collection of generic objects.
org.apache.commons.math.stat.inference - none
org.apache.commons.math.stat.multivariate - none
org.apache.commons.math.stat.univariate - none
org.apache.commons.math.util - TransformerMap maintains an underlying 
Map of custom or provided transformer objects

So based on this review we have one case where serialization requires 
some small customization in random and three cases where its the users 
responsibility to maintain that the objects they wish to serialize are 
infact, serializable. In all these cases serialization will throw an 
exception stating that there are objects that cannot be serialized, 
which would be the proper response alerting the user that their objects 
are not properly serializable.

I'm still convinced that Serialization can be maintained across the 
entire project with one minor customization to manage the case in 
ValueServer.

As I use this feature, have written tests for it, and understand the 
requirements for its inclusion. I would like to make an effort to 
support this further. I would like to take on the task of writing tests 
for serialization across the entire project, including serialization 
UID's and maintaining any existing serialization interfaces. Tests for 
serialization can be simply copies of existing tests with calls to the 
TestUtils serialization method in between, comparing the serialized to 
unserialized result for the objects.

-Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math][proposal] Drop serialization from selected classes

2004-05-24 Thread Mark R. Diggory

Phil Steitz wrote:
The point is not so much just testing, 
I'm just showing that effort has been put into making this a testable
feature of our packages.
but also the backward compatability  issues and extra burden when 
extending.  
I'm not convinced there is an extra burden. If a user wants to assure
they can serialize a class that extends something in our library, its
actually less of a burden for them if we can show the library supports
it. If the users don't use serialization, then they are under no burden
to assure its applicable to their objects and there is no impact to them.
The real burden is that users who actually want to use serialization
will not use our library because we arn't supporting it. Fewer users =
Less feedback.
If you feel that the classes above must implement Serializable, then 
yes, please generate and add the serialization IDs where they are 
missing.  Can I assume that there are no objections to removing 
serialization from the classes below?  If so, please provide a reason 
that the class should implenment Serializable.

It behoves us to look over these classes as well and determine if there
are any restictions to their being serializable. The restictions I would
apply are the following
1.) If I can see is if there is a static object that is altered by any
method.
2.) If any FileInput/OutputStream or file handle is maintained in field
outside of a method.
3.) If any threading is used.
4.) If underlying Collections exists with questionable objects.
org.apache.commons.math.analysis - none
org.apache.commons.math.complex - none
org.apache.commons.math.distributions - none
org.apache.commons.math.linear - none
org.apache.commons.math.random  -  Yes, ValueServer maintains files and
streams. Solution mark these as transient and use
serialization/deserialization methods to maintain state.
EmpiricalDistribution uses an ArrayList of generic objects
org.apache.commons.math.special - none
org.apache.commons.math.stat - Yes Frequency has an underlying
collection of generic objects.
org.apache.commons.math.stat.inference - none
org.apache.commons.math.stat.multivariate - none
org.apache.commons.math.stat.univariate - none
org.apache.commons.math.util - TransformerMap maintains an underlying
Map of custom or provided transformer objects
So based on this review we have one case where serialization requires
some small customization in random and three cases where its the users
responsibility to maintain that the objects they wish to serialize are
infact, serializable. In all these cases serialization will throw an
exception stating that there are objects that cannot be serialized,
which would be the proper response alerting the user that their objects
are not properly serializable.
I'm still convinced that Serialization can be maintained across the
entire project with one minor customization to manage the case in
ValueServer.
As I use this feature, have written tests for it, and understand the
requirements for its inclusion. I would like to make an effort to
support this further. I would like to take on the task of writing tests
for serialization across the entire project, including serialization
UID's and maintaining any existing serialization interfaces. Tests for
serialization can be simply copies of existing tests with calls to the
TestUtils serialization method in between, comparing the serialized to
unserialized result for the objects.
-Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] Just a test

2004-05-24 Thread Mark R. Diggory

Unsure why my email is not coming through.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [math] Just a test

2004-05-24 Thread Matthias Wessendorf

jupp,

noticed the same ... (today)


 -Original Message-
 From: Mark R. Diggory [mailto:[EMAIL PROTECTED] 
 Sent: Monday, May 24, 2004 7:25 PM
 To: Jakarta Commons Developers List
 Subject: [math] Just a test
 
 
 Unsure why my email is not coming through.
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sql] [patch] sql server improvments, fix for prior patch

2004-05-24 Thread John M

I had previously submitted a patch for the sql
project, and it was finally accepted, sort of. It
seems only part of the patch was merged. I have
included the other parts that didn't make it before,
as well as some fixes for SQL Server DDL generation
that I discovered while working on a new project with
it. Alas, some of the changes in the patch are mere
whitespace changes, but I didn't feel like trying to
undo all of those.


John Marshall
Connectria

I couldn't get this to go as an attachment.  If you
want me to send it somewhere else let me know.

=
cvs diff -u 
Index:
src/java/org/apache/commons/sql/builder/MSSqlBuilder.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/MSSqlBuilder.java,v
retrieving revision 1.7
diff -u -r1.7 MSSqlBuilder.java
---
src/java/org/apache/commons/sql/builder/MSSqlBuilder.java
28 Feb 2004 03:35:47 -  1.7
+++
src/java/org/apache/commons/sql/builder/MSSqlBuilder.java
24 May 2004 18:38:50 -
@@ -21,6 +21,7 @@
 
 import org.apache.commons.sql.model.Column;
 import org.apache.commons.sql.model.ForeignKey;
+import org.apache.commons.sql.model.Index;
 import org.apache.commons.sql.model.Table;
 
 /**
@@ -44,7 +45,7 @@
 int counter = 1;
 for (Iterator iter =
table.getForeignKeys().iterator(); iter.hasNext(); ) {
 ForeignKey key = (ForeignKey)
iter.next();
-
+
 String constraintName = tableName +
_FK_ + counter;
 println(IF EXISTS (SELECT 1 FROM
sysobjects WHERE type ='RI' AND name=' 
 + constraintName + '
@@ -53,7 +54,7 @@
 print(ALTER TABLE  + tableName +  DROP
CONSTRAINT  + constraintName );
 printEndOfStatement();
 }
-
+
 // now drop the table
 println( IF EXISTS (SELECT 1 FROM sysobjects
WHERE type = 'U' AND name = ' + tableName + ') );
 println( BEGIN );
@@ -81,13 +82,50 @@
 print( END );
 printEndOfStatement();
 }
-
-protected void printComment(String text) throws
IOException {
-print(# );
-println(text);
-}
-
+
 protected void printAutoIncrementColumn(Table
table, Column column) throws IOException {
 print( IDENTITY (1,1)  );
 }
+
+protected boolean
shouldGeneratePrimaryKeys(java.util.List
primaryKeyColumns) {
+/*
+ * requires primary key indication for
autoincrement key columns
+ * I'm not sure why the default skips the pk
statement if all are identity
+ */
+return primaryKeyColumns.size()  0;
+}
+
+protected String getSqlType(Column column) {
+//SQL Server reports datetime columns as
java.sql.Types.TIMESTAMP from DatabaseMetaData
+//Since dates are much more useful than the
actual MSSQL timestamp versioning data type
+// this uses DATETIME for all these types
+switch (column.getTypeCode()) {
+case java.sql.Types.DATE :
+case java.sql.Types.TIME :
+case java.sql.Types.TIMESTAMP :
+return DATETIME;
+default :
+return super.getSqlType(column);
+}
+}
+
+public void alterColumn( Table table, Column
column, boolean add ) throws IOException {
+
+writeAlterHeader( table );
+
+print( add ? ADD  : ALTER COLUMN  );
+createColumn( table, column );
+printEndOfStatement();
+}
+
+public void dropIndex( Table table, Index index )
throws IOException {
+
+print( DROP INDEX  );
+print( table.getName() );
+print( . );
+print( index.getName() );
+
+printEndOfStatement();
+}
+
 }
Index:
src/java/org/apache/commons/sql/builder/SqlBuilder.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/sql/src/java/org/apache/commons/sql/builder/SqlBuilder.java,v
retrieving revision 1.16
diff -u -r1.16 SqlBuilder.java
---
src/java/org/apache/commons/sql/builder/SqlBuilder.java
2 Mar 2004 13:18:31 -   1.16
+++
src/java/org/apache/commons/sql/builder/SqlBuilder.java
24 May 2004 18:38:51 -
@@ -185,7 +185,7 @@
  */
 public void createColumn(Table table, Column
column) throws IOException {
 //see comments in columnsDiffer about null/
defaults
-
+
 print(column.getName());
 print( );
 print(getSqlType(column));
@@ -493,7 +493,7 @@
 println());
 printEndOfStatement();
 }
-
+
 }
 
 /**
@@ -510,7 +510,7 @@
 
 /**
  * Writes one index for a table
- */
+ */
 protected void writeIndex( Table table, Index
index ) throws IOException {
 if (index.getName() == null) {
 log.warn( Index Name is null for index:
 + index);
@@ -526,15 +526,15 @@

1 2 >

1 - 100 of 120 matches

Mail list logo