[jira] Resolved: (MATH-406) Wrong weight handling in Levenberg-Marquardt
[ https://issues.apache.org/jira/browse/MATH-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dimitri Pourbaix resolved MATH-406. --- Resolution: Fixed > Wrong weight handling in Levenberg-Marquardt > > > Key: MATH-406 > URL: https://issues.apache.org/jira/browse/MATH-406 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Dimitri Pourbaix >Assignee: Dimitri Pourbaix > Fix For: Nightly Builds > > Attachments: MATH-406.patch > > > A comparison with a Fortran version of Levenberg-Marquardt reveals that when > observations have different weights, the 2.1 version reaches a value of the > function which does not necessary correspond to the minimum -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-406) Wrong weight handling in Levenberg-Marquardt
[ https://issues.apache.org/jira/browse/MATH-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dimitri Pourbaix updated MATH-406: -- Attachment: MATH-406.patch Correction patch. > Wrong weight handling in Levenberg-Marquardt > > > Key: MATH-406 > URL: https://issues.apache.org/jira/browse/MATH-406 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Dimitri Pourbaix >Assignee: Dimitri Pourbaix > Fix For: Nightly Builds > > Attachments: MATH-406.patch > > > A comparison with a Fortran version of Levenberg-Marquardt reveals that when > observations have different weights, the 2.1 version reaches a value of the > function which does not necessary correspond to the minimum -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-406) Wrong weight handling in Levenberg-Marquardt
Wrong weight handling in Levenberg-Marquardt Key: MATH-406 URL: https://issues.apache.org/jira/browse/MATH-406 Project: Commons Math Issue Type: Bug Affects Versions: 2.1 Reporter: Dimitri Pourbaix Assignee: Dimitri Pourbaix Fix For: Nightly Builds A comparison with a Fortran version of Levenberg-Marquardt reveals that when observations have different weights, the 2.1 version reaches a value of the function which does not necessary correspond to the minimum -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-397) Inconsistencies between "optimization.univariate" and "optimization.general"
[
https://issues.apache.org/jira/browse/MATH-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898641#action_12898641
]
Luc Maisonobe commented on MATH-397:
OK to either remove or rename ConvergingAlgorithm.
For the interface setting max iteration and getting evaluation ... what about
IterativeAlgorithm ? ;-)
Not sure about gradients. If you think a single combined counter is enough go
for it. From a users point of view, this is simpler and I don't think much
functionality would be lost with a single counter. I don't even know what a
user could say if the number of functions evaluation was low and the number of
gradients evaluation was high. It would be confusing but may happen.
OK for moving UnivariateRealOptimizer and for the new pair.
> Inconsistencies between "optimization.univariate" and "optimization.general"
>
>
> Key: MATH-397
> URL: https://issues.apache.org/jira/browse/MATH-397
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 2.2
>
>
> I think that we could make the usage (from the developer's point-of-view) of
> "optimization.univariate" more similar to what is done in
> "optimization.general". At first this looked like a small change but then I
> discovered that "AbstractUnivariateRealOptimizer" competes with
> "ConvergingAlgorithmImpl" for some functionality, and that everything could
> be more coherent by enforcing the use of accessors and avoiding "protected"
> fields.
> Moreover the logic inside "AbstractUnivariateRealOptimizer" seems convoluted
> and one change leading to another...
> Currently only "BrentOptimizer" inherits from
> "AbstractUnivariateRealOptimizer", so I hope that it's OK to revise that
> class.
> In "ConvergingAlgorithmImpl", I propose to add a method:
> {code}
> protected void incrementIterationsCounter()
> throws ConvergenceException {
> if (++iterationCount > maximalIterationCount) {
> throw new ConvergenceException(new
> MaxIterationsExceededException(maximalIterationCount));
> }
> }
> {code}
> This is still not the best since in "BaseAbstractScalarOptimizer", we have
> {code}
> protected void incrementIterationsCounter()
> throws OptimizationException {
> if (++iterations > maxIterations) {
> throw new OptimizationException(new
> MaxIterationsExceededException(maxIterations));
> }
> }
> {code}
> (thus: two codes for the same problem, throwing different exceptions).
> Then it seems that there is also a functionality overlap between
> "ConvergingAlgorithm" and "ConvergenceChecker"...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXEC-36) CommandLine does not work with double quote or single quote correctly
[
https://issues.apache.org/jira/browse/EXEC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898640#action_12898640
]
Siegfried Goeschl commented on EXEC-36:
---
When using the API to build the command line incrementally (and not parsing the
command line string) it is possible to recreate Kai's command line as shown in
DefaultExecutorTest#testExec36_1() under Unix.
> CommandLine does not work with double quote or single quote correctly
> -
>
> Key: EXEC-36
> URL: https://issues.apache.org/jira/browse/EXEC-36
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Ubuntu 704, JDK1.6
>Reporter: Kai Hu
>Assignee: Siegfried Goeschl
>Priority: Critical
> Attachments: ExecParseUtils.java, ExecParseUtilsTest.java
>
>
> Please review and run the following junit test, either apache ant or apache
> exec does not handle the qoute in the arguments correctly.
>@Test
> public void shouldHandleTheDoubelQuote() throws Exception {
> String commandline = "./script/jrake cruise:publish_installers "
> + "INSTALLER_VERSION=unstable_2_1 "
> + "INSTALLER_PATH=\"/var/lib/ cruise-agent/installers\" "
> + "INSTALLER_DOWNLOAD_SERVER='something'"
> + "WITHOUT_HELP_DOC=true";
> CommandLine line = CommandLine.parse(commandline);
> String[] args = line.getArguments();
> assertThat(args[0], is("cruise:publish_installers"));
> assertThat(args[1], is("INSTALLER_VERSION=unstable_2_1"));
> assertThat(args[2], is("INSTALLER_PATH=\"/var/lib/
> cruise-agent/installers\""));
> assertThat(args[3], is("INSTALLER_DOWNLOAD_SERVER='something'"));
> assertThat(args[4], is("WITHOUT_HELP_DOC=true"));
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (EXEC-36) CommandLine does not work with double quote or single quote correctly
[
https://issues.apache.org/jira/browse/EXEC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl updated EXEC-36:
--
Attachment: ExecParseUtils.java
ExecParseUtilsTest.java
Code based on Mitko's work in Apache Camel
> CommandLine does not work with double quote or single quote correctly
> -
>
> Key: EXEC-36
> URL: https://issues.apache.org/jira/browse/EXEC-36
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Ubuntu 704, JDK1.6
>Reporter: Kai Hu
>Assignee: Siegfried Goeschl
>Priority: Critical
> Attachments: ExecParseUtils.java, ExecParseUtilsTest.java
>
>
> Please review and run the following junit test, either apache ant or apache
> exec does not handle the qoute in the arguments correctly.
>@Test
> public void shouldHandleTheDoubelQuote() throws Exception {
> String commandline = "./script/jrake cruise:publish_installers "
> + "INSTALLER_VERSION=unstable_2_1 "
> + "INSTALLER_PATH=\"/var/lib/ cruise-agent/installers\" "
> + "INSTALLER_DOWNLOAD_SERVER='something'"
> + "WITHOUT_HELP_DOC=true";
> CommandLine line = CommandLine.parse(commandline);
> String[] args = line.getArguments();
> assertThat(args[0], is("cruise:publish_installers"));
> assertThat(args[1], is("INSTALLER_VERSION=unstable_2_1"));
> assertThat(args[2], is("INSTALLER_PATH=\"/var/lib/
> cruise-agent/installers\""));
> assertThat(args[3], is("INSTALLER_DOWNLOAD_SERVER='something'"));
> assertThat(args[4], is("WITHOUT_HELP_DOC=true"));
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXEC-41) Patch to enable executing thread to return immediately when process is "killed" by a watchdog
[ https://issues.apache.org/jira/browse/EXEC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EXEC-41. --- Resolution: Won't Fix > Patch to enable executing thread to return immediately when process is > "killed" by a watchdog > - > > Key: EXEC-41 > URL: https://issues.apache.org/jira/browse/EXEC-41 > Project: Commons Exec > Issue Type: Improvement >Affects Versions: 1.0, 1.1 > Environment: Windows XP >Reporter: Ernest Mishkin >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.1 > > Attachments: commons-exec.patch, EXEC-41.patch > > > This has been discussed on the commons-users mailing list. The patch intends > to solve the following problem: > when a process runs longer than allowed by a configured watchdog's timeout, > the watchdog tries to destroy it and then DefaultExecutor tries to clean up > by joining with all installed pump stream threads. Problem is, that sometimes > the native process doesn't die and thus streams aren't closed and the stream > threads do not complete. > The patch provides setAlwaysWaitForStreamThreads(boolean) method in > PumpStreamHandler. By default, alwaysWaitForStreamThreads is set to true to > preserve the current behavior. If set to false, and process is killed by > watchdog, DefaultExecutor's call into ErrorStreamHandler.stop will NOT join > the stream threads and DefaultExecutor will NOT attempt to close the streams, > so the executor's thread won't get stuck. > Additionally, this patch fixes a small but annoying bug in > DefaultExecuteHandler.setExitValues(int[]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (EXEC-41) Patch to enable executing thread to return immediately when process is "killed" by a watchdog
[ https://issues.apache.org/jira/browse/EXEC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl updated EXEC-41: -- Attachment: EXEC-41.patch Reverted changes when trying to fix EXEC-41 > Patch to enable executing thread to return immediately when process is > "killed" by a watchdog > - > > Key: EXEC-41 > URL: https://issues.apache.org/jira/browse/EXEC-41 > Project: Commons Exec > Issue Type: Improvement >Affects Versions: 1.0, 1.1 > Environment: Windows XP >Reporter: Ernest Mishkin >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.1 > > Attachments: commons-exec.patch, EXEC-41.patch > > > This has been discussed on the commons-users mailing list. The patch intends > to solve the following problem: > when a process runs longer than allowed by a configured watchdog's timeout, > the watchdog tries to destroy it and then DefaultExecutor tries to clean up > by joining with all installed pump stream threads. Problem is, that sometimes > the native process doesn't die and thus streams aren't closed and the stream > threads do not complete. > The patch provides setAlwaysWaitForStreamThreads(boolean) method in > PumpStreamHandler. By default, alwaysWaitForStreamThreads is set to true to > preserve the current behavior. If set to false, and process is killed by > watchdog, DefaultExecutor's call into ErrorStreamHandler.stop will NOT join > the stream threads and DefaultExecutor will NOT attempt to close the streams, > so the executor's thread won't get stuck. > Additionally, this patch fixes a small but annoying bug in > DefaultExecuteHandler.setExitValues(int[]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (EXEC-41) Patch to enable executing thread to return immediately when process is "killed" by a watchdog
[ https://issues.apache.org/jira/browse/EXEC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl reopened EXEC-41: --- Testing under Windows showed that the patch does not solve the problem - with the patch applied the code now hangs now in DefaultExecutor.closeStreams() until the process (and its children) are terminated. Created a patch with the modifications and reverted them for the code under version control. > Patch to enable executing thread to return immediately when process is > "killed" by a watchdog > - > > Key: EXEC-41 > URL: https://issues.apache.org/jira/browse/EXEC-41 > Project: Commons Exec > Issue Type: Improvement >Affects Versions: 1.0, 1.1 > Environment: Windows XP >Reporter: Ernest Mishkin >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.1 > > Attachments: commons-exec.patch > > > This has been discussed on the commons-users mailing list. The patch intends > to solve the following problem: > when a process runs longer than allowed by a configured watchdog's timeout, > the watchdog tries to destroy it and then DefaultExecutor tries to clean up > by joining with all installed pump stream threads. Problem is, that sometimes > the native process doesn't die and thus streams aren't closed and the stream > threads do not complete. > The patch provides setAlwaysWaitForStreamThreads(boolean) method in > PumpStreamHandler. By default, alwaysWaitForStreamThreads is set to true to > preserve the current behavior. If set to false, and process is killed by > watchdog, DefaultExecutor's call into ErrorStreamHandler.stop will NOT join > the stream threads and DefaultExecutor will NOT attempt to close the streams, > so the executor's thread won't get stuck. > Additionally, this patch fixes a small but annoying bug in > DefaultExecuteHandler.setExitValues(int[]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXEC-34) Race condition prevent watchdog working using ExecuteStreamHandler
[
https://issues.apache.org/jira/browse/EXEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898631#action_12898631
]
Siegfried Goeschl commented on EXEC-34:
---
Well, actually the sample is buggy since the following line is missing
exec.setWatchdog(watchdog)
which injects the newly created 'Process' instance into the watchdog and
without *Process' instance 'watchdog.destroy()' has no effect
> Race condition prevent watchdog working using ExecuteStreamHandler
> --
>
> Key: EXEC-34
> URL: https://issues.apache.org/jira/browse/EXEC-34
> Project: Commons Exec
> Issue Type: Bug
> Environment: Windows Vista 64bit, dual core CPU
>Reporter: Marco Ferrante
>Assignee: Siegfried Goeschl
>Priority: Minor
>
> Consider this test case (in _DefaultExecutorTest_ class):
> {noformat}
> /**
> * Start a async process using a stream handler and terminate it manually
> * before the watchdog timeout occurs
> */
> public void testExecuteAsyncWithStreamHandlerAndUserTermination() throws
> Exception {
> CommandLine cl = new CommandLine(foreverTestScript);
> ExecuteWatchdog watchdog = new ExecuteWatchdog(Integer.MAX_VALUE);
> PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
> System.err);
> exec.setStreamHandler(streamHanlder);
> MockExecuteResultHandler handler = new MockExecuteResultHandler();
> exec.execute(cl, handler);
> // DON'T wait for script to run
> //Thread.sleep(2000);
> // teminate it
> watchdog.destroyProcess();
> assertTrue("Watchdog should have killed the
> process",watchdog.killedProcess());
> }
> {noformat}
> It fails (at least in my environment) because when
> _watchdog.destroyProcess()_ is invoked the external process is not bound to
> the watchdog yet.
> Although there are possible several workarounds, but all of them seem to me
> very intrusive in the code. So, I prefer some discussion before preparing and
> submitting a patch.
> IMHO, the watchdog should handle a reference to the thread running the
> process, not to the process itself. In this way, interrupting signals can be
> transport using default _interrupt()_ method of class _Thread_.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
