You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/01/25 13:13:36 UTC
[Math] Toward releasing 3.0 ?
Hello.
Among the good resolutions for this new year 2012, there had been rumours
about releasing Commons Math 3.0 around mid-January.
I've been reviewing the list of open issues and postponed several issues to
3.1 (mostly because there were no patch).
Pending design issues (matrix interface, etc.) are too fuzzy; thus unlikely
to be correctly implemented in a short timespan.
As far as I'm concerned, in order to meet a deadline that was mentioned
some time ago (in November last year, IIRC), there must be a feature freeze
as soon as possible, and an official release before March.
It thus becomes urgent to tackle the remaining blocking issues.
Can we please make a list of those, and of all practical matters that
prevent the preparation of the release?
Thanks and best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> just some status/feedback on some still open issues:
>
> - MATH-449: I have implemented (almost) all suggestions from
> Phil, and the code is documented and tested, so imho the issue
> can be resolved unless somebody has still reservations
You probably know best.
> - MATH-431: the two tests were contributed by Mikkel Meyer Andersen
> (is he still active?) and I have cleaned up the exceptions while
> working on another issue. There are still things to do, as can be
> seen in the comments to the issue (mainly the results are not 100%
> equivalent to R due to some specific corrections). I do not have
> the expertise to work on them myself straight away. How do we proceed
> in such a case? Keep them as they are and note the differences
> in the javadoc, or remove them unless the issues are completely
> resolved?
It's categorized as "New feature", so resolution can be postponed to 3.1.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > do we need to clear all Findbugs/PMD warning prior to releasing?
>
> Yes, and checkstyle too.
We'll have to make an exception for "BOBYQAOptimizer": I don't want to
eliminate all those potential clues pointing at the needed improvements
towards a clean Java implementation.
If the CheckStyle report must be empty for the released source code, I
propose to first create the release branch[1], and there, disable the
scanning of the entire class.
The same might be going for "PivotingQRDecomposition", although my preferred
solution would, again, be to not include it in the release, given that it
seems unsupported.
> [...]
Is it useful to create a JIRA ticket to list all the tasks needed to be
completed for the release?
Best,
Gilles
[1] When can we do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 29 February 2012 18:35, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> > [...]
>> >
>> > With
>> > <gpg.passphrase>Pass phrase in clear text</gpg.passphrase>
>> > it works; whereas with
>> > <gpg.passphrase>{dwQBDCzUlr8Hb4JOieNAAhzWzTT0Gnmy5yOayp6W4CpbnGsVQrii/bcwDRjwYx9U}</gpg.passphrase>
>> > it doesn't.
>> >
>>
>> Just re-checked, and it seems that Maven only supports password
>> encryption for *server* passwords.
>>
>> Sorry, thought Maven supported encryption elsewhere in settings.xml too.
>
> Hence, it would be clearer to remove the line
> <gpg.passphrase></gpg.passphrase>
> in the example snippet of "settings.xml" (in the "UsingNexus" page) and
> explicitly say that the signing must preferrably be done in interactive mode
> (where one will type the passphrase when maven prompts for it).
>
> There is another confusion that arises when that same snippet refers to
> <id>apache-release</id>
> whereas the commands refer to "-Prelease".
>
DOne
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > [...]
> >
> > With
> > <gpg.passphrase>Pass phrase in clear text</gpg.passphrase>
> > it works; whereas with
> > <gpg.passphrase>{dwQBDCzUlr8Hb4JOieNAAhzWzTT0Gnmy5yOayp6W4CpbnGsVQrii/bcwDRjwYx9U}</gpg.passphrase>
> > it doesn't.
> >
>
> Just re-checked, and it seems that Maven only supports password
> encryption for *server* passwords.
>
> Sorry, thought Maven supported encryption elsewhere in settings.xml too.
Hence, it would be clearer to remove the line
<gpg.passphrase></gpg.passphrase>
in the example snippet of "settings.xml" (in the "UsingNexus" page) and
explicitly say that the signing must preferrably be done in interactive mode
(where one will type the passphrase when maven prompts for it).
There is another confusion that arises when that same snippet refers to
<id>apache-release</id>
whereas the commands refer to "-Prelease".
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 29 February 2012 00:09, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> >> [...]
>> >>
>> >> > I think that this, indeed, did not test the use of the encrypted password
>> >> > for login.
>> >>
>> >> To test the login encryption, I suggest you try deploying a snapshot
>> >> release instead (e.g. install from trunk, which should remain a
>> >> snapshot).
>> >
>> > This command
>> >
>> > $ mvn clean deploy -Prelease -Dgpg.skip
>> >
>> > worked. A.o. it uploaded this file:
>> > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math3/3.0-SNAPSHOT/commons-math3-3.0-20120228.1019
>>
>> OK, so the login password encryption is working.
>>
>> AIUI one should not use -Prelease with snapshots as they are not releases.
>> The release profile is intended for staging of release artifacts, and
>> as such includes signing.
>
> I took the command from this document:
> http://wiki.apache.org/commons/UsingNexus
>
>>
>> The next stage is to get the signing key working.
>>
>> I suggest you revert temporarily to a plain text password, and check
>> you can sign locally, e.g.
>>
>> mvn package gpg:sign -DskipTests
>>
>> Then try encrypting the password again.
>
> With
> <gpg.passphrase>Pass phrase in clear text</gpg.passphrase>
> it works; whereas with
> <gpg.passphrase>{dwQBDCzUlr8Hb4JOieNAAhzWzTT0Gnmy5yOayp6W4CpbnGsVQrii/bcwDRjwYx9U}</gpg.passphrase>
> it doesn't.
>
Just re-checked, and it seems that Maven only supports password
encryption for *server* passwords.
Sorry, thought Maven supported encryption elsewhere in settings.xml too.
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >> [...]
> >>
> >> > I think that this, indeed, did not test the use of the encrypted password
> >> > for login.
> >>
> >> To test the login encryption, I suggest you try deploying a snapshot
> >> release instead (e.g. install from trunk, which should remain a
> >> snapshot).
> >
> > This command
> >
> > $ mvn clean deploy -Prelease -Dgpg.skip
> >
> > worked. A.o. it uploaded this file:
> > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math3/3.0-SNAPSHOT/commons-math3-3.0-20120228.1019
>
> OK, so the login password encryption is working.
>
> AIUI one should not use -Prelease with snapshots as they are not releases.
> The release profile is intended for staging of release artifacts, and
> as such includes signing.
I took the command from this document:
http://wiki.apache.org/commons/UsingNexus
>
> The next stage is to get the signing key working.
>
> I suggest you revert temporarily to a plain text password, and check
> you can sign locally, e.g.
>
> mvn package gpg:sign -DskipTests
>
> Then try encrypting the password again.
With
<gpg.passphrase>Pass phrase in clear text</gpg.passphrase>
it works; whereas with
<gpg.passphrase>{dwQBDCzUlr8Hb4JOieNAAhzWzTT0Gnmy5yOayp6W4CpbnGsVQrii/bcwDRjwYx9U}</gpg.passphrase>
it doesn't.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 28 February 2012 10:36, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> [...]
>>
>> > I think that this, indeed, did not test the use of the encrypted password
>> > for login.
>>
>> To test the login encryption, I suggest you try deploying a snapshot
>> release instead (e.g. install from trunk, which should remain a
>> snapshot).
>
> This command
>
> $ mvn clean deploy -Prelease -Dgpg.skip
>
> worked. A.o. it uploaded this file:
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math3/3.0-SNAPSHOT/commons-math3-3.0-20120228.1019
OK, so the login password encryption is working.
AIUI one should not use -Prelease with snapshots as they are not releases.
The release profile is intended for staging of release artifacts, and
as such includes signing.
The next stage is to get the signing key working.
I suggest you revert temporarily to a plain text password, and check
you can sign locally, e.g.
mvn package gpg:sign -DskipTests
Then try encrypting the password again.
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
>
> > I think that this, indeed, did not test the use of the encrypted password
> > for login.
>
> To test the login encryption, I suggest you try deploying a snapshot
> release instead (e.g. install from trunk, which should remain a
> snapshot).
This command
$ mvn clean deploy -Prelease -Dgpg.skip
worked. A.o. it uploaded this file:
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math3/3.0-SNAPSHOT/commons-math3-3.0-20120228.1019
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 27 February 2012 21:22, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> > I couldn't tell you now because installing maven3 implied desinstalling
>> > maven2.
>>
>> I've got both installed (Win XP) with no issues; I just change the
>> PATH as needed to switch between them.
>
> It's Debian GNU/Linux here.
>
>> > [...]
>
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO] Building Commons Math 3.0-SNAPSHOT
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO]
>> > [INFO] --- maven-gpg-plugin:1.1:sign (default-cli) @ commons-math3 ---
>> > GPG Passphrase: *******************************
>>
>> Good, so it does prompt.
>>
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO] BUILD FAILURE
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO] Total time: 11.345s
>> > [INFO] Finished at: Mon Feb 27 13:05:15 CET 2012
>> > [INFO] Final Memory: 9M/105M
>> > [INFO] ------------------------------------------------------------------------
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default-cli) on project
>> > commons-math3: The project artifact has not been assembled yet. Please do
>> > not invoke this goal before the lifecycle phase "package". -> [Help 1]
>> > [ERROR]
>> > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
>> > switch.
>> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> > [ERROR]
>> > [ERROR] For more information about the errors and possible solutions, please read the following articles:
>> > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>> > ---CUT---
>> >
>> > However, when I run
>> >
>> > $ mvn clean deploy -Papache-release -Ptest-deploy
>>
>> Try using
>>
>> mvn clean package deploy -Prelease -Ptest-deploy
>>
>> instead.
>
> Same error (bad passphrase).
>
>> [...]
>> Some encrypted passphrases can contain invalid characters; check that
>> {} only appear at the ends.
>
> There are no "{" or "}" inside the encrypted passphrase.
>
>> [Very poor design of the Maven decrypt routine - it should only check
>> for {} at the ends of the value and so avoid the hassle of escaping
>> chars]
>>
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO] BUILD FAILURE
>> > [INFO] ------------------------------------------------------------------------
>> > [INFO] Total time: 2:20.088s
>> > [INFO] Finished at: Mon Feb 27 13:15:10 CET 2012
>> > [INFO] Final Memory: 36M/370M
>> > [INFO] ------------------------------------------------------------------------
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default) on project commons-math3: Exit code: 2 -> [Help 1]
>> > ---CUT---
>> >
>> >>
>> >> Better than plain text, but still not ideal if your host is not
>> >> physically secure.
>> >
>> > It would have been good enough if it worked.
>> > I must be missing some additional configuration...
>>
>> Does the encryption setup work for logins, e.g. can you deploy snapshots?
>
> When there is no GPG step, it seems to work; here is a listing of the
> created files:
>
> $ ls -1 target/deploy/org/apache/commons/commons-math3/3.0-SNAPSHOT/
> commons-math3-3.0-20120227.204940-1.jar
> commons-math3-3.0-20120227.204940-1.jar.md5
> commons-math3-3.0-20120227.204940-1.jar.sha1
> commons-math3-3.0-20120227.204940-1.pom
> commons-math3-3.0-20120227.204940-1.pom.md5
> commons-math3-3.0-20120227.204940-1.pom.sha1
> commons-math3-3.0-20120227.204940-1-site.xml
> commons-math3-3.0-20120227.204940-1-site.xml.md5
> commons-math3-3.0-20120227.204940-1-site.xml.sha1
> maven-metadata.xml
> maven-metadata.xml.md5
> maven-metadata.xml.sha1
>
>
> I only tried "test-deploy"; can I just try "deploy" as is, and see what is
> going to happen?
AFAIK, there is no point - the gpg stage happens before deploy;
changing the deploy target won't change anything to do with gpg.
> I was wary of messing with Nexus until it could at least
> work flawlessly with "test-deploy"...
Nexus is the safety net; it's not possible to accidentally deploy when
using Nexus, as the release upload has to be closed and then released
before it gets sent further.
> I think that this, indeed, did not test the use of the encrypted password
> for login.
To test the login encryption, I suggest you try deploying a snapshot
release instead (e.g. install from trunk, which should remain a
snapshot).
>> > [...]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > I couldn't tell you now because installing maven3 implied desinstalling
> > maven2.
>
> I've got both installed (Win XP) with no issues; I just change the
> PATH as needed to switch between them.
It's Debian GNU/Linux here.
> > [...]
> > [INFO] ------------------------------------------------------------------------
> > [INFO] Building Commons Math 3.0-SNAPSHOT
> > [INFO] ------------------------------------------------------------------------
> > [INFO]
> > [INFO] --- maven-gpg-plugin:1.1:sign (default-cli) @ commons-math3 ---
> > GPG Passphrase: *******************************
>
> Good, so it does prompt.
>
> > [INFO] ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO] ------------------------------------------------------------------------
> > [INFO] Total time: 11.345s
> > [INFO] Finished at: Mon Feb 27 13:05:15 CET 2012
> > [INFO] Final Memory: 9M/105M
> > [INFO] ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default-cli) on project
> > commons-math3: The project artifact has not been assembled yet. Please do
> > not invoke this goal before the lifecycle phase "package". -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> > switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions, please read the following articles:
> > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> > ---CUT---
> >
> > However, when I run
> >
> > $ mvn clean deploy -Papache-release -Ptest-deploy
>
> Try using
>
> mvn clean package deploy -Prelease -Ptest-deploy
>
> instead.
Same error (bad passphrase).
> [...]
> Some encrypted passphrases can contain invalid characters; check that
> {} only appear at the ends.
There are no "{" or "}" inside the encrypted passphrase.
> [Very poor design of the Maven decrypt routine - it should only check
> for {} at the ends of the value and so avoid the hassle of escaping
> chars]
>
> > [INFO] ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO] ------------------------------------------------------------------------
> > [INFO] Total time: 2:20.088s
> > [INFO] Finished at: Mon Feb 27 13:15:10 CET 2012
> > [INFO] Final Memory: 36M/370M
> > [INFO] ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default) on project commons-math3: Exit code: 2 -> [Help 1]
> > ---CUT---
> >
> >>
> >> Better than plain text, but still not ideal if your host is not
> >> physically secure.
> >
> > It would have been good enough if it worked.
> > I must be missing some additional configuration...
>
> Does the encryption setup work for logins, e.g. can you deploy snapshots?
When there is no GPG step, it seems to work; here is a listing of the
created files:
$ ls -1 target/deploy/org/apache/commons/commons-math3/3.0-SNAPSHOT/
commons-math3-3.0-20120227.204940-1.jar
commons-math3-3.0-20120227.204940-1.jar.md5
commons-math3-3.0-20120227.204940-1.jar.sha1
commons-math3-3.0-20120227.204940-1.pom
commons-math3-3.0-20120227.204940-1.pom.md5
commons-math3-3.0-20120227.204940-1.pom.sha1
commons-math3-3.0-20120227.204940-1-site.xml
commons-math3-3.0-20120227.204940-1-site.xml.md5
commons-math3-3.0-20120227.204940-1-site.xml.sha1
maven-metadata.xml
maven-metadata.xml.md5
maven-metadata.xml.sha1
I only tried "test-deploy"; can I just try "deploy" as is, and see what is
going to happen? I was wary of messing with Nexus until it could at least
work flawlessly with "test-deploy"...
I think that this, indeed, did not test the use of the encrypted password
for login.
> > [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 27 February 2012 12:27, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> On Sat, Feb 25, 2012 at 12:25:49PM +0000, sebb wrote:
>> On 25 February 2012 09:59, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
>> > Hello.
>> >
>> >> >
>> >> > How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
>> >> > "Things to do before releasing 3.0".
>> >>
>> >> Sorry for being late on this.
>> >>
>> >> >
>> >> > Can we start to talk about an expected release date?
>> >>
>> >> I guess you did a wonderful job for closing everything. As it is clean
>> >> enough, I think we could even skip the step of using a release branch
>> >> and we could simply tag the release candidates from the trunk. This
>> >> would simply imply refraining from any change which is not related to
>> >> the release for a few days.
>> >>
>> >> Someone has to volunteer to act as the release manager. The task is
>> >> simply to perform the few commands described for example here:
>> >> <http://wiki.apache.org/commons/UsingNexus>. The release manager also
>> >> signs the packages using a gpg key, which should be put in the global
>> >> KEYS file. This file can be retrieved using the following svn command:
>> >>
>> >> svn checkout --depth=immediates \
>> >> https://[your-commiter-id]@svn.apache.org/repos/asf/commons/trunks-proper
>> >>
>> >> The artifacts for the release candidate must be made available and a
>> >> VOTE thread must be started on the dev list for at least 72 hours (see
>> >> <http://www.apache.org/foundation/voting.html>). There can be several
>> >> release candidate before a version finally goes out (when I release
>> >> version 2.0 I think, we needed 6 candidates ...). When the vote passes,
>> >> the exact artifacts which were used for voting will be published by
>> >> uploading the source and binary zip and tar files and by promoting the
>> >> maven artifacts with Nexus. Not a single bit is changed (this would
>> >> change the gpg signatures). This means that for example the release date
>> >> which appears in the release notes must be estimated before the vote
>> >> taking the voting delay into account (plus one or two days as a safety
>> >> margin) and it must be updated as each release candidate is cut.
>> >>
>> >> So there is no predefined release date until the vote finally passes.
>> >>
>> >> At the pace at which you go now, I would say we could target a first
>> >> release candidate early next week.
>> >>
>> >> Any volunteer as release manager ?
>> >
>> > OK, I started to try the commands listed in the "UsingNexus" file. Not
>> > everything works directly... [maven2 could not find a plugin, which led me
>>
>> Which plugin?
>
> I couldn't tell you now because installing maven3 implied desinstalling
> maven2.
I've got both installed (Win XP) with no issues; I just change the
PATH as needed to switch between them.
>>
>> > to upgrade to maven3, which printed a warning about "parent" being a broken
>> > project, etc.]
>
> This is the warning from maven3:
> ---CUT---
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model for org.apache.commons:commons-math3:jar:3.0-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-idea-plugin is missing. @org.apache.commons:commons-parent:20, /home/eran/.m2/repository/org/apache/commons/commons-parent/20/commons-parent-20.pom, line 316, column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
> [WARNING]
> ---CUT---
Can ignore that - IDEA is used for reports only (if then).
>> >
>> > I don't know maven (apart from the basics to build CM) so, it is not always
>> > obvious which are the mandatory steps and what result must be observed in
>> > order to check that everything went fine...
>> >
>> > For the encryption key: I was always advised against writing a passphrase in
>> > clear in a file; maven seems to support asking for the passphrase but when
>> > it prints:
>> > ---CUT---
>> > Enter passphrase: gpg: gpg-agent is not available in this session
>> > ---CUT---
>> > When I enter the passphrase, it just prints that same message again...
>>
>> Works for me using Maven 2.2.1 and 3.0.4
>
> Maven version is also 3.0.4 here.
>
>>
>> Which version of gpg have you installed locally?
>
> ---CUT---
> $ gpg --version
> gpg (GnuPG) 1.4.11
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Home: ~/.gnupg
> Supported algorithms:
> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
> Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
> CAMELLIA192, CAMELLIA256
> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2
> ---CUT---
>
>>
>> To test it out, just use
>>
>> mvn gpg:sign
>>
>> It will fail later as it needs package first.
>
> This seems to work (if this is where you expected it to fail); it produces:
> ---CUT---
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model for org.apache.commons:commons-math3:jar:3.0-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-idea-plugin is missing. @org.apache.commons:commons-parent:20, /home/eran/.m2/repository/org/apache/commons/commons-parent/20/commons-parent-20.pom, line 316, column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
> [WARNING]
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Commons Math 3.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-gpg-plugin:1.1:sign (default-cli) @ commons-math3 ---
> GPG Passphrase: *******************************
Good, so it does prompt.
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 11.345s
> [INFO] Finished at: Mon Feb 27 13:05:15 CET 2012
> [INFO] Final Memory: 9M/105M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default-cli) on project
> commons-math3: The project artifact has not been assembled yet. Please do
> not invoke this goal before the lifecycle phase "package". -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> ---CUT---
>
> However, when I run
>
> $ mvn clean deploy -Papache-release -Ptest-deploy
Try using
mvn clean package deploy -Prelease -Ptest-deploy
instead.
> I get:
>
> ---CUT---
> [INFO] Parent project loaded from repository.
> [INFO]
> [INFO] --- maven-gpg-plugin:1.1:sign (default) @ commons-math3 ---
>
> You need a passphrase to unlock the secret key for
> user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
> 1024-bit DSA key, ID 51D05641, created 2003-09-28
>
> Enter passphrase: gpg: gpg-agent is not available in this session
>
> You need a passphrase to unlock the secret key for
> user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
> 1024-bit DSA key, ID 51D05641, created 2003-09-28
>
> Enter passphrase: gpg: Invalid passphrase; please try again ...
>
> You need a passphrase to unlock the secret key for
> user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
> 1024-bit DSA key, ID 51D05641, created 2003-09-28
>
> Enter passphrase: gpg: gpg-agent is not available in this session
> [... and so on ...]
> ---CUT---
>
>
>> > [I guess I'll create a dummy key and store the passphrase in "settings.xml"
>> > just for this to work...]
>>
>> You can use encrypted passwords:
>>
>> http://maven.apache.org/guides/mini/guide-encryption.html
>
> I had read it, but didn't think it would work for the
> <gpg.passphrase></gpg.passphrase>
> tag.
>
> Anyway, I encrypted the pass phrase using
>
> $ mvn --encrypt-password "my pass phrase"
>
> put the result in the above tag, and got:
> ---CUT---
> INFO] --- maven-gpg-plugin:1.1:sign (default) @ commons-math3 ---
> gpg: skipped "Gilles Sadowski (ASF code signing) <er...@apache.org>": bad passphrase
> gpg: signing failed: bad passphrase
Some encrypted passphrases can contain invalid characters; check that
{} only appear at the ends.
[Very poor design of the Maven decrypt routine - it should only check
for {} at the ends of the value and so avoid the hassle of escaping
chars]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2:20.088s
> [INFO] Finished at: Mon Feb 27 13:15:10 CET 2012
> [INFO] Final Memory: 36M/370M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default) on project commons-math3: Exit code: 2 -> [Help 1]
> ---CUT---
>
>>
>> Better than plain text, but still not ideal if your host is not
>> physically secure.
>
> It would have been good enough if it worked.
> I must be missing some additional configuration...
Does the encryption setup work for logins, e.g. can you deploy snapshots?
>>
>> Can also store the master key on a removable USB stick.
>
> I'm not that paranoid ;-). It is encrypted, and stored in
> "settings-security.xml", only readable by me. And it serves only to run
> maven.
> It's just that storing the pass phrase of a general-purpose encrypting key,
> in clear text does not seem right.
Agree.
>
> Thanks for any enlightenment as to what could cause this problem,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sat, Feb 25, 2012 at 12:25:49PM +0000, sebb wrote:
> On 25 February 2012 09:59, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> > Hello.
> >
> >> >
> >> > How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
> >> > "Things to do before releasing 3.0".
> >>
> >> Sorry for being late on this.
> >>
> >> >
> >> > Can we start to talk about an expected release date?
> >>
> >> I guess you did a wonderful job for closing everything. As it is clean
> >> enough, I think we could even skip the step of using a release branch
> >> and we could simply tag the release candidates from the trunk. This
> >> would simply imply refraining from any change which is not related to
> >> the release for a few days.
> >>
> >> Someone has to volunteer to act as the release manager. The task is
> >> simply to perform the few commands described for example here:
> >> <http://wiki.apache.org/commons/UsingNexus>. The release manager also
> >> signs the packages using a gpg key, which should be put in the global
> >> KEYS file. This file can be retrieved using the following svn command:
> >>
> >> svn checkout --depth=immediates \
> >> https://[your-commiter-id]@svn.apache.org/repos/asf/commons/trunks-proper
> >>
> >> The artifacts for the release candidate must be made available and a
> >> VOTE thread must be started on the dev list for at least 72 hours (see
> >> <http://www.apache.org/foundation/voting.html>). There can be several
> >> release candidate before a version finally goes out (when I release
> >> version 2.0 I think, we needed 6 candidates ...). When the vote passes,
> >> the exact artifacts which were used for voting will be published by
> >> uploading the source and binary zip and tar files and by promoting the
> >> maven artifacts with Nexus. Not a single bit is changed (this would
> >> change the gpg signatures). This means that for example the release date
> >> which appears in the release notes must be estimated before the vote
> >> taking the voting delay into account (plus one or two days as a safety
> >> margin) and it must be updated as each release candidate is cut.
> >>
> >> So there is no predefined release date until the vote finally passes.
> >>
> >> At the pace at which you go now, I would say we could target a first
> >> release candidate early next week.
> >>
> >> Any volunteer as release manager ?
> >
> > OK, I started to try the commands listed in the "UsingNexus" file. Not
> > everything works directly... [maven2 could not find a plugin, which led me
>
> Which plugin?
I couldn't tell you now because installing maven3 implied desinstalling
maven2.
>
> > to upgrade to maven3, which printed a warning about "parent" being a broken
> > project, etc.]
This is the warning from maven3:
---CUT---
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.commons:commons-math3:jar:3.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-idea-plugin is missing. @org.apache.commons:commons-parent:20, /home/eran/.m2/repository/org/apache/commons/commons-parent/20/commons-parent-20.pom, line 316, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
---CUT---
> >
> > I don't know maven (apart from the basics to build CM) so, it is not always
> > obvious which are the mandatory steps and what result must be observed in
> > order to check that everything went fine...
> >
> > For the encryption key: I was always advised against writing a passphrase in
> > clear in a file; maven seems to support asking for the passphrase but when
> > it prints:
> > ---CUT---
> > Enter passphrase: gpg: gpg-agent is not available in this session
> > ---CUT---
> > When I enter the passphrase, it just prints that same message again...
>
> Works for me using Maven 2.2.1 and 3.0.4
Maven version is also 3.0.4 here.
>
> Which version of gpg have you installed locally?
---CUT---
$ gpg --version
gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
---CUT---
>
> To test it out, just use
>
> mvn gpg:sign
>
> It will fail later as it needs package first.
This seems to work (if this is where you expected it to fail); it produces:
---CUT---
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.commons:commons-math3:jar:3.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-idea-plugin is missing. @org.apache.commons:commons-parent:20, /home/eran/.m2/repository/org/apache/commons/commons-parent/20/commons-parent-20.pom, line 316, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Commons Math 3.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-gpg-plugin:1.1:sign (default-cli) @ commons-math3 ---
GPG Passphrase: *******************************
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.345s
[INFO] Finished at: Mon Feb 27 13:05:15 CET 2012
[INFO] Final Memory: 9M/105M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default-cli) on project
commons-math3: The project artifact has not been assembled yet. Please do
not invoke this goal before the lifecycle phase "package". -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
---CUT---
However, when I run
$ mvn clean deploy -Papache-release -Ptest-deploy
I get:
---CUT---
[INFO] Parent project loaded from repository.
[INFO]
[INFO] --- maven-gpg-plugin:1.1:sign (default) @ commons-math3 ---
You need a passphrase to unlock the secret key for
user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
1024-bit DSA key, ID 51D05641, created 2003-09-28
Enter passphrase: gpg: gpg-agent is not available in this session
You need a passphrase to unlock the secret key for
user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
1024-bit DSA key, ID 51D05641, created 2003-09-28
Enter passphrase: gpg: Invalid passphrase; please try again ...
You need a passphrase to unlock the secret key for
user: "Gilles Sadowski (ASF code signing) <er...@apache.org>"
1024-bit DSA key, ID 51D05641, created 2003-09-28
Enter passphrase: gpg: gpg-agent is not available in this session
[... and so on ...]
---CUT---
> > [I guess I'll create a dummy key and store the passphrase in "settings.xml"
> > just for this to work...]
>
> You can use encrypted passwords:
>
> http://maven.apache.org/guides/mini/guide-encryption.html
I had read it, but didn't think it would work for the
<gpg.passphrase></gpg.passphrase>
tag.
Anyway, I encrypted the pass phrase using
$ mvn --encrypt-password "my pass phrase"
put the result in the above tag, and got:
---CUT---
INFO] --- maven-gpg-plugin:1.1:sign (default) @ commons-math3 ---
gpg: skipped "Gilles Sadowski (ASF code signing) <er...@apache.org>": bad passphrase
gpg: signing failed: bad passphrase
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:20.088s
[INFO] Finished at: Mon Feb 27 13:15:10 CET 2012
[INFO] Final Memory: 36M/370M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-gpg-plugin:1.1:sign (default) on project commons-math3: Exit code: 2 -> [Help 1]
---CUT---
>
> Better than plain text, but still not ideal if your host is not
> physically secure.
It would have been good enough if it worked.
I must be missing some additional configuration...
>
> Can also store the master key on a removable USB stick.
I'm not that paranoid ;-). It is encrypted, and stored in
"settings-security.xml", only readable by me. And it serves only to run
maven.
It's just that storing the pass phrase of a general-purpose encrypting key,
in clear text does not seem right.
Thanks for any enlightenment as to what could cause this problem,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 25 February 2012 09:59, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> >
>> > How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
>> > "Things to do before releasing 3.0".
>>
>> Sorry for being late on this.
>>
>> >
>> > Can we start to talk about an expected release date?
>>
>> I guess you did a wonderful job for closing everything. As it is clean
>> enough, I think we could even skip the step of using a release branch
>> and we could simply tag the release candidates from the trunk. This
>> would simply imply refraining from any change which is not related to
>> the release for a few days.
>>
>> Someone has to volunteer to act as the release manager. The task is
>> simply to perform the few commands described for example here:
>> <http://wiki.apache.org/commons/UsingNexus>. The release manager also
>> signs the packages using a gpg key, which should be put in the global
>> KEYS file. This file can be retrieved using the following svn command:
>>
>> svn checkout --depth=immediates \
>> https://[your-commiter-id]@svn.apache.org/repos/asf/commons/trunks-proper
>>
>> The artifacts for the release candidate must be made available and a
>> VOTE thread must be started on the dev list for at least 72 hours (see
>> <http://www.apache.org/foundation/voting.html>). There can be several
>> release candidate before a version finally goes out (when I release
>> version 2.0 I think, we needed 6 candidates ...). When the vote passes,
>> the exact artifacts which were used for voting will be published by
>> uploading the source and binary zip and tar files and by promoting the
>> maven artifacts with Nexus. Not a single bit is changed (this would
>> change the gpg signatures). This means that for example the release date
>> which appears in the release notes must be estimated before the vote
>> taking the voting delay into account (plus one or two days as a safety
>> margin) and it must be updated as each release candidate is cut.
>>
>> So there is no predefined release date until the vote finally passes.
>>
>> At the pace at which you go now, I would say we could target a first
>> release candidate early next week.
>>
>> Any volunteer as release manager ?
>
> OK, I started to try the commands listed in the "UsingNexus" file. Not
> everything works directly... [maven2 could not find a plugin, which led me
Which plugin?
> to upgrade to maven3, which printed a warning about "parent" being a broken
> project, etc.]
>
> I don't know maven (apart from the basics to build CM) so, it is not always
> obvious which are the mandatory steps and what result must be observed in
> order to check that everything went fine...
>
> For the encryption key: I was always advised against writing a passphrase in
> clear in a file; maven seems to support asking for the passphrase but when
> it prints:
> ---CUT---
> Enter passphrase: gpg: gpg-agent is not available in this session
> ---CUT---
> When I enter the passphrase, it just prints that same message again...
Works for me using Maven 2.2.1 and 3.0.4
Which version of gpg have you installed locally?
To test it out, just use
mvn gpg:sign
It will fail later as it needs package first.
> [I guess I'll create a dummy key and store the passphrase in "settings.xml"
> just for this to work...]
You can use encrypted passwords:
http://maven.apache.org/guides/mini/guide-encryption.html
Better than plain text, but still not ideal if your host is not
physically secure.
Can also store the master key on a removable USB stick.
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >
> > How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
> > "Things to do before releasing 3.0".
>
> Sorry for being late on this.
>
> >
> > Can we start to talk about an expected release date?
>
> I guess you did a wonderful job for closing everything. As it is clean
> enough, I think we could even skip the step of using a release branch
> and we could simply tag the release candidates from the trunk. This
> would simply imply refraining from any change which is not related to
> the release for a few days.
>
> Someone has to volunteer to act as the release manager. The task is
> simply to perform the few commands described for example here:
> <http://wiki.apache.org/commons/UsingNexus>. The release manager also
> signs the packages using a gpg key, which should be put in the global
> KEYS file. This file can be retrieved using the following svn command:
>
> svn checkout --depth=immediates \
> https://[your-commiter-id]@svn.apache.org/repos/asf/commons/trunks-proper
>
> The artifacts for the release candidate must be made available and a
> VOTE thread must be started on the dev list for at least 72 hours (see
> <http://www.apache.org/foundation/voting.html>). There can be several
> release candidate before a version finally goes out (when I release
> version 2.0 I think, we needed 6 candidates ...). When the vote passes,
> the exact artifacts which were used for voting will be published by
> uploading the source and binary zip and tar files and by promoting the
> maven artifacts with Nexus. Not a single bit is changed (this would
> change the gpg signatures). This means that for example the release date
> which appears in the release notes must be estimated before the vote
> taking the voting delay into account (plus one or two days as a safety
> margin) and it must be updated as each release candidate is cut.
>
> So there is no predefined release date until the vote finally passes.
>
> At the pace at which you go now, I would say we could target a first
> release candidate early next week.
>
> Any volunteer as release manager ?
OK, I started to try the commands listed in the "UsingNexus" file. Not
everything works directly... [maven2 could not find a plugin, which led me
to upgrade to maven3, which printed a warning about "parent" being a broken
project, etc.]
I don't know maven (apart from the basics to build CM) so, it is not always
obvious which are the mandatory steps and what result must be observed in
order to check that everything went fine...
For the encryption key: I was always advised against writing a passphrase in
clear in a file; maven seems to support asking for the passphrase but when
it prints:
---CUT---
Enter passphrase: gpg: gpg-agent is not available in this session
---CUT---
When I enter the passphrase, it just prints that same message again...
[I guess I'll create a dummy key and store the passphrase in "settings.xml"
just for this to work...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 20/02/2012 23:26, Gilles Sadowski a écrit :
> Hi.
Hi Gilles,
>
> How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
> "Things to do before releasing 3.0".
Sorry for being late on this.
>
> Can we start to talk about an expected release date?
I guess you did a wonderful job for closing everything. As it is clean
enough, I think we could even skip the step of using a release branch
and we could simply tag the release candidates from the trunk. This
would simply imply refraining from any change which is not related to
the release for a few days.
Someone has to volunteer to act as the release manager. The task is
simply to perform the few commands described for example here:
<http://wiki.apache.org/commons/UsingNexus>. The release manager also
signs the packages using a gpg key, which should be put in the global
KEYS file. This file can be retrieved using the following svn command:
svn checkout --depth=immediates \
https://[your-commiter-id]@svn.apache.org/repos/asf/commons/trunks-proper
The artifacts for the release candidate must be made available and a
VOTE thread must be started on the dev list for at least 72 hours (see
<http://www.apache.org/foundation/voting.html>). There can be several
release candidate before a version finally goes out (when I release
version 2.0 I think, we needed 6 candidates ...). When the vote passes,
the exact artifacts which were used for voting will be published by
uploading the source and binary zip and tar files and by promoting the
maven artifacts with Nexus. Not a single bit is changed (this would
change the gpg signatures). This means that for example the release date
which appears in the release notes must be estimated before the vote
taking the voting delay into account (plus one or two days as a safety
margin) and it must be updated as each release candidate is cut.
So there is no predefined release date until the vote finally passes.
At the pace at which you go now, I would say we could target a first
release candidate early next week.
Any volunteer as release manager ?
Luc
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
How do we proceed from here in order to release 3.0? Cf. ticket MATH-746,
"Things to do before releasing 3.0".
Can we start to talk about an expected release date?
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [Math] Toward releasing 3.0 ?
Posted by Patrick Meyer <me...@gmail.com>.
Looks great, thanks!
-----Original Message-----
From: Thomas Neidhart [mailto:thomas.neidhart@gmail.com]
Sent: Wednesday, February 15, 2012 2:28 PM
To: dev@commons.apache.org
Subject: Re: [Math] Toward releasing 3.0 ?
On 02/15/2012 02:41 PM, Patrick Meyer wrote:
> OK, I submited a patch that includes comments and documentation. Let
> me know if I need to write more, but I think I've covered the
> functionality of the classes.
Hi Patrick,
thanks for the patch. I have applied it together with additional code
cleanup and javadoc in r1244667.
What I have done:
- applied your javadoc patch
- added missing javadoc for variables
- moved var initialization to constructor
- changed exceptions to more specific ones
- simplified getCovarianceMatrix (uses getData() to construct the
RealMatrix)
- changed deltaX / deltaY to local variables
Could you please take a look and give feedback about the changes made?
@all: from my point of view this would resolve issue MATH-449 so far as it
is fully documented and has proper unit tests.
Thanks Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/15/2012 02:41 PM, Patrick Meyer wrote:
> OK, I submited a patch that includes comments and documentation. Let me know
> if I need to write more, but I think I've covered the functionality of the
> classes.
Hi Patrick,
thanks for the patch. I have applied it together with additional code
cleanup and javadoc in r1244667.
What I have done:
- applied your javadoc patch
- added missing javadoc for variables
- moved var initialization to constructor
- changed exceptions to more specific ones
- simplified getCovarianceMatrix (uses getData() to construct the
RealMatrix)
- changed deltaX / deltaY to local variables
Could you please take a look and give feedback about the changes made?
@all: from my point of view this would resolve issue MATH-449 so far as
it is fully documented and has proper unit tests.
Thanks Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [Math] Toward releasing 3.0 ?
Posted by Patrick Meyer <me...@gmail.com>.
OK, I submited a patch that includes comments and documentation. Let me know
if I need to write more, but I think I've covered the functionality of the
classes.
Patrick
-----Original Message-----
From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org]
Sent: Tuesday, February 14, 2012 7:46 AM
To: dev@commons.apache.org
Subject: Re: [Math] Toward releasing 3.0 ?
On Tue, Feb 14, 2012 at 01:12:50PM +0100, Thomas Neidhart wrote:
> On 02/14/2012 12:50 PM, Patrick Meyer wrote:
> > I can document the StorelessCovariance addition. What is the best
> > way to add documentation? Do I just add comments to the file and create
a patch?
>
> Yes this would be fine. I have seen that there is an open issue
> regarding this contribution, please attach the patch to it (MATH-449).
Yes, of course, that's better than creating a new one as I suggested in my
previous reply!
I've just updated the target version of MATH-449.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 15/02/2012 07:32, Sébastien Brisard a écrit :
> Dear all,
> do we need to clear all Findbugs/PMD warning prior to releasing?
Yes, and checkstyle too.
In some cases, there are false positive which must be handled by adding
the appropriate filter using specific filtering comments in the code for
checkstyle, and using findbugs-exclude.xml file for findbugs. I don't
known about PMD.
Luc
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Dear all,
I think 3.0 is very close at hand. Just a quick note to let you know
that unfortunately, I'll be away for a week, and won't be able to help
with the final brush up (if release occurs before next weekend).
Best wishes,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/17/2012 09:04 PM, Mikkel Meyer Andersen wrote:
> I am still active in theory, but in practise I unfortunately haven't
> contributed much lately due to high workload on my PhD. I am of course
> sorry for this and hope to be able to highen my activity.
>
> Regarding MATH-431, we need to discuss if we should adopt some of the
> changes R makes and find references for all these. I am on holiday
> next week, but I will be back in one week and would love to
> participate in the discussion. Meanwhile I would love some views on
> whether to adopt the changes or not. Personally, I am fine with
> noticing in the code for 3.0 release that some corrections can be made
> and refer to some (e.g. from R) but none are implemented yet.
Dear Mikkel,
good to hear from you. I will set the fix version for the issue to 3.1
as Gilles suggested.
Looking forward to discussion on this topic.
Cheers,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Mikkel Meyer Andersen <mi...@mikl.dk>.
2012/2/17 Thomas Neidhart <th...@gmail.com>:
> Hi @all,
>
> just some status/feedback on some still open issues:
>
> - MATH-449: I have implemented (almost) all suggestions from
> Phil, and the code is documented and tested, so imho the issue
> can be resolved unless somebody has still reservations
>
> - MATH-431: the two tests were contributed by Mikkel Meyer Andersen
> (is he still active?) and I have cleaned up the exceptions while
> working on another issue. There are still things to do, as can be
> seen in the comments to the issue (mainly the results are not 100%
> equivalent to R due to some specific corrections). I do not have
> the expertise to work on them myself straight away. How do we proceed
> in such a case? Keep them as they are and note the differences
> in the javadoc, or remove them unless the issues are completely
> resolved?
>
> Cheers,
>
> Thomas
Dear all,
I am still active in theory, but in practise I unfortunately haven't
contributed much lately due to high workload on my PhD. I am of course
sorry for this and hope to be able to highen my activity.
Regarding MATH-431, we need to discuss if we should adopt some of the
changes R makes and find references for all these. I am on holiday
next week, but I will be back in one week and would love to
participate in the discussion. Meanwhile I would love some views on
whether to adopt the changes or not. Personally, I am fine with
noticing in the code for 3.0 release that some corrections can be made
and refer to some (e.g. from R) but none are implemented yet.
Cheers, Mikkel.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
Hi @all,
just some status/feedback on some still open issues:
- MATH-449: I have implemented (almost) all suggestions from
Phil, and the code is documented and tested, so imho the issue
can be resolved unless somebody has still reservations
- MATH-431: the two tests were contributed by Mikkel Meyer Andersen
(is he still active?) and I have cleaned up the exceptions while
working on another issue. There are still things to do, as can be
seen in the comments to the issue (mainly the results are not 100%
equivalent to R due to some specific corrections). I do not have
the expertise to work on them myself straight away. How do we proceed
in such a case? Keep them as they are and note the differences
in the javadoc, or remove them unless the issues are completely
resolved?
Cheers,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Dear all,
do we need to clear all Findbugs/PMD warning prior to releasing?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Feb 14, 2012 at 01:12:50PM +0100, Thomas Neidhart wrote:
> On 02/14/2012 12:50 PM, Patrick Meyer wrote:
> > I can document the StorelessCovariance addition. What is the best way to add
> > documentation? Do I just add comments to the file and create a patch?
>
> Yes this would be fine. I have seen that there is an open issue
> regarding this contribution, please attach the patch to it (MATH-449).
Yes, of course, that's better than creating a new one as I suggested in my
previous reply!
I've just updated the target version of MATH-449.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/14/2012 12:50 PM, Patrick Meyer wrote:
> I can document the StorelessCovariance addition. What is the best way to add
> documentation? Do I just add comments to the file and create a patch?
Yes this would be fine. I have seen that there is an open issue
regarding this contribution, please attach the patch to it (MATH-449).
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Feb 14, 2012 at 06:50:34AM -0500, Patrick Meyer wrote:
> I can document the StorelessCovariance addition. What is the best way to add
> documentation? Do I just add comments to the file and create a patch?
>
Yes. Then please attach the diff to a new JIRA ticket (with target fix set
to 3.0). Thanks!
Gilles
> -----Original Message-----
> From: Thomas Neidhart [mailto:thomas.neidhart@gmail.com]
> Sent: Monday, February 13, 2012 9:21 AM
> To: dev@commons.apache.org
> Subject: Re: [Math] Toward releasing 3.0 ?
>
> Hi,
>
> I have seen that there are several classes that are almost undocumented:
>
> - PivotingQRDecomposition (linear)
> - StorelessCovariance (stat.correlation)
> - StorelessBivariateCovariance (stat.correlation)
>
> both seem to be quite new contributions, is somebody willing to help here?
>
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [Math] Toward releasing 3.0 ?
Posted by Patrick Meyer <me...@gmail.com>.
I can document the StorelessCovariance addition. What is the best way to add
documentation? Do I just add comments to the file and create a patch?
-----Original Message-----
From: Thomas Neidhart [mailto:thomas.neidhart@gmail.com]
Sent: Monday, February 13, 2012 9:21 AM
To: dev@commons.apache.org
Subject: Re: [Math] Toward releasing 3.0 ?
Hi,
I have seen that there are several classes that are almost undocumented:
- PivotingQRDecomposition (linear)
- StorelessCovariance (stat.correlation)
- StorelessBivariateCovariance (stat.correlation)
both seem to be quite new contributions, is somebody willing to help here?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
Hi,
I have seen that there are several classes that are almost undocumented:
- PivotingQRDecomposition (linear)
- StorelessCovariance (stat.correlation)
- StorelessBivariateCovariance (stat.correlation)
both seem to be quite new contributions, is somebody willing to help here?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >>>>>> MATH-698
> >>>>>> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >>>>>> (e.g. look at method "encode", lines 904-914).
> >>>>>> I don't have the knowledge about the algorithm in order to know how to
> >>>>>> modify that code so that it will behave correctly when only one of the
> >>>>>> bounds is infinite (a valid case allowed by the base class for optimizers
> >>>>>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>>>>>
> >>>>>> I would not want to release an API where simple bounds are dealt differently
> >>>>>> in "CMAESOptimizer" than in the supposedly common interface.
> >>>>>>
> >>>
> >>> What do you think about this point?
> >>
> >> You ae right, consistency is important. Users should be able to switch
> >> from one algorithm to another one for such common behaviour.
> >
> > This issue MATH-698 is still pending.
Anyone is welcome to have a look at that one...
> >
> > Others that were not postponed to after 3.0 are:
> > MATH-712 (trivial)
> > MATH-707 (done or almost done, depending on the comments)
>
> I would consider it is done.
Resolved.
>
> > MATH-444 (trivial)
>
> Yes, and it is probably time to do it now.
OK!
>
> >
> > Unscheduled but probably to be fixed before 3.0:
> > MATH-744
>
> Agreed.
>
> I'll resolve MATH-650 soon, making an arbitrary choice by myself (so you
> will know who is to blame).
I forgot that one ;-)
And also
MATH-672
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Gilles,
Le 13/02/2012 12:01, Gilles Sadowski a écrit :
> Hello.
>
>>>
>>>>>>>
>>>>>>> It thus becomes urgent to tackle the remaining blocking issues.
>>>>>>> Can we please make a list of those, and of all practical matters that
>>>>>>> prevent the preparation of the release?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> MATH-621 (see also MATH-728)
>>>>>> * Unit test coverage: at least 6 branches of the code are not explored.
>>>>>> * Code complexity:
>>>>>> - Variable "state" that is similar to having goto's
>>>>>> - drop from one "case" to the next (no "break")
>>>>>> - explicit matrix computations
>>>>>> * Code fragility: success or failure of some unit tests depends on the
>>>>>> order of floating point operations (addition).
>>>>>> * Support: no resource in the CM team to bring the code to a state where
>>>>>> a Java developer can maintain it.
>>>>>>
>>>>>> I'm wary to release the code in that state.
>>>>>>
>>>>> The last point is indeed quite worrying. If we are planning for a
>>>>> release taking place briefly, I'm of no use, because digging into this
>>>>> would take me forever (even if it must be done in the end by one of
>>>>> us, I suppose).
>>>>
>>>> As strange as it might seem, I would like to see this code part of 3.0
>>>> with a big "experimental" flag on it. People can use it at their own
>>>> risk, but they can also help improve it.
>>>
>>> How do we set this flag practically? A warning in the release notes?
>>
>> Yes, something alogn this line.
>
> Does this information go in the "description" attribute of the "release" tag
> in the file "changes.xml"?
Yes, it would be an appropriate place since the release notes are
extracted from this file.
>
>>
>>> If so, we should maybe also stress that we seek volunteers to clean up the
>>> code and add a thorough unit test suite.
>>
>> Yes.
>>
>>>
>>> Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
>>> supposedly a unit test (created by Greg Sterijevski) but many test methods
>>> are actually commented out because they fail; and nobody has investigated
>>> why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
>>> inherent complexity of the problem?]
>>> IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
>>> rewritten with a clear separation of the problems handled and the optimizers
>>> used to try and solve them.
>>> As is, the class should not be part of the release.
>>
>> OK, then we should remove it for the release and move it to next release.
>
> Practically, how can I do that? Just "svn del"? [If so, how is it moved in
> again for the nex release?]
I would rather set up a 3.0 release branch and do the svn del here.
>
>>>
>>>>>>
>>>>>> MATH-698
>>>>>> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>>>>> (e.g. look at method "encode", lines 904-914).
>>>>>> I don't have the knowledge about the algorithm in order to know how to
>>>>>> modify that code so that it will behave correctly when only one of the
>>>>>> bounds is infinite (a valid case allowed by the base class for optimizers
>>>>>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>>>
>>>>>> I would not want to release an API where simple bounds are dealt differently
>>>>>> in "CMAESOptimizer" than in the supposedly common interface.
>>>>>>
>>>
>>> What do you think about this point?
>>
>> You ae right, consistency is important. Users should be able to switch
>> from one algorithm to another one for such common behaviour.
>
> This issue MATH-698 is still pending.
>
> Others that were not postponed to after 3.0 are:
> MATH-712 (trivial)
> MATH-707 (done or almost done, depending on the comments)
I would consider it is done.
> MATH-444 (trivial)
Yes, and it is probably time to do it now.
>
> Unscheduled but probably to be fixed before 3.0:
> MATH-744
Agreed.
I'll resolve MATH-650 soon, making an arbitrary choice by myself (so you
will know who is to blame).
Luc
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >
> >>>>>
> >>>>> It thus becomes urgent to tackle the remaining blocking issues.
> >>>>> Can we please make a list of those, and of all practical matters that
> >>>>> prevent the preparation of the release?
> >>>>>
> >>>>
> >>>>
> >>>> MATH-621 (see also MATH-728)
> >>>> * Unit test coverage: at least 6 branches of the code are not explored.
> >>>> * Code complexity:
> >>>> - Variable "state" that is similar to having goto's
> >>>> - drop from one "case" to the next (no "break")
> >>>> - explicit matrix computations
> >>>> * Code fragility: success or failure of some unit tests depends on the
> >>>> order of floating point operations (addition).
> >>>> * Support: no resource in the CM team to bring the code to a state where
> >>>> a Java developer can maintain it.
> >>>>
> >>>> I'm wary to release the code in that state.
> >>>>
> >>> The last point is indeed quite worrying. If we are planning for a
> >>> release taking place briefly, I'm of no use, because digging into this
> >>> would take me forever (even if it must be done in the end by one of
> >>> us, I suppose).
> >>
> >> As strange as it might seem, I would like to see this code part of 3.0
> >> with a big "experimental" flag on it. People can use it at their own
> >> risk, but they can also help improve it.
> >
> > How do we set this flag practically? A warning in the release notes?
>
> Yes, something alogn this line.
Does this information go in the "description" attribute of the "release" tag
in the file "changes.xml"?
>
> > If so, we should maybe also stress that we seek volunteers to clean up the
> > code and add a thorough unit test suite.
>
> Yes.
>
> >
> > Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
> > supposedly a unit test (created by Greg Sterijevski) but many test methods
> > are actually commented out because they fail; and nobody has investigated
> > why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
> > inherent complexity of the problem?]
> > IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
> > rewritten with a clear separation of the problems handled and the optimizers
> > used to try and solve them.
> > As is, the class should not be part of the release.
>
> OK, then we should remove it for the release and move it to next release.
Practically, how can I do that? Just "svn del"? [If so, how is it moved in
again for the nex release?]
> >
> >>>>
> >>>> MATH-698
> >>>> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >>>> (e.g. look at method "encode", lines 904-914).
> >>>> I don't have the knowledge about the algorithm in order to know how to
> >>>> modify that code so that it will behave correctly when only one of the
> >>>> bounds is infinite (a valid case allowed by the base class for optimizers
> >>>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>>>
> >>>> I would not want to release an API where simple bounds are dealt differently
> >>>> in "CMAESOptimizer" than in the supposedly common interface.
> >>>>
> >
> > What do you think about this point?
>
> You ae right, consistency is important. Users should be able to switch
> from one algorithm to another one for such common behaviour.
This issue MATH-698 is still pending.
Others that were not postponed to after 3.0 are:
MATH-712 (trivial)
MATH-707 (done or almost done, depending on the comments)
MATH-444 (trivial)
Unscheduled but probably to be fixed before 3.0:
MATH-744
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 27/01/2012 12:48, Gilles Sadowski a écrit :
> Hi.
Hi Gilles,
>
>>>>>
>>>>> It thus becomes urgent to tackle the remaining blocking issues.
>>>>> Can we please make a list of those, and of all practical matters that
>>>>> prevent the preparation of the release?
>>>>>
>>>>
>>>>
>>>> MATH-621 (see also MATH-728)
>>>> * Unit test coverage: at least 6 branches of the code are not explored.
>>>> * Code complexity:
>>>> - Variable "state" that is similar to having goto's
>>>> - drop from one "case" to the next (no "break")
>>>> - explicit matrix computations
>>>> * Code fragility: success or failure of some unit tests depends on the
>>>> order of floating point operations (addition).
>>>> * Support: no resource in the CM team to bring the code to a state where
>>>> a Java developer can maintain it.
>>>>
>>>> I'm wary to release the code in that state.
>>>>
>>> The last point is indeed quite worrying. If we are planning for a
>>> release taking place briefly, I'm of no use, because digging into this
>>> would take me forever (even if it must be done in the end by one of
>>> us, I suppose).
>>
>> As strange as it might seem, I would like to see this code part of 3.0
>> with a big "experimental" flag on it. People can use it at their own
>> risk, but they can also help improve it.
>
> How do we set this flag practically? A warning in the release notes?
Yes, something alogn this line.
> If so, we should maybe also stress that we seek volunteers to clean up the
> code and add a thorough unit test suite.
Yes.
>
> Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
> supposedly a unit test (created by Greg Sterijevski) but many test methods
> are actually commented out because they fail; and nobody has investigated
> why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
> inherent complexity of the problem?]
> IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
> rewritten with a clear separation of the problems handled and the optimizers
> used to try and solve them.
> As is, the class should not be part of the release.
OK, then we should remove it for the release and move it to next release.
>
>>>>
>>>> MATH-698
>>>> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>>> (e.g. look at method "encode", lines 904-914).
>>>> I don't have the knowledge about the algorithm in order to know how to
>>>> modify that code so that it will behave correctly when only one of the
>>>> bounds is infinite (a valid case allowed by the base class for optimizers
>>>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>
>>>> I would not want to release an API where simple bounds are dealt differently
>>>> in "CMAESOptimizer" than in the supposedly common interface.
>>>>
>
> What do you think about this point?
You ae right, consistency is important. Users should be able to switch
from one algorithm to another one for such common behaviour.
Luc
>
>
> Regards,
> Gilles
>
>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> >>>
> >>> It thus becomes urgent to tackle the remaining blocking issues.
> >>> Can we please make a list of those, and of all practical matters that
> >>> prevent the preparation of the release?
> >>>
> >>
> >>
> >> MATH-621 (see also MATH-728)
> >> * Unit test coverage: at least 6 branches of the code are not explored.
> >> * Code complexity:
> >> - Variable "state" that is similar to having goto's
> >> - drop from one "case" to the next (no "break")
> >> - explicit matrix computations
> >> * Code fragility: success or failure of some unit tests depends on the
> >> order of floating point operations (addition).
> >> * Support: no resource in the CM team to bring the code to a state where
> >> a Java developer can maintain it.
> >>
> >> I'm wary to release the code in that state.
> >>
> > The last point is indeed quite worrying. If we are planning for a
> > release taking place briefly, I'm of no use, because digging into this
> > would take me forever (even if it must be done in the end by one of
> > us, I suppose).
>
> As strange as it might seem, I would like to see this code part of 3.0
> with a big "experimental" flag on it. People can use it at their own
> risk, but they can also help improve it.
How do we set this flag practically? A warning in the release notes?
If so, we should maybe also stress that we seek volunteers to clean up the
code and add a thorough unit test suite.
Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
supposedly a unit test (created by Greg Sterijevski) but many test methods
are actually commented out because they fail; and nobody has investigated
why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
inherent complexity of the problem?]
IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
rewritten with a clear separation of the problems handled and the optimizers
used to try and solve them.
As is, the class should not be part of the release.
> >>
> >> MATH-698
> >> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >> (e.g. look at method "encode", lines 904-914).
> >> I don't have the knowledge about the algorithm in order to know how to
> >> modify that code so that it will behave correctly when only one of the
> >> bounds is infinite (a valid case allowed by the base class for optimizers
> >> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>
> >> I would not want to release an API where simple bounds are dealt differently
> >> in "CMAESOptimizer" than in the supposedly common interface.
> >>
What do you think about this point?
Regards,
Gilles
> >> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 26/01/2012 15:52, Sébastien Brisard a écrit :
> Hello,
>> Hi.
>>
>>>
>>> It thus becomes urgent to tackle the remaining blocking issues.
>>> Can we please make a list of those, and of all practical matters that
>>> prevent the preparation of the release?
>>>
>>
>>
>> MATH-621 (see also MATH-728)
>> * Unit test coverage: at least 6 branches of the code are not explored.
>> * Code complexity:
>> - Variable "state" that is similar to having goto's
>> - drop from one "case" to the next (no "break")
>> - explicit matrix computations
>> * Code fragility: success or failure of some unit tests depends on the
>> order of floating point operations (addition).
>> * Support: no resource in the CM team to bring the code to a state where
>> a Java developer can maintain it.
>>
>> I'm wary to release the code in that state.
>>
> The last point is indeed quite worrying. If we are planning for a
> release taking place briefly, I'm of no use, because digging into this
> would take me forever (even if it must be done in the end by one of
> us, I suppose).
As strange as it might seem, I would like to see this code part of 3.0
with a big "experimental" flag on it. People can use it at their own
risk, but they can also help improve it.
Luc
>
>>
>> MATH-698
>> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>> (e.g. look at method "encode", lines 904-914).
>> I don't have the knowledge about the algorithm in order to know how to
>> modify that code so that it will behave correctly when only one of the
>> bounds is infinite (a valid case allowed by the base class for optimizers
>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>
>> I would not want to release an API where simple bounds are dealt differently
>> in "CMAESOptimizer" than in the supposedly common interface.
>>
>>
>> MATH-726
>> This is really a small issue. But the discussion has stalled because of a
>> long-term wish concerning a design convergence with the "nabla" project.
>> I'd rather introduce the code now, in a form that is similar to the design
>> of other packages ("solvers", "optimization", "integration").
>> I see no problem in changing that later, in the same way that there are
>> suggestions to change other things (e.g. matrix interface, factories, ...).
>>
> I agree. It's only after playing around with this new feature that we
> will be able to find its (potential) flaws. However, I do realize that
> not everyone may agree on this...
>>
>> MATH-707
>> A few more changes to be done.
>>
>>
>> Regards,
>> Gilles
>>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hello,
> Hi.
>
>>
>> It thus becomes urgent to tackle the remaining blocking issues.
>> Can we please make a list of those, and of all practical matters that
>> prevent the preparation of the release?
>>
>
>
> MATH-621 (see also MATH-728)
> * Unit test coverage: at least 6 branches of the code are not explored.
> * Code complexity:
> - Variable "state" that is similar to having goto's
> - drop from one "case" to the next (no "break")
> - explicit matrix computations
> * Code fragility: success or failure of some unit tests depends on the
> order of floating point operations (addition).
> * Support: no resource in the CM team to bring the code to a state where
> a Java developer can maintain it.
>
> I'm wary to release the code in that state.
>
The last point is indeed quite worrying. If we are planning for a
release taking place briefly, I'm of no use, because digging into this
would take me forever (even if it must be done in the end by one of
us, I suppose).
>
> MATH-698
> IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> (e.g. look at method "encode", lines 904-914).
> I don't have the knowledge about the algorithm in order to know how to
> modify that code so that it will behave correctly when only one of the
> bounds is infinite (a valid case allowed by the base class for optimizers
> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>
> I would not want to release an API where simple bounds are dealt differently
> in "CMAESOptimizer" than in the supposedly common interface.
>
>
> MATH-726
> This is really a small issue. But the discussion has stalled because of a
> long-term wish concerning a design convergence with the "nabla" project.
> I'd rather introduce the code now, in a form that is similar to the design
> of other packages ("solvers", "optimization", "integration").
> I see no problem in changing that later, in the same way that there are
> suggestions to change other things (e.g. matrix interface, factories, ...).
>
I agree. It's only after playing around with this new feature that we
will be able to find its (potential) flaws. However, I do realize that
not everyone may agree on this...
>
> MATH-707
> A few more changes to be done.
>
>
> Regards,
> Gilles
>
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>
MATH-621 (see also MATH-728)
* Unit test coverage: at least 6 branches of the code are not explored.
* Code complexity:
- Variable "state" that is similar to having goto's
- drop from one "case" to the next (no "break")
- explicit matrix computations
* Code fragility: success or failure of some unit tests depends on the
order of floating point operations (addition).
* Support: no resource in the CM team to bring the code to a state where
a Java developer can maintain it.
I'm wary to release the code in that state.
MATH-698
IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
(e.g. look at method "encode", lines 904-914).
I don't have the knowledge about the algorithm in order to know how to
modify that code so that it will behave correctly when only one of the
bounds is infinite (a valid case allowed by the base class for optimizers
with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
I would not want to release an API where simple bounds are dealt differently
in "CMAESOptimizer" than in the supposedly common interface.
MATH-726
This is really a small issue. But the discussion has stalled because of a
long-term wish concerning a design convergence with the "nabla" project.
I'd rather introduce the code now, in a form that is similar to the design
of other packages ("solvers", "optimization", "integration").
I see no problem in changing that later, in the same way that there are
suggestions to change other things (e.g. matrix interface, factories, ...).
MATH-707
A few more changes to be done.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
2012/1/26 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hello.
>
>> > It thus becomes urgent to tackle the remaining blocking issues.
>> > Can we please make a list of those, and of all practical matters that
>> > prevent the preparation of the release?
>> >
>> >
>> > Thanks and best regards,
>> > Gilles
>> >
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.
> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).
>
Yes, you're right. So the quick answer is : the fix proposed by Juan
is correct and *should* be implemented. However, I'm worried about
accuracy of tanh(z) for large (but not too-large) values of the real
part of z. I haven't had the time yet to investigate this specific
point.
>> There is one thing I would like to reshape a little bit : that's the
>> interface for IterativeLinearSolvers, which I found (after having used
>> it) poorly designed. As this is blocking, maybe I should concentrate
>> on this issue right now ?
>
> This, in my opinion, is not blocking. Maybe the design must be improved (as
> your own usage has shown already, it seems) but it could be done in 4.0.
> This design issue should not delay the release of 3.0.
> Of course, you can do whatever changes you think would be for the better.
> :-)
>
What I meant is: once it's in the wild, we cannot do anything until
the next major release. I would like to add a couple of methods in the
current interface (merely to be able to retrieve the current value of
the residual, and the current iteration number). In fact I've been
using these solvers recently and have lacked these methods. This can
be done fairly quickly, but I need to think a little bit on the most
appropriate way. Nothing major, but it would be nice if it was already
in 3.0.
>> Otherwise, I'm available for anything that would take us nearer to
>> releasing 3.0 (how exciting! First release since I joined!).
>
> Same for me (first _major_ release).
>
> Those who know what must be done, could you please post here some pointers
> to a document that decribe the currently recommended and necessary steps for
> preparing a release?
>
>
> Thanks,
> Gilles
>
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 26/01/2012 15:39, Gilles Sadowski a écrit :
> Hello.
>
>>> It thus becomes urgent to tackle the remaining blocking issues.
>>> Can we please make a list of those, and of all practical matters that
>>> prevent the preparation of the release?
>>>
>>>
>>> Thanks and best regards,
>>> Gilles
>>>
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.
> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).
>
>> There is one thing I would like to reshape a little bit : that's the
>> interface for IterativeLinearSolvers, which I found (after having used
>> it) poorly designed. As this is blocking, maybe I should concentrate
>> on this issue right now ?
>
> This, in my opinion, is not blocking. Maybe the design must be improved (as
> your own usage has shown already, it seems) but it could be done in 4.0.
> This design issue should not delay the release of 3.0.
+1
> Of course, you can do whatever changes you think would be for the better.
> :-)
>
>> Otherwise, I'm available for anything that would take us nearer to
>> releasing 3.0 (how exciting! First release since I joined!).
>
> Same for me (first _major_ release).
I agree we should release now, sorry for the very long delay.
>
> Those who know what must be done, could you please post here some pointers
> to a document that decribe the currently recommended and necessary steps for
> preparing a release?
If you plane to use Nexus, here are some guidelines, mainly written by
Sebb if I remember well: <http://wiki.apache.org/commons/UsingNexus>.
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by sebb <se...@gmail.com>.
On 26 January 2012 14:39, Gilles Sadowski <gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> > It thus becomes urgent to tackle the remaining blocking issues.
>> > Can we please make a list of those, and of all practical matters that
>> > prevent the preparation of the release?
>> >
>> >
>> > Thanks and best regards,
>> > Gilles
>> >
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.
As usual - it depends.
If the bug is a regression then it should probably block a release.
But even then, if the reason for the regression was to fix a worse
bug, then it may be OK to release.
It also depends on the relative cost of fixing the bug before and
after a release.
If the bug is in a new API, it's generally going to be cheaper to fix
before release rather than break compatibility later.
> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).
Adding a warning for known (major) bugs is a good idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> > It thus becomes urgent to tackle the remaining blocking issues.
> > Can we please make a list of those, and of all practical matters that
> > prevent the preparation of the release?
> >
> >
> > Thanks and best regards,
> > Gilles
> >
> As far as I'm concerned, I have been concentrating recently on
> MATH-677 and MATH-722. However, both issues are non-blocking, because
> I don't foresee any interface change now (regarding MATH-677, exposing
> the complex roots would just be a feature addition, as it is a private
> class right now). MATH-722 would merely be a bug correction.
It was my impression that an identified bug is a blocking issue.
Is it difficult to solve? If so, maybe that we can postpone it, and add a
warning in the release notes (?).
> There is one thing I would like to reshape a little bit : that's the
> interface for IterativeLinearSolvers, which I found (after having used
> it) poorly designed. As this is blocking, maybe I should concentrate
> on this issue right now ?
This, in my opinion, is not blocking. Maybe the design must be improved (as
your own usage has shown already, it seems) but it could be done in 4.0.
This design issue should not delay the release of 3.0.
Of course, you can do whatever changes you think would be for the better.
:-)
> Otherwise, I'm available for anything that would take us nearer to
> releasing 3.0 (how exciting! First release since I joined!).
Same for me (first _major_ release).
Those who know what must be done, could you please post here some pointers
to a document that decribe the currently recommended and necessary steps for
preparing a release?
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Gilles,
>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>
>
> Thanks and best regards,
> Gilles
>
As far as I'm concerned, I have been concentrating recently on
MATH-677 and MATH-722. However, both issues are non-blocking, because
I don't foresee any interface change now (regarding MATH-677, exposing
the complex roots would just be a feature addition, as it is a private
class right now). MATH-722 would merely be a bug correction.
There is one thing I would like to reshape a little bit : that's the
interface for IterativeLinearSolvers, which I found (after having used
it) poorly designed. As this is blocking, maybe I should concentrate
on this issue right now ?
Otherwise, I'm available for anything that would take us nearer to
releasing 3.0 (how exciting! First release since I joined!).
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/25/2012 01:13 PM, Gilles Sadowski wrote:
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
Hi,
a release quite soon would also be appreciated from my side.
As for the issues I am currently work on:
- MATH-235, which is still targeted for 3.1 but it would be nice to
include it already in 3.0 and it should be ready in 1-2 weeks
- MATH-651 which is directly related to MATH-235
- MATH-575 for the cleanup of the genetics package which should be
almost done I guess
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 27/01/2012 20:44, Sébastien Brisard a écrit :
> Hi Luc,
> thanks for this answer.
>>>
>>> My problem is that I do not know what getSolverAbsoluteAccuracy()
>>> should return. I see three options
>>> 1. Have getSolverAbsoluteAccuracy() throw an
>>> UnsupportedOperationException, as the solver is *never* invoked.
>>> 2. Return a default value, and specify in the Javadoc that it is
>>> meaningless or not really meaningful ;).
>>> 3. Return an estimate of the absolute accuracy of the explicit above
>>> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
>>> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>>>
>>> My preferred option is 1. I dislike option 2, because users might
>>> actually be using the returned value, believing it to somehow reflect
>>> the accuracy of the value returned by
>>> inverseCumulativeProbability(double). Option 3 would be a good
>>> compromise, but I certainly do not have the level of expertise to come
>>> up with this estimate... Any help would be most welcome!
>>
>> I don't like UnsupportedOperationException.
>>
> Fine.
>> In this case, I would say
>> the explicit formula is some kind of "perfect" solver
> I agree
>>
>> which has a
>> theoretical accuracy of zero (or 1 ulp). So I would return this value.
>>
> Yes, but one ulp of which number? What I have implemented so far is
> return Math.ulp(c) (the intermediate value). I sould probably return
> Math.max(Math.ulp(a), Math.ulp(b)), what do you think?
Both are fine.
Luc
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Luc,
thanks for this answer.
>>
>> My problem is that I do not know what getSolverAbsoluteAccuracy()
>> should return. I see three options
>> 1. Have getSolverAbsoluteAccuracy() throw an
>> UnsupportedOperationException, as the solver is *never* invoked.
>> 2. Return a default value, and specify in the Javadoc that it is
>> meaningless or not really meaningful ;).
>> 3. Return an estimate of the absolute accuracy of the explicit above
>> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
>> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>>
>> My preferred option is 1. I dislike option 2, because users might
>> actually be using the returned value, believing it to somehow reflect
>> the accuracy of the value returned by
>> inverseCumulativeProbability(double). Option 3 would be a good
>> compromise, but I certainly do not have the level of expertise to come
>> up with this estimate... Any help would be most welcome!
>
> I don't like UnsupportedOperationException.
>
Fine.
> In this case, I would say
> the explicit formula is some kind of "perfect" solver
I agree
>
> which has a
> theoretical accuracy of zero (or 1 ulp). So I would return this value.
>
Yes, but one ulp of which number? What I have implemented so far is
return Math.ulp(c) (the intermediate value). I sould probably return
Math.max(Math.ulp(a), Math.ulp(b)), what do you think?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 27/01/2012 13:55, Sébastien Brisard a écrit :
> Hi
>>
>> It thus becomes urgent to tackle the remaining blocking issues.
>> Can we please make a list of those, and of all practical matters that
>> prevent the preparation of the release?
>>
>
> MATH-731 is pretty much solved, but I still need a piece of advice.
> Let me explain : the triangular distribution is so simple that
> explicit formula have been implemented for
> inverseCumulativeProbability(double) (see below).
>
> {code}
> public double inverseCumulativeProbability(double p)
> throws OutOfRangeException {
> if (p < 0.0 || p > 1.0) {
> throw new OutOfRangeException(p, 0, 1);
> }
> if (p == 0.0) {
> return a;
> }
> if (p == 1.0) {
> return b;
> }
> final double pc = (c - a) / (b - a);
> if (p == pc) {
> return c;
> }
> if (p < pc) {
> return a + FastMath.sqrt(p * (b - a) * (c - a));
> }
> return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
> }
> {code}
>
> My problem is that I do not know what getSolverAbsoluteAccuracy()
> should return. I see three options
> 1. Have getSolverAbsoluteAccuracy() throw an
> UnsupportedOperationException, as the solver is *never* invoked.
> 2. Return a default value, and specify in the Javadoc that it is
> meaningless or not really meaningful ;).
> 3. Return an estimate of the absolute accuracy of the explicit above
> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>
> My preferred option is 1. I dislike option 2, because users might
> actually be using the returned value, believing it to somehow reflect
> the accuracy of the value returned by
> inverseCumulativeProbability(double). Option 3 would be a good
> compromise, but I certainly do not have the level of expertise to come
> up with this estimate... Any help would be most welcome!
I don't like UnsupportedOperationException. In this case, I would say
the explicit formula is some kind of "perfect" solver which has a
theoretical accuracy of zero (or 1 ulp). So I would return this value.
Luc
>
> What do you think?
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hi
>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>
MATH-731 is pretty much solved, but I still need a piece of advice.
Let me explain : the triangular distribution is so simple that
explicit formula have been implemented for
inverseCumulativeProbability(double) (see below).
{code}
public double inverseCumulativeProbability(double p)
throws OutOfRangeException {
if (p < 0.0 || p > 1.0) {
throw new OutOfRangeException(p, 0, 1);
}
if (p == 0.0) {
return a;
}
if (p == 1.0) {
return b;
}
final double pc = (c - a) / (b - a);
if (p == pc) {
return c;
}
if (p < pc) {
return a + FastMath.sqrt(p * (b - a) * (c - a));
}
return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
}
{code}
My problem is that I do not know what getSolverAbsoluteAccuracy()
should return. I see three options
1. Have getSolverAbsoluteAccuracy() throw an
UnsupportedOperationException, as the solver is *never* invoked.
2. Return a default value, and specify in the Javadoc that it is
meaningless or not really meaningful ;).
3. Return an estimate of the absolute accuracy of the explicit above
expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
FastMath.sqrt((1 - p) * (b - a) * (b - c)).
My preferred option is 1. I dislike option 2, because users might
actually be using the returned value, believing it to somehow reflect
the accuracy of the value returned by
inverseCumulativeProbability(double). Option 3 would be a good
compromise, but I certainly do not have the level of expertise to come
up with this estimate... Any help would be most welcome!
What do you think?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org