Re: [dbutils] Java5 branch landed to trunk; release tomorrow?
Thanks for the review! 2009/11/4 Dan Fabulich : > Julien Aymé wrote: > >> I've submitted a patch for DBUTILS-54 and DBUTILS-57, which can be >> added to the release if someone (Dan? ;-) ) has the time to review >> them. >> >> I'll try to submit a patch for DBUTILS-50 later this evening, but I >> think this will require a little more time and thoughts. >> >> https://issues.apache.org/jira/browse/DBUTILS-54 >> https://issues.apache.org/jira/browse/DBUTILS-57 >> https://issues.apache.org/jira/browse/DBUTILS-50 > > I submitted your patch for DBUTILS-57, but I -1 the patch for DBUTIL-54... > it's just too much complexity for a "Minor" issue. I thought so when I wrote the patch for DBUTILS-54. I wasn't completly satisfied with it, since the patch is really long and add too many methods in QueryRunner. Maybe we should rewrite it in another specialized class? Anyway, +1 to leave it open for the moment. > > I think DBUTILS-50 will also be controversial (Liam had argued against it) > so at this point I'd like to move ahead with a release candidate for 1.3. > DBUTILS-54 and DBUTILS-50 can be handled in a later release, IMO. (I'd like > to do the release this week; I've blocked out time during ApacheCon to think > about this.) I'm totally OK with it, please do. And I also agree with Liam, DBUTILS-50 is really complicated to deal with. I tried to implement it in a simple yet usefull way and I couldn't achieve what I wanted. So +1 to leave it open and fix later. Julien > > -Dan > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD SUCCESSFUL: Commons - Commons DbUtils -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=249171&projectId=162 Build statistics: State: Ok Previous State: Failed Started at: Tue 3 Nov 2009 11:36:17 -0800 Finished at: Tue 3 Nov 2009 11:36:56 -0800 Total time: 39s Build Trigger: Schedule Build Number: 51 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.6.0_06 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: Changed: dfabulich @ Tue 3 Nov 2009 09:32:57 -0800 Comment: Updating compiler plugin separately (why did this ever work before?) Files changed: /commons/proper/dbutils/trunk/pom.xml ( 832480 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 90 Failures: 0 Errors: 0 Success Rate: 100 Total time: 1.247 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r832577 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java site/xdoc/changes.xml test/java/org/apache/commons/math/linear/EigenDe
Kudos indeed. Nice work!
Phil
l...@apache.org wrote:
> Author: luc
> Date: Tue Nov 3 22:04:08 2009
> New Revision: 832577
>
> URL: http://svn.apache.org/viewvc?rev=832577&view=rev
> Log:
> fixed an ArrayIndexOutOfBoundsException
> Kudos to Dimitri who debugged this mess of fortran/java array indices
> translation
> JIRA: MATH-308
>
> Modified:
>
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java
> commons/proper/math/trunk/src/site/xdoc/changes.xml
>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/EigenDecompositionImplTest.java
>
> Modified:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java?rev=832577&r1=832576&r2=832577&view=diff
> ==
> ---
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java
> (original)
> +++
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/EigenDecompositionImpl.java
> Tue Nov 3 22:04:08 2009
> @@ -595,8 +595,12 @@
> }
>
> final double dCurrent = main[m - 1];
> -work[lowerStart + m - 1] = dCurrent - eCurrent;
> -work[upperStart + m - 1] = dCurrent + eCurrent;
> +final double lower = dCurrent - eCurrent;
> +work[lowerStart + m - 1] = lower;
> +lowerSpectra = Math.min(lowerSpectra, lower);
> +final double upper = dCurrent + eCurrent;
> +work[upperStart + m - 1] = upper;
> +upperSpectra = Math.max(upperSpectra, upper);
> minPivot = MathUtils.SAFE_MIN * Math.max(1.0, eMax * eMax);
>
> }
> @@ -647,7 +651,7 @@
>
> tau = (range[1] - range[0]) * MathUtils.EPSILON * n + 2 *
> minPivot;
>
> -// decompose TλI as LDLT
> +// decompose T-λI as LDLT
> ldlTDecomposition(lambda, begin, n);
>
> // apply general dqd/dqds method
> @@ -899,8 +903,8 @@
> diagMax= work[4 * i0];
> offDiagMin = work[4 * i0 + 2];
> double previousEMin = work[4 * i0 + 3];
> -for (int i = 4 * i0; i < 4 * n0 - 11; i += 4) {
> -if ((work[i + 3] <= TOLERANCE_2 * work[i]) &&
> +for (int i = 4 * i0; i < 4 * n0 - 16; i += 4) {
> +if ((work[i + 3] <= TOLERANCE_2 * work[i]) ||
> (work[i + 2] <= TOLERANCE_2 * sigma)) {
> // insert a split
> work[i + 2] = -sigma;
> @@ -1537,7 +1541,7 @@
> double a2 = (work[np - 8] / b2) * (1 + work[np - 4] / b1);
>
> // approximate contribution to norm squared from i < nn-2.
> -if (end - start > 2) {
> +if (end - start > 3) {
> b2 = work[nn - 13] / work[nn - 15];
> a2 = a2 + b2;
> for (int i4 = nn - 17; i4 >= 4 * start + 2 + pingPong;
> i4 -= 4) {
>
> Modified: commons/proper/math/trunk/src/site/xdoc/changes.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/site/xdoc/changes.xml?rev=832577&r1=832576&r2=832577&view=diff
> ==
> --- commons/proper/math/trunk/src/site/xdoc/changes.xml (original)
> +++ commons/proper/math/trunk/src/site/xdoc/changes.xml Tue Nov 3 22:04:08
> 2009
> @@ -39,6 +39,10 @@
>
>
>
> +
> +Fixed an ArrayIndexOutOfBoundsException in eigen decomposition.
> Kudos to Dimitri
> +for debugging this, it was really difficult.
> +
>
> Fixed parameter test in RandomDataImpl#nextExponential. The method
> now throws
> IllegalArgumentException for mean = 0.
>
> Modified:
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/EigenDecompositionImplTest.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/EigenDecompositionImplTest.java?rev=832577&r1=832576&r2=832577&view=diff
> ==
> ---
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/EigenDecompositionImplTest.java
> (original)
> +++
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/EigenDecompositionImplTest.java
> Tue Nov 3 22:04:08 2009
> @@ -108,6 +108,40 @@
> assertEquals(0.1, ed.getRealEigenvalue(3), 1.0e-15);
> }
>
> +// the following test triggered an ArrayIndexOutOfBoundsException in
> commons-math 2.0
> +public void testMath308() {
> +
> +double[] m
Re: [dbutils] Java5 branch landed to trunk; release tomorrow?
Julien Aymé wrote: I've submitted a patch for DBUTILS-54 and DBUTILS-57, which can be added to the release if someone (Dan? ;-) ) has the time to review them. I'll try to submit a patch for DBUTILS-50 later this evening, but I think this will require a little more time and thoughts. https://issues.apache.org/jira/browse/DBUTILS-54 https://issues.apache.org/jira/browse/DBUTILS-57 https://issues.apache.org/jira/browse/DBUTILS-50 I submitted your patch for DBUTILS-57, but I -1 the patch for DBUTIL-54... it's just too much complexity for a "Minor" issue. I think DBUTILS-50 will also be controversial (Liam had argued against it) so at this point I'd like to move ahead with a release candidate for 1.3. DBUTILS-54 and DBUTILS-50 can be handled in a later release, IMO. (I'd like to do the release this week; I've blocked out time during ApacheCon to think about this.) -Dan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbutils] binary compatibility
Jörg Schaible wrote:
Is it binary backward compatible?
I think it is, but I'm not 100% certain; it's confusing.
I ran clirr on dbutils-1.2 and my locally built 1.3-SNAPSHOT; it found one
clear compatibility error which I just fixed (DBUTILS-61). This is what
it says as of r832529:
INFO: 7011: org.apache.commons.dbutils.ProxyFactory: Method 'public
java.lang.Object newProxyInstance(java.lang.Class,
java.lang.reflect.InvocationHandler)' has been added
INFO: 7011: org.apache.commons.dbutils.ResultSetIterator: Method 'public
java.lang.Iterable iterable(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.ResultSetIterator: Return type of
method 'public java.lang.Object next()' has been changed to java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.ResultSetIterator: Method 'public
java.lang.Object next()' has been added
INFO: 8000: org.apache.commons.dbutils.handlers.AbstractKeyedHandler: Class
org.apache.commons.dbutils.handlers.AbstractKeyedHandler added
ERROR: 7006: org.apache.commons.dbutils.handlers.AbstractListHandler: Return
type of method 'public java.lang.Object handle(java.sql.ResultSet)' has been
changed to java.util.List
INFO: 7011: org.apache.commons.dbutils.handlers.AbstractListHandler: Method
'public java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.ArrayHandler: Return type of
method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed to
java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.handlers.ArrayHandler: Method 'public
java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.ArrayListHandler: Return type
of method 'protected java.lang.Object handleRow(java.sql.ResultSet)' has been
changed to java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.handlers.ArrayListHandler: Method
'protected java.lang.Object handleRow(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.BeanListHandler: Return type
of method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed
to java.util.List
INFO: 7011: org.apache.commons.dbutils.handlers.BeanListHandler: Method 'public
java.lang.Object handle(java.sql.ResultSet)' has been added
INFO: 5000: org.apache.commons.dbutils.handlers.KeyedHandler: Added
org.apache.commons.dbutils.handlers.AbstractKeyedHandler to the list of
superclasses
INFO: 7000: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'protected
java.util.Map createMap()' is now implemented in superclass
org.apache.commons.dbutils.handlers.AbstractKeyedHandler
ERROR: 7006: org.apache.commons.dbutils.handlers.KeyedHandler: Return type of
method 'protected java.lang.Object createRow(java.sql.ResultSet)' has been
changed to java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'protected
java.lang.Object createRow(java.sql.ResultSet)' has been added
INFO: 7003: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'public
java.lang.Object handle(java.sql.ResultSet)' has been removed, but an inherited
definition exists.
ERROR: 7006: org.apache.commons.dbutils.handlers.MapHandler: Return type of
method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed to
java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.MapHandler: Method 'public
java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.MapListHandler: Return type of
method 'protected java.lang.Object handleRow(java.sql.ResultSet)' has been
changed to java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.MapListHandler: Method
'protected java.lang.Object handleRow(java.sql.ResultSet)' has been added
All of the errors are complaints about covariant return types. In each
case, something that used to return an Object now returns a more specific
type (e.g. List or Object[]).
But it's confusing, because Java handles covariant return types by
generating replacement methods in the bytecode. So there IS still a
method that returns Object in the bytecode.
For example, according to Jad, BeanListHandler.class decompiles like this:
public List handle(ResultSet rs) throws SQLException {
return convert.toBeanList(rs, type);
}
public volatile Object handle(ResultSet resultset) throws SQLException {
return handle(resultset);
}
Strangely, Clirr is reporting this as an ERROR that the method has
changed, followed by an INFO remark that a new method was added that just
happens to be exactly like the old method! (I guess the new signature
isn't exactly the same, since it is marked "volatile" ...?)
I believe none of these errors are really errors. I tested this by
creating a subclass of KeyedHandler like this:
public class MyKeyedHandler extends KeyedHandler {
public boolean hit = false;
@Override
protected Object createRow(ResultSet rs) th
Re: [dbutils] Java5 branch landed to trunk; release tomorrow?
Dan Fabulich wrote at Dienstag, 3. November 2009 02:57: > > In r832220 I merged the sandbox/dbutils/java5 branch to > proper/dbutils/trunk. The build works and has no compiler warnings. Is it binary backward compatible? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Generate random data using the Inverse CDF Method?
Phil Steitz wrote: > Mikkel Meyer Andersen wrote: >> 2009/11/3 Luc Maisonobe : >>> There are at least one other regular commiter and three other committers >>> that have been active on the list last year. Phil is clearly one of the >>> most involved maintainers and he has been here since the beginning. >> Okay, thanks for the info. I know how much Phil means and I haven't >> for a second doubted that. > > One important thing to understand about how things work here is that > there is no hierarchy among committers and in terms of ideas, > patches, itches-to-scratch, etc. all - including noncomitters - are > on equal footing. Just because I have been around for a while does > not mean my ideas are any better than yours or anyone else's. > >>> There are only two lists: the users list and the developers list (here). >>> Both lists are archived and searchable. >>> >>> I have no preference on this specific topic, sorry. One important thing >>> to me is also to keep backward compatibility (as strange as it might >>> seem after the bunch of changes I introduced last summer). >> I agree with this, at least to the degree where it is practically durable. >>> Would the change imply that the random package would disappear ? In this >>> case I would be against it. Would that change imply that low level "raw" >>> generators would be in random and higher level generators in >>> distribution ? In this case, I don't know what is better. >>> >>> One thing I would like to add at some time in the future would be better >>> and more modern "raw" generators in the same spirit as the Mersenne >>> Twister (typically I would like to add the WELL family of generators). >>> >>> From a user point of view, it is also important to be able to select a >>> different raw generator underlying a high level one. This is used for >>> example in Monte-Carlo analyses when one wants to reproduce a subset of >>> an already generated sequence, or according to what has higher priority, >>> generation speed or generation accuracy with respect to the desired >>> repartition. > > This is why I would like to keep the random data generation > machinery in the random package. As I stated elsewhere, I am +0/1 > on the idea of adding generic inversion-based generators that work > with any invertible distribution; but I still do not see attaching > them to the distribution implementations as a good idea. This is > for three reasons: 0) I see it as poor separation of concerns > (admittedly this is a matter of taste, but I do not see sourcing > random deviates as an essential behavior of a probability > distribution) A little more explanation of the separation of concerns issue. Inference is another thing that one frequently does *with* distributions. This was in fact the application that led to introduction of the first distributions in commons-math. But would we add hypothesis testing to the distributions themselves? Obviously no. It is interesting to ask for each distribution, how often would you have need to either generate random data from it or perform hypothesis tests using it. In addition to the obvious question of separation of concerns, the variability in the response to this is another indication that neither of these are essential behaviors of the class. Phil 1) if the implementation is *only* inversion-based, it > will be naive for some distributions and we do not want users to get > a bad impl by default 2) to fix 1) we have to essentially refactor > our package structure to place random data generation into the > distributions package, causing users to have to instantiate > distributions and also configure generators to get deviates. I see > it as simpler and more natural to use a RandomData instance. I am > -1 on dropping the random package for the reasons that Luc states. > Therefore, I am not in favor of attaching this functionality to the > distributions. > > Phil > > >>> Luc >> Cheers, Mikkel. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Generate random data using the Inverse CDF Method?
Mikkel Meyer Andersen wrote: > 2009/11/3 Luc Maisonobe : >> There are at least one other regular commiter and three other committers >> that have been active on the list last year. Phil is clearly one of the >> most involved maintainers and he has been here since the beginning. > Okay, thanks for the info. I know how much Phil means and I haven't > for a second doubted that. One important thing to understand about how things work here is that there is no hierarchy among committers and in terms of ideas, patches, itches-to-scratch, etc. all - including noncomitters - are on equal footing. Just because I have been around for a while does not mean my ideas are any better than yours or anyone else's. > >> There are only two lists: the users list and the developers list (here). >> Both lists are archived and searchable. >> >> I have no preference on this specific topic, sorry. One important thing >> to me is also to keep backward compatibility (as strange as it might >> seem after the bunch of changes I introduced last summer). > I agree with this, at least to the degree where it is practically durable. >> Would the change imply that the random package would disappear ? In this >> case I would be against it. Would that change imply that low level "raw" >> generators would be in random and higher level generators in >> distribution ? In this case, I don't know what is better. >> >> One thing I would like to add at some time in the future would be better >> and more modern "raw" generators in the same spirit as the Mersenne >> Twister (typically I would like to add the WELL family of generators). >> >> From a user point of view, it is also important to be able to select a >> different raw generator underlying a high level one. This is used for >> example in Monte-Carlo analyses when one wants to reproduce a subset of >> an already generated sequence, or according to what has higher priority, >> generation speed or generation accuracy with respect to the desired >> repartition. This is why I would like to keep the random data generation machinery in the random package. As I stated elsewhere, I am +0/1 on the idea of adding generic inversion-based generators that work with any invertible distribution; but I still do not see attaching them to the distribution implementations as a good idea. This is for three reasons: 0) I see it as poor separation of concerns (admittedly this is a matter of taste, but I do not see sourcing random deviates as an essential behavior of a probability distribution) 1) if the implementation is *only* inversion-based, it will be naive for some distributions and we do not want users to get a bad impl by default 2) to fix 1) we have to essentially refactor our package structure to place random data generation into the distributions package, causing users to have to instantiate distributions and also configure generators to get deviates. I see it as simpler and more natural to use a RandomData instance. I am -1 on dropping the random package for the reasons that Luc states. Therefore, I am not in favor of attaching this functionality to the distributions. Phil >> >> Luc > Cheers, Mikkel. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbutils] Java5 branch landed to trunk; release tomorrow?
I've submitted a patch for DBUTILS-54 and DBUTILS-57, which can be added to the release if someone (Dan? ;-) ) has the time to review them. I'll try to submit a patch for DBUTILS-50 later this evening, but I think this will require a little more time and thoughts. https://issues.apache.org/jira/browse/DBUTILS-54 https://issues.apache.org/jira/browse/DBUTILS-57 https://issues.apache.org/jira/browse/DBUTILS-50 Anyway, thanks for pushing this release. Regards, Julien 2009/11/3 Dan Fabulich : > > In r832220 I merged the sandbox/dbutils/java5 branch to > proper/dbutils/trunk. The build works and has no compiler warnings. > > I've also fixed bug DBUTILS-58, which provides a workaround for bug > DBUTILS-56. > > https://issues.apache.org/jira/browse/DBUTILS-56 > https://issues.apache.org/jira/browse/DBUTILS-58 > > At this point, I think I'd be happy to cut a release... I'll fire up an RC > at ApacheCon Hackathon tomorrow unless somebody (Julien?) identifies some > other bugs that need fixing. > > -Dan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
