Re: [math] integer factorization
> However do you have a concrete use-case for this feature? > What about an implementation with "BigInteger"? I'd guess that would make > the feature more apt to be used in "real" applications (just guessing). Well I have to admit that my current use case is fairly exotic: testing whether an irreducible polynomial in Zp(x) is primitive or not (p being a prime, I need the prime factors of (p^m)-1. In this context, the int type is enough. A less exotic use case is about arranging stuff: for example when one wants to arrange a given number N of small boxes in a bigger boxes. Given the prime factors of N, one can enumerate the possible sizes of the bigger boxes. In other applications of prime numbers, it is usually not the prime factors that are needed but a primality test. I also have this functionality for the int type (using Miller-Rabin in such a way that the result is deterministic rather than probabilistic). It is true that for random bit generation int or even long would not be enough. For hash tables, the int range seems decent (I don't really know this use case). I proposed to restrict to int type just because this is what I have now. This can be a first step and then we can consider BigInteger... > Maybe we can add it in "ArithmeticUtils". int code is less than 500 lines so it could be added to ArithmeticUtils.java on the other hand, an implementation dealing with BigInteger is bound to be much bigger. The ECC implementation of Dario Alejandro Alpern (see http://www.alpertron.com.ar/ECM.HTM) is about 7000 lines after removing the applet stuff. You probably don't want this to be added to ArithmeticUtils.java... Sebastien
Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/
Hi Thomas,
Thomas Neidhart wrote:
> On 08/06/2012 10:00 PM, Jörg Schaible wrote:
>>
>> === %< ==
>>
>> Betreff: svn commit: r1369931 - in
>>
/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
>> keyvalue/ list/
>> Absender: t...@apache.org
>> Datum: Mon, 06 Aug 2012 19:21:30 +
>> Newsgruppe: gmane.comp.jakarta.commons.scm
>>
>> Author: tn
>> Date: Mon Aug 6 19:21:29 2012
>> New Revision: 1369931
>>
>> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
>> Log:
>> Checkstyle fixes.
>>
>> [snip]
>>
>> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
>> }
>>
>>
//---
>> +
>> +/** {@inheritDoc} */
>> public K getKey() {
>> return entry.getKey();
>> }
>>
>> +/** {@inheritDoc} */
>> public V getValue() {
>> return entry.getValue();
>> }
>>
>> +/** {@inheritDoc} */
>> public V setValue(V object) {
>> return entry.setValue(object);
>> }
>> === %< ==
>>
>> Geeez, what's that for an annoying change? Since Java 5 this is already
>> the default for Javadoc when overwriting/implementing methods, so adding
>> a Javdoc comment with a single @inheritDoc is completely superfluous and
>> adds simply clutter!
>>
>> Can we stop Checkstyle complaining about it and revert these lines again?
>
> If you have a better solution, I am really willing to include it.
>
> My suggestion to go for java 6 source compatibility to be able to use
> @Override tags was so far objected.
@Override and the Javadoc inheritance is not related, automatic Javadoc
inheritance works for Java 5 independently. It seems just this bogus
Checkstyle rule, but I have nothing done with Checkstyle rules ever.
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/
On Tue, Aug 7, 2012 at 10:24 AM, Jörg Schaible
wrote:
> Hi Thomas,
>
> Thomas Neidhart wrote:
>
> > On 08/06/2012 10:00 PM, Jörg Schaible wrote:
> >>
> >> === %< ==
> >>
> >> Betreff: svn commit: r1369931 - in
> >>
>
> /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
> >> keyvalue/ list/
> >> Absender: t...@apache.org
> >> Datum: Mon, 06 Aug 2012 19:21:30 +
> >> Newsgruppe: gmane.comp.jakarta.commons.scm
> >>
> >> Author: tn
> >> Date: Mon Aug 6 19:21:29 2012
> >> New Revision: 1369931
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
> >> Log:
> >> Checkstyle fixes.
> >>
> >> [snip]
> >>
> >> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
> >> }
> >>
> >>
> //---
> >> +
> >> +/** {@inheritDoc} */
> >> public K getKey() {
> >> return entry.getKey();
> >> }
> >>
> >> +/** {@inheritDoc} */
> >> public V getValue() {
> >> return entry.getValue();
> >> }
> >>
> >> +/** {@inheritDoc} */
> >> public V setValue(V object) {
> >> return entry.setValue(object);
> >> }
> >> === %< ==
> >>
> >> Geeez, what's that for an annoying change? Since Java 5 this is already
> >> the default for Javadoc when overwriting/implementing methods, so adding
> >> a Javdoc comment with a single @inheritDoc is completely superfluous and
> >> adds simply clutter!
> >>
> >> Can we stop Checkstyle complaining about it and revert these lines
> again?
> >
> > If you have a better solution, I am really willing to include it.
> >
> > My suggestion to go for java 6 source compatibility to be able to use
> > @Override tags was so far objected.
>
> @Override and the Javadoc inheritance is not related, automatic Javadoc
> inheritance works for Java 5 independently. It seems just this bogus
> Checkstyle rule, but I have nothing done with Checkstyle rules ever.
>
Yes, I am perfectly aware of this. My goal was to bring the number of
checkstyle warnings to a manageable amount, so see the real issues more
easily (now there are still more than 800 warnings).
Afaik, there is no easy way to exclude certain methods from the check, it
only works on scope level, but as these methods all have public scope, we
are somehow stuck.
Thomas
Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/
On 7 August 2012 09:28, Thomas Neidhart wrote:
> On Tue, Aug 7, 2012 at 10:24 AM, Jörg Schaible
> wrote:
>
>> Hi Thomas,
>>
>> Thomas Neidhart wrote:
>>
>> > On 08/06/2012 10:00 PM, Jörg Schaible wrote:
>> >>
>> >> === %< ==
>> >>
>> >> Betreff: svn commit: r1369931 - in
>> >>
>>
>> /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
>> >> keyvalue/ list/
>> >> Absender: t...@apache.org
>> >> Datum: Mon, 06 Aug 2012 19:21:30 +
>> >> Newsgruppe: gmane.comp.jakarta.commons.scm
>> >>
>> >> Author: tn
>> >> Date: Mon Aug 6 19:21:29 2012
>> >> New Revision: 1369931
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
>> >> Log:
>> >> Checkstyle fixes.
>> >>
>> >> [snip]
>> >>
>> >> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
>> >> }
>> >>
>> >>
>> //---
>> >> +
>> >> +/** {@inheritDoc} */
>> >> public K getKey() {
>> >> return entry.getKey();
>> >> }
>> >>
>> >> +/** {@inheritDoc} */
>> >> public V getValue() {
>> >> return entry.getValue();
>> >> }
>> >>
>> >> +/** {@inheritDoc} */
>> >> public V setValue(V object) {
>> >> return entry.setValue(object);
>> >> }
>> >> === %< ==
>> >>
>> >> Geeez, what's that for an annoying change? Since Java 5 this is already
>> >> the default for Javadoc when overwriting/implementing methods, so adding
>> >> a Javdoc comment with a single @inheritDoc is completely superfluous and
>> >> adds simply clutter!
>> >>
>> >> Can we stop Checkstyle complaining about it and revert these lines
>> again?
>> >
>> > If you have a better solution, I am really willing to include it.
>> >
>> > My suggestion to go for java 6 source compatibility to be able to use
>> > @Override tags was so far objected.
>>
>> @Override and the Javadoc inheritance is not related, automatic Javadoc
>> inheritance works for Java 5 independently. It seems just this bogus
>> Checkstyle rule, but I have nothing done with Checkstyle rules ever.
>>
>
> Yes, I am perfectly aware of this. My goal was to bring the number of
> checkstyle warnings to a manageable amount, so see the real issues more
> easily (now there are still more than 800 warnings).
In which case, I suggest disabling all the rules that trigger warnings.
Then re-enable one by one, starting with the most important.
> Afaik, there is no easy way to exclude certain methods from the check, it
> only works on scope level, but as these methods all have public scope, we
> are somehow stuck.
>
> Thomas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] integer factorization
Hello. > > > However do you have a concrete use-case for this feature? > > > What > about an implementation with "BigInteger"? I'd guess that would make > > the feature more apt to be used in "real" applications (just > guessing). > Well I have to admit that my current use case is fairly > exotic: testing whether an irreducible polynomial in Zp(x) is primitive > or not (p being a prime, I need the prime factors of (p^m)-1. > In this > context, the int type is enough. > A less exotic use case is about > arranging stuff: for example when one wants to arrange a given number N > of small boxes in a bigger boxes. Given the prime factors of N, one can > enumerate the possible sizes of the bigger boxes. > In other applications > of prime numbers, it is usually not the prime factors that are needed > but a primality test. > I also have this functionality for the int type > (using Miller-Rabin in such a way that the result is deterministic > rather than probabilistic). > It is true that for random bit generation > int or even long would not be enough. > For hash tables, the int range > seems decent (I don't really know this use case). > > I proposed to > restrict to int type just because this is what I have now. This can be a > first step and then we can consider BigInteger... > > > Maybe we can add it > in "ArithmeticUtils". > > int code is less than 500 lines so it could be > added to ArithmeticUtils.java on the other hand, an implementation > dealing with BigInteger is bound to be much bigger. The ECC > implementation of Dario Alejandro Alpern (see > http://www.alpertron.com.ar/ECM.HTM) is about 7000 lines after removing > the applet stuff. You probably don't want this to be added to > ArithmeticUtils.java... Following this explanation, I'm inclined to agree to extend the CM feature set. Given the potential for extension, this should definitely not go in "ArithmeticUtils" but in a package of its own. Suggestions on how to lay out the structure? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] integer factorization
> Given the potential for extension, this should definitely not go in > "ArithmeticUtils" but in a package of its own. > Suggestions on how to lay out the structure? > Maybe just a class "org.apache.commons.math3.util.Prime" would do ? We can have one or more package private class beneath to do the hard work... for a start, it would contain the following methods: public static boolean isPrime(int n) public static List primeFactors(int n) and a few private ones. Later we can extend by adding overloaded versions of those methods with long and/or BigInteger types. Sebastien
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
On 7 August 2012 13:36, wrote: > Author: henrib > Date: Tue Aug 7 12:36:38 2012 > New Revision: 1370208 > > URL: http://svn.apache.org/viewvc?rev=1370208&view=rev > Log: > Reflect last changes in release notes and changes.xml; OK > Added toolchain usage to force 1.5 in pom The Commons Parent POM already provides different Java profiles for compile/test. Not sure using toolchain helps here; it may make things harder for users and developers. It must be possible to build with Java 1.6+, not just 1.5. > Modified: > commons/proper/jexl/branches/2.0/RELEASE-NOTES.txt > commons/proper/jexl/branches/2.0/pom.xml > commons/proper/jexl/branches/2.0/src/site/xdoc/changes.xml > > Modified: commons/proper/jexl/branches/2.0/RELEASE-NOTES.txt > URL: > http://svn.apache.org/viewvc/commons/proper/jexl/branches/2.0/RELEASE-NOTES.txt?rev=1370208&r1=1370207&r2=1370208&view=diff > == > --- commons/proper/jexl/branches/2.0/RELEASE-NOTES.txt (original) > +++ commons/proper/jexl/branches/2.0/RELEASE-NOTES.txt Tue Aug 7 12:36:38 > 2012 > @@ -40,8 +40,11 @@ Its goal is to expose scripting features > Release 2.1.2: > > > > -Version 2.1.2 is a micro release to fix bugs reported since 2.1.1: > +Version 2.1.2 is a micro release to fix issues reported in 2.1.1: > > +* JEXL-136: Script calls within scripts may fail with number arguments > +* JEXL-135: Using map as script parameter or local variable > +* JEXL-134: Issue with evaluation of concat of variables : \r + \n gives > 0 > * JEXL-131: UnifiedJexl parsing may fail with NPE > * JEXL-130: Ternary Conditional fails for Object values > * JEXL-126: Decimal numbers literals should be 'double' by default > (instead of 'float') > > Modified: commons/proper/jexl/branches/2.0/pom.xml > URL: > http://svn.apache.org/viewvc/commons/proper/jexl/branches/2.0/pom.xml?rev=1370208&r1=1370207&r2=1370208&view=diff > == > --- commons/proper/jexl/branches/2.0/pom.xml (original) > +++ commons/proper/jexl/branches/2.0/pom.xml Tue Aug 7 12:36:38 2012 > @@ -120,6 +120,8 @@ > > > > +1.5 > +sun > 1.5 > 1.5 > jexl > > Modified: commons/proper/jexl/branches/2.0/src/site/xdoc/changes.xml > URL: > http://svn.apache.org/viewvc/commons/proper/jexl/branches/2.0/src/site/xdoc/changes.xml?rev=1370208&r1=1370207&r2=1370208&view=diff > == > --- commons/proper/jexl/branches/2.0/src/site/xdoc/changes.xml (original) > +++ commons/proper/jexl/branches/2.0/src/site/xdoc/changes.xml Tue Aug 7 > 12:36:38 2012 > @@ -26,6 +26,12 @@ > > > > + > +Script calls within scripts may fail with number arguments > + > + > +using map as script parameter or local variable > + > > Issue with evaluation of concat of variables : \r + \n gives 0 > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] integer factorization
For hash tables, int nextPrimeAfter(int) would be useful. On Tue, Aug 7, 2012 at 8:00 AM, matic wrote: > would contain the following methods: > > public static boolean isPrime(int > n) > public static List primeFactors(int n) > > and a few private > ones. >
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
Just trying to ensure that I will not generate a public jexl2 release compiled against a jdk6. Since most (if not all) JEXL users can't even use published snapshots, the likelihood of anyone attempting to compile jexl2 and not being able to comment the toolchain plugin in the pom seems very low... Anyhow, you can revert the modification and you are more than welcome to release jexl-2.1.2 if you want to. :-) -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1370208-in-commons-proper-jexl-branches-2-0-RELEASE-NOTES-txt-pom-xml-src-site-xdoc-cl-tp4637751p4637754.html Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
On 7 August 2012 15:16, henrib wrote: > Just trying to ensure that I will not generate a public jexl2 release > compiled against a jdk6. Did not prevent me using Java 1.6 to compile. Try updating a source file to add a call to "".isEmpty() - a Java 1.6+ method - and see what happens if you compile with the default Java set to 1.6 That compiles fine for me on WinXP Compiling with 1.6 will still generate 1.5-compatible code provided that the source/target properties are set correctly. Note that the Continuum build should pick up any usage of Java 1.6+ methods which is the only other issue here. > Since most (if not all) JEXL users can't even use published snapshots, the > likelihood of anyone attempting to compile jexl2 and not being able to > comment the toolchain plugin in the pom seems very low... It's a pain having to update the pom just to check with different JVMs. That's partly why CP now includes the java-1.x profiles. Also, the way that is implemented actually works! > Anyhow, you can revert the modification and you are more than welcome to > release jexl-2.1.2 if you want to. :- I don't mind it being present if it adds utility without causing problems. > > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1370208-in-commons-proper-jexl-branches-2-0-RELEASE-NOTES-txt-pom-xml-src-site-xdoc-cl-tp4637751p4637754.html > Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1370304 - /commons/proper/jexl/branches/2.0/pom.xml
On 7 August 2012 16:08, wrote: > Author: henrib > Date: Tue Aug 7 15:08:06 2012 > New Revision: 1370304 > > URL: http://svn.apache.org/viewvc?rev=1370304&view=rev > Log: > Corrected and commented out toolchain usage Rather than comment it out, why not make it an optional profile? > Modified: > commons/proper/jexl/branches/2.0/pom.xml > > Modified: commons/proper/jexl/branches/2.0/pom.xml > URL: > http://svn.apache.org/viewvc/commons/proper/jexl/branches/2.0/pom.xml?rev=1370304&r1=1370303&r2=1370304&view=diff > == > --- commons/proper/jexl/branches/2.0/pom.xml (original) > +++ commons/proper/jexl/branches/2.0/pom.xml Tue Aug 7 15:08:06 2012 > @@ -120,12 +120,14 @@ > > > > + > 1.5 > 1.5 > jexl > -2.1.1 > +2.1.2 > > RC1 > 1.1 > @@ -136,19 +138,29 @@ > > > > + > > org.apache.maven.plugins > maven-compiler-plugin > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
I corrected the toolchain configuration (thanks for pointing it out the error) and commented out its usage from the pom. Jexl 2.1.2 is all yours now. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1370208-in-commons-proper-jexl-branches-2-0-RELEASE-NOTES-txt-pom-xml-src-site-xdoc-cl-tp4637751p4637757.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
On 8/6/12 11:16 PM, Dennis Hendriks wrote:
> See below.
>
> On 08/06/2012 05:29 PM, Phil Steitz wrote:
>>
>>
>>
>>
>> On Aug 6, 2012, at 6:06 AM, Dennis Hendriks
>> wrote:
>>
>>> See below.
>>>
>>> Dennis
>>>
>>>
>>> On 08/06/2012 02:48 PM, Phil Steitz wrote:
On Aug 5, 2012, at 11:21 PM, Dennis
Hendriks wrote:
> See below.
>
> On 08/06/2012 12:49 AM, Gilles Sadowski wrote:
>> On Sun, Aug 05, 2012 at 12:54:11PM -0700, Phil Steitz wrote:
>>> On 8/4/12 10:57 AM, Gilles Sadowski wrote:
Hello.
Referring to this failed test (cf. messages from Continuum):
---CUT---
org.apache.commons.math3.exception.NumberIsTooLargeException:
lower bound (65) must be strictly less than upper bound (65)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)
It is due to a precondition check while creating the
"UniformIntegerDistribution" instance:
---CUT---
if (lower>= upper) {
throw new NumberIsTooLargeException(
LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
lower, upper, false);
}
---CUT---
The test referred to above was using this code (before I
changed it use a
"UniformIntegerDistribution" instance):
---CUT---
final int next = (i == 4 || cur == length - 1) ? length - 1
: randomData.nextInt(cur, length - 1);
---CUT---
It is now (after the change):
---CUT---
final IntegerDistribution partitionPoint = new
UniformIntegerDistribution(cur, length - 1);
final int next = (i == 4 || cur == length - 1) ? length - 1
: partitionPoint.sample();
---CUT---
Thus, AFAIK, the failure did not appear before because
there was no
precondition enforcement in "nextInt".
The question is: Was the code in the test correct (in
allowing the same
value for both bounds?
* In the negative, how to change it?
* The affirmative would mean that the precondition check in
"UniformIntegerDistribution" should be relaxed to allow
equal bounds.
Does this make sense?
If so, can we change it now, or is it forbidden in
order to stay
backwards compatible?
>>>
>>> Your analysis above is correct. The failure after the
>>> change is due
>>> to the fact that post-change the distribution is
>>> instantiated before
>>> the bounds check. I changed the test to fix this.
>>
>> Thanks.
>>
>>> Both the
>>> randomData nextInt and the UniformIntegerDistribution
>>> constructor
>>> now forbid the degenerate case where there is only one point
>>> in the
>>> domain. In retrospect, I guess it would have probably been
>>> better
>>> to allow this degenerate case. Unfortunately, this would be an
>>> incompatible change, so will have to wait until 4.0 if we
>>> want to do it.
>>>
>>> The original code above illustrates the convenience of being
>>> able to
>>> just make direct calls to randomData.nextXxx, which is why this
>>> class exists ;)
>>
>> As I wrote in another post, I'm not against the convenience
>> methods. But
>> IMO, they should be located in a new "DistributionUtils" class.
>> And we should also find a way to remove the code duplication
>> (in the
>> distribution's "sample()" method and in the corresponding
>> "next..." method).
>>
>
> The RandomData class (or whatever it would be called) does
> indeed seem useful. If we plan to keep it, we should probably
> make sure that there is a sample/next/... method in that class
> for EVERY distribution, as some of them are missing, if I
> remember correctly. Perhaps this is a separate issue though?
>
All have the method now, but the impls delegate to
RandomDataImpl. In some cases, there is nothing better
implemented than just inversion, provided by the default
inversion sampler. That is OK. What we need to do is just
move the implementations of the default and specialized
samplers to the actual distribution classes. These can't be
static, as t
Re: [math] spinning BOBYQAOptimizerTest
Le 07/08/2012 00:21, Phil Steitz a écrit : > On 8/6/12 2:53 PM, Gilles Sadowski wrote: >> On Sun, Aug 05, 2012 at 03:13:33PM -0700, Phil Steitz wrote: >>> The site build just hung on me due to >>> BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints >>> spinning. A sample thread dump showing the spinning thread is show >>> below. Above the reference to >>> BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246), successive >>> dumps change. The code continues to run, but does not complete. >>> The hang happened during the coberta instrumented test run. >>> >>> at >>> org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqb(BOBYQAOptimizer.java:970) >>> at >>> org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqa(BOBYQAOptimizer.java:334) >>> at >>> org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) >>> at >>> org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateOptimizer.optimize(BaseAbstractMultivariateOptimizer.java:126) >>> at >>> org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateSimpleBoundsOptimizer.optimize(BaseAbstractMultivariateSimpleBoundsOptimizer.java:139) >>> at >>> org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.doTest(BOBYQAOptimizerTest.java:321) >>> at >>> org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints(BOBYQAOptimizerTest.java:249) >> Runs fine here... >> Excerpt from Cobertura report: >> BOBYQAOptimizer 87% 1022/1162 84% 525/624 23 > > Interesting. Hangs every time for me on Same here. I wanted to use cobertura for testing the studff I am working on, and could not succeed. I'm running the following versions, on a Linux box with Debian squeeze OS, a three years old AMD 64 processor and about 6 Gbytes RAM. (lehrin) luc% mvn -version Apache Maven 2.2.1 (rdebian-8) Java version: 1.6.0_24 Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: "linux" version: "3.2.0-3-amd64" arch: "amd64" Family: "unix" (lehrin) luc% java -version java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) (lehrin) luc% Luc > > BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) > > running > > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) > > Phil > >> >> >> Gilles >> >> - >> 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 > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] spinning BOBYQAOptimizerTest
On 8/7/12 11:29 AM, Luc Maisonobe wrote: > Le 07/08/2012 00:21, Phil Steitz a écrit : >> On 8/6/12 2:53 PM, Gilles Sadowski wrote: >>> On Sun, Aug 05, 2012 at 03:13:33PM -0700, Phil Steitz wrote: The site build just hung on me due to BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints spinning. A sample thread dump showing the spinning thread is show below. Above the reference to BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246), successive dumps change. The code continues to run, but does not complete. The hang happened during the coberta instrumented test run. at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqb(BOBYQAOptimizer.java:970) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqa(BOBYQAOptimizer.java:334) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) at org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateOptimizer.optimize(BaseAbstractMultivariateOptimizer.java:126) at org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateSimpleBoundsOptimizer.optimize(BaseAbstractMultivariateSimpleBoundsOptimizer.java:139) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.doTest(BOBYQAOptimizerTest.java:321) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints(BOBYQAOptimizerTest.java:249) >>> Runs fine here... >>> Excerpt from Cobertura report: >>> BOBYQAOptimizer 87% 1022/1162 84% 525/624 23 >> Interesting. Hangs every time for me on > Same here. > I wanted to use cobertura for testing the studff I am working on, and > could not succeed. What I don't get is why this happens only when running the coberta-instrumented code and why it is not actually hung, just not terminating. Successive thread dumps show that processing is continuing. Have we seen other situations where this test does not terminate? Phil > > I'm running the following versions, on a Linux box with Debian squeeze > OS, a three years old AMD 64 processor and about 6 Gbytes RAM. > > (lehrin) luc% mvn -version > Apache Maven 2.2.1 (rdebian-8) > Java version: 1.6.0_24 > Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre > Default locale: fr_FR, platform encoding: UTF-8 > OS name: "linux" version: "3.2.0-3-amd64" arch: "amd64" Family: "unix" > (lehrin) luc% java -version > java version "1.6.0_24" > OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2) > OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) > (lehrin) luc% > > Luc > >> BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) >> >> running >> >> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) >> java version "1.6.0_33" >> Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) >> Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) >> >> Phil >> >>> >>> Gilles >>> >>> - >>> 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 >> >> > > - > 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: svn commit: r1363623 - /commons/proper/logging/trunk/pom.xml
On 2012-07-24 23:06, sebb wrote:
> On 23 July 2012 17:20, Dennis Lundberg wrote:
>> On 2012-07-20 23:26, sebb wrote:
>>> On 20 July 2012 22:02, Dennis Lundberg wrote:
If this is an integration test, the proper way to exclude it is to
change its name so that it ends with "ITCase.java", see
>>>
>>> see ... what?
>>>
>>> It's not an integration test - I'm excluding WeakHashTableTestCase
>>> from the existing integration tests.
>>
>> I see, so it's the other way around.
>>
>> The integration tests should be executed by maven-failsafe-plugin, and
>> the unit tests should be executed by maven-surefire-plugin. I know that
>> commons-logging has some fairly complex integration tests. I'll try to
>> see if I can get the Maven build to follow Maven best practices.
>
> OK, thanks.
>
> There's and Ant build as well, which may help with deciding dependencies etc.
I got this sorted out. The Maven build now runs the same tests as the
Ant build.
To not upset the Ant build I've only made changes to pom.xml. Parts of
it kind of a hack, but I've documented it.
>
>>> The rest of the patch just allows the IT to work.
>>>
On 2012-07-20 04:04, s...@apache.org wrote:
> Author: sebb
> Date: Fri Jul 20 02:04:51 2012
> New Revision: 1363623
>
> URL: http://svn.apache.org/viewvc?rev=1363623&view=rev
> Log:
> Add missing property definitions for integration tests
>
> Modified:
> commons/proper/logging/trunk/pom.xml
>
> Modified: commons/proper/logging/trunk/pom.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1363623&r1=1363622&r2=1363623&view=diff
> ==
> --- commons/proper/logging/trunk/pom.xml (original)
> +++ commons/proper/logging/trunk/pom.xml Fri Jul 20 02:04:51 2012
> @@ -343,10 +343,16 @@ under the License.
>
> **/*TestCase.java
>
> +
> +**/WeakHashTableTestCase.java
> +
>
>
> + ${log4j:log4j:jar}
> + ${logkit:logkit:jar}
> +
> ${javax.servlet:servlet-api:jar}
>
> target/${project.build.finalName}.jar
>
> target/${project.artifactId}-api-${project.version}.jar
>
> target/${project.artifactId}-adapters-${project.version}.jar
> @@ -371,6 +377,19 @@ under the License.
>gnu
>
>
> +
> +
> +org.apache.maven.plugins
> +maven-dependency-plugin
> +2.4
> +
> +
> +
> + properties
> +
> +
> +
> +
>
>
>
>
>
--
Dennis Lundberg
-
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
>>>
>>
>>
>> --
>> Dennis Lundberg
>>
>>
>>
>> -
>> 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
>
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Clirr failure
On 4 August 2012 17:23, Gilles Sadowski wrote: > Hello. > > I cannot figure why "Clirr" now fails to generate its report and entails the > fail of the build on my machine: The Eclipse compiler can generate code that Clirr does not like; make sure you compile everything using the Sun compiler (and temporarily stop Eclipse rebuilding). > ---CUT--- > [INFO] Generating "Clirr" report--- clirr-maven-plugin:2.3 > [INFO] Comparing to version: 3.0 > [ERROR] Unable to find information in class > org.apache.commons.math3.analysis.FunctionUtils referring back to nested > class org.apache.commons.math3.analysis.FunctionUtils$11 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > ---CUT--- > > > Regards, > Gilles > > - > 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
Proposal Commons-JNDI
Hi, I'd like to propose a new component Commons JNDI for the sandbox. The aim would be to have a very lightweight JNDI implementation (no server, or something like that) that's not necessarily suitable for production, but ideally suited for use in test suites, and the like. For example, commons dbcp might use this to verify configuration via JNDI. The new implementation ought to be driven by property, XML, or JSON files. Possible starting points: - Import Simple JNDI, which already comes very close to the target. Henri Yandell, one of the Simple JNDI authors has given his agreement. - Import Tomcat JNDI, no contact with the Tomcat developers exists on that topic. WDYT? Jochen -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] NSWC and Apache license
Hello, I'm currently working on MATH-738, and am considering porting part of the FORTRAN "NSWC Library of Mathematics Subroutines" [1] (Naval Surface Warfare Center). The website states "This software is made available, without cost, to the general scientific community. The 1993 edition is an update of the 1990 edition." Does that mean that porting it into Commons-Math is possible (license-wise?). I would think it does... Thanks for your advice! Sébastien [1] http://www.ualberta.ca/CNS/RESEARCH/Software/NumericalNSWC/site.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal Commons-JNDI
+1 long time ago I was looking for something similar and didn't find anything useful, full support from my side! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 8, 2012 at 8:02 AM, Jochen Wiedmann wrote: > Hi, > > I'd like to propose a new component Commons JNDI for the sandbox. > > The aim would be to have a very lightweight JNDI implementation (no > server, or something like that) that's not necessarily suitable for > production, but ideally suited for use in test suites, and the like. > For example, commons dbcp might use this to verify configuration via > JNDI. The new implementation ought to be driven by property, XML, or > JSON files. > Possible starting points: > > - Import Simple JNDI, which already comes very close to the target. > Henri Yandell, one of the Simple JNDI authors has given his agreement. > - Import Tomcat JNDI, no contact with the Tomcat developers exists on > that topic. > > > WDYT? > > Jochen > > -- > In other words: what could be seen as a socially debilitating failure > of character can certainly work to your advantage too. (Linus > Torvalds, but the use in the signature tells something about me as > well.) > > - > 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
