[jira] [Commented] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes
[ https://issues.apache.org/jira/browse/OGNL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481192#comment-13481192 ] Lukasz Lenart commented on OGNL-224: I will merge it to OGNL git source and prepare a new version. Performance - Locking and performance problem with OgnlRuntime.findParameterTypes - Key: OGNL-224 URL: https://issues.apache.org/jira/browse/OGNL-224 Project: Commons OGNL Issue Type: Improvement Components: Core Runtime Affects Versions: 3.0 Reporter: Pelladi Gabor Priority: Minor Labels: patch, perfomance Attachments: OGNL-224.patch, OgnlRuntimeTest.java I am using struts2 and under heavy load (around 100 threads) many threads are in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we use have a generic superclass like: public class PersonalCaptureAction extends DataCaptureActionPersonalDTO OGNL handles this very bad, it enters synchronized (_genericMethodParameterTypesCache) all the time, at every property access of the Action. A possible workaround is to introduce another layer of superclass that is not generic. I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git tree I found: https://github.com/jkuhnert/ognl I will attach a patch and a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes
[ https://issues.apache.org/jira/browse/OGNL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481194#comment-13481194 ] Lukasz Lenart commented on OGNL-224: Or could you prepare a pull request ? Performance - Locking and performance problem with OgnlRuntime.findParameterTypes - Key: OGNL-224 URL: https://issues.apache.org/jira/browse/OGNL-224 Project: Commons OGNL Issue Type: Improvement Components: Core Runtime Affects Versions: 3.0 Reporter: Pelladi Gabor Assignee: Lukasz Lenart Priority: Minor Labels: patch, perfomance Attachments: OGNL-224.patch, OgnlRuntimeTest.java I am using struts2 and under heavy load (around 100 threads) many threads are in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we use have a generic superclass like: public class PersonalCaptureAction extends DataCaptureActionPersonalDTO OGNL handles this very bad, it enters synchronized (_genericMethodParameterTypesCache) all the time, at every property access of the Action. A possible workaround is to introduce another layer of superclass that is not generic. I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git tree I found: https://github.com/jkuhnert/ognl I will attach a patch and a testcase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-244) prunsrv does not propagate exit code
[ https://issues.apache.org/jira/browse/DAEMON-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-244. Resolution: Fixed Fix Version/s: 1.0.11 Patch applied. Thanks! prunsrv does not propagate exit code Key: DAEMON-244 URL: https://issues.apache.org/jira/browse/DAEMON-244 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.10 Environment: MS Windows Reporter: Peter Ehrbar Assignee: Mladen Turk Fix For: 1.0.11 Attachments: exit_code_patch_on_1_0_10.txt, exit_code_patch_on_1_0_10-u.txt In order to perform recovery actions (e.g. restart service) the Windows Service Controller needs to detect abnormal program terminations (failures). The Service controller detects a failure if either the service process crashes or the process terminates with a non-zero exit code. For my Java server application I want to define recovery actions for the following conditions: 1) VM crash 2) Error was thrown (e.g. OutOfMemoryError) 3) System.exit() with non-zero exit code When using prunsrv as a wrapper, I observe the following behaviour: 1) VM crash is detected only when StartMode=jvm, otherwise the Service Controller ignores the failure situation 2) When an Error is thrown and StartMode=jvm, prunsrv does not terminate but seems to hang. Therefore, the Service Controller is not aware of the failure. For other StartModes, prunsrv terminates, but the Service Controller does not detect the failure. 3) When System.exit(42) is called, prunsrv terminates but the Service Controller does not detect the non-zero exit code. This applies for all StartModes. It seems to me as if prunsrv always terminates with exit code zero. But I expect the following behaviour: 1) VM crash with StartMode=jvm - OK as it is now, but with other StartModes, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. 2) When an Error is thrown, prunsrv should terminate with a non-zero exit code in order to indicate the abnormal termination. 3) When System.exit() is called, prunsrv should terminate with the exit code passed to System.exit() (transparent behaviour), in order to let the application indicate a failure situation. With the current behaviour, it is not possible to let the Windows Service Controller perform recovery actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-243) Support for Failure Recovery
[ https://issues.apache.org/jira/browse/DAEMON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk updated DAEMON-243: --- Priority: Minor (was: Major) Support for Failure Recovery Key: DAEMON-243 URL: https://issues.apache.org/jira/browse/DAEMON-243 Project: Commons Daemon Issue Type: New Feature Components: Procrun Affects Versions: 1.0.10 Environment: MS Windows Reporter: Peter Ehrbar Priority: Minor The MS Windows Service Controller provides functionality to perform some basic failure recovery actions: Restart service or execute any command or restart the machine. This can be configured using the Service Controller GUI or in a shell with SC.EXE (commands FAILURE and FAILUREFLAG). It would be convenient if this could be configured also using procrun. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-243) Support for Failure Recovery
[ https://issues.apache.org/jira/browse/DAEMON-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481206#comment-13481206 ] Mladen Turk commented on DAEMON-243: I have lowered down the priority of this issue to minor since there is a solution which can be used. So if you wish to have this supported better write some code :) Support for Failure Recovery Key: DAEMON-243 URL: https://issues.apache.org/jira/browse/DAEMON-243 Project: Commons Daemon Issue Type: New Feature Components: Procrun Affects Versions: 1.0.10 Environment: MS Windows Reporter: Peter Ehrbar Priority: Minor The MS Windows Service Controller provides functionality to perform some basic failure recovery actions: Restart service or execute any command or restart the machine. This can be configured using the Service Controller GUI or in a shell with SC.EXE (commands FAILURE and FAILUREFLAG). It would be convenient if this could be configured also using procrun. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-246) jsvc fails to load libcap.so.2 from /lib64
[ https://issues.apache.org/jira/browse/DAEMON-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-246. Resolution: Fixed Fix Version/s: 1.0.11 Patch applied. Thanks! jsvc fails to load libcap.so.2 from /lib64 -- Key: DAEMON-246 URL: https://issues.apache.org/jira/browse/DAEMON-246 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.10 Environment: Fedora Core 16 (x86_64, using an x86_64 jsvc), CentOS 5.5 (x86_86, using an x86_64 jsvc), Debian Squeeze (x86_64, using an i686 jsvc), Debian Wheezy (x86_64, using an i686 jsvc) Reporter: Emily Middleton Fix For: 1.0.11 Attachments: patch.txt I see this when running jsvc -debug ... Attemtping to load library /lib/libcap.so.2 Attemtping to load library /lib/libcap.so.1 Attemtping to load library /lib/libcap.so Attemtping to load library /usr/lib/libcap.so.2 Attemtping to load library /usr/lib/libcap.so.1 Attemtping to load library /usr/lib/libcap.so failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared object file: No such file or directory. This does not work on 64bit Fedora, as the lib directory is /lib64/. It also won't work if you're using a 32bit copy of jsvc on a 64bit copy of Debian, which has a similar problem (the 32bit copy of libcap.so.2 is found at /lib32/libcap.so.2). These alternative library locations are mentioned in the Linux filesystem hierarchy standard (http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL). The hard-coded /lib and /usr/lib paths in jsvc are counter-productive in the environments mentioned, and also in environments where the user expects to be able to control the library search path with the LD_LIBRARY_PATH environment variable. jsvc should be utilising the normal ld.so search path. This can be achieved even with a desire to be able to load either version 1 or 2 of libcap (as requested in https://issues.apache.org/jira/browse/DAEMON-234) because you don't need to give a full path to dlopen, according to its man page on Linux: If filename contains a slash (/), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows ... (see ld.so(8) for further details) So the issue can be resolved by simply making libcap_locs contain the desired filenames rather than pathnames. Patch will be attached shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-245) Support privilege escalation on Windows (UAC)
[ https://issues.apache.org/jira/browse/DAEMON-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-245. Resolution: Fixed Fix Version/s: 1.0.11 Added slightly modified prunsrv.manifest which should do the trick. Not sure if Commons-Controls dependency is needed or not. Thanks! Support privilege escalation on Windows (UAC) - Key: DAEMON-245 URL: https://issues.apache.org/jira/browse/DAEMON-245 Project: Commons Daemon Issue Type: New Feature Components: Procrun Affects Versions: 1.0.10 Environment: Windows Vista+ Reporter: Rainer Jung Fix For: 1.0.11 Windows introduced User Access Control which limits things users can do even if they are logged in as administrators. Management of services is one of those things. Usually the recommendation was to switch the UAC feature off, but it is not to hard to support UAC for procrun. Any binary can include information about a needed privilege escalation. If you start such a binary, the usualy Windows confirmation popup of UAC will show and you can confirm the operation. To support this, the manifest included in the exe files need to be enhanced. The following is an example for prunsrv: ?xml version=1.0 encoding=UTF-8 standalone=yes? assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 assemblyIdentity version=3.1.0.0 processorArchitecture=* name=Apache.Procrun.Prunsrv type=win32/assemblyIdentity descriptionApache Procrun Service Manager/description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=* publicKeyToken=6595b64144ccf1df language=*/assemblyIdentity /dependentAssembly /dependency trustInfo xmlns=urn:schemas-microsoft-com:asm.v3 security requestedPrivileges requestedExecutionLevel level=requireAdministrator uiAccess=false/requestedExecutionLevel /requestedPrivileges /security /trustInfo /assembly I used this manifest and the same one with the string Prunsrv replaced by Prunmgr successfully on Windows 7. I do not know, whether such an extended manifest has negative cnsequences on older Windows. If accepted, the manifest should be added to both binaries. Currently only one of them contains a manifest. Regards, Rainer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-226) Race condition with OgnlRuntime.getMethod
[
https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johno Crawford updated OGNL-226:
Attachment: OgnlRuntimeTest.java
Attaching test case, if you run it a few times it should yield the following
exception..
{code}
Exception in thread main java.lang.AssertionError: expected:true but
was:false
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at OgnlRuntimeTest.runTest(OgnlRuntimeTest.java:32)
at OgnlRuntimeTest.main(OgnlRuntimeTest.java:22)
{code}
Race condition with OgnlRuntime.getMethod
-
Key: OGNL-226
URL: https://issues.apache.org/jira/browse/OGNL-226
Project: Commons OGNL
Issue Type: Bug
Components: Core Runtime
Affects Versions: 3.0
Reporter: Johno Crawford
Priority: Minor
Attachments: OgnlRuntimeTest.java
If there are two consecutive calls to OgnlRuntime.getMethod before the result
is cached it may erroneously return null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IMAGING-90) ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
[
https://issues.apache.org/jira/browse/IMAGING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481338#comment-13481338
]
Stefan Huber commented on IMAGING-90:
-
Sorry for the late update - I haven't received any notification about the
comment. Unfortunately I can not provide a sample image at the moment as they
do not belong to me. Sorry about that.
ClassCastException: [I cannot be cast to java.lang.Number in
TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
--
Key: IMAGING-90
URL: https://issues.apache.org/jira/browse/IMAGING-90
Project: Commons Imaging
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 1.0
Environment: jdk 1.6.0_33
Reporter: Stefan Huber
Version 1.0 rc2. (Checked the trunk, but couldn't find any commits concerning
this issue)
When calling Imaging.getImageInfo on certain (in this case jpeg) images,
there might be a ClassCastException in TiffReader:239 if the entry is not a
Number.
{code}
int subDirectoryOffset = ((Number) entry.getValue())
.intValue();
{code}
This may occur if the entry does not have any actual value. This is the entry
shown by the debugger:
{code}
40965 (0xa005: InteropOffset): (0 Long)
{code}
A quick solution to this problem might be to check if entry.getValue() could
be cast to a Number before doing so. Probably there is a more elegant way,
but I haven't had the time to analyze this thoroughly.
Here is the stack trace:
{code}
Caused by: java.lang.ClassCastException: [I cannot be cast to java.lang.Number
at
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:239)
at
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:253)
at
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
at
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:95)
at
org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:419)
at
org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:410)
at
org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:132)
at
org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:203)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:335)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:295)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:668)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:683)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:615)
{code}
The same issue applies to similar uses of TiffField, for instance
JpegImageParser around line 676.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OGNL-226) Race condition with OgnlRuntime.getMethod
[
https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481339#comment-13481339
]
Johno Crawford edited comment on OGNL-226 at 10/22/12 12:43 PM:
Attaching test case, if you run it a few times it should yield the following
exception..
Exception in thread main java.lang.AssertionError: expected:true but
was:false
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at OgnlRuntimeTest.runTest(OgnlRuntimeTest.java:32)
at OgnlRuntimeTest.main(OgnlRuntimeTest.java:22)
was (Author: johno):
Attaching test case, if you run it a few times it should yield the
following exception..
{code}
Exception in thread main java.lang.AssertionError: expected:true but
was:false
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at OgnlRuntimeTest.runTest(OgnlRuntimeTest.java:32)
at OgnlRuntimeTest.main(OgnlRuntimeTest.java:22)
{code}
Race condition with OgnlRuntime.getMethod
-
Key: OGNL-226
URL: https://issues.apache.org/jira/browse/OGNL-226
Project: Commons OGNL
Issue Type: Bug
Components: Core Runtime
Affects Versions: 3.0
Reporter: Johno Crawford
Priority: Minor
Attachments: OgnlRuntimeTest.java
If there are two consecutive calls to OgnlRuntime.getMethod before the result
is cached it may erroneously return null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OGNL-226) Race condition with OgnlRuntime.getMethod
[ https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481339#comment-13481339 ] Johno Crawford edited comment on OGNL-226 at 10/22/12 12:46 PM: Attaching test case, if you run it several times it should yield the following exception (maybe 1 in 15 if you are unlucky).. Exception in thread main java.lang.AssertionError: expected:true but was:false at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at OgnlRuntimeTest.runTest(OgnlRuntimeTest.java:32) at OgnlRuntimeTest.main(OgnlRuntimeTest.java:22) was (Author: johno): Attaching test case, if you run it a few times it should yield the following exception.. Exception in thread main java.lang.AssertionError: expected:true but was:false at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at OgnlRuntimeTest.runTest(OgnlRuntimeTest.java:32) at OgnlRuntimeTest.main(OgnlRuntimeTest.java:22) Race condition with OgnlRuntime.getMethod - Key: OGNL-226 URL: https://issues.apache.org/jira/browse/OGNL-226 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Affects Versions: 3.0 Reporter: Johno Crawford Priority: Minor Attachments: OgnlRuntimeTest.java If there are two consecutive calls to OgnlRuntime.getMethod before the result is cached it may erroneously return null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-671) EmpiricalDistribution(Impl) should support a pluggable kernel
[ https://issues.apache.org/jira/browse/MATH-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-671: Fix Version/s: (was: 3.1) 3.2 EmpiricalDistribution(Impl) should support a pluggable kernel - Key: MATH-671 URL: https://issues.apache.org/jira/browse/MATH-671 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 3.2 The normal distribution used to sample data within bins should be pluggable, replaceable by any distribution that can be parameterized by a StatisticalSummary. Adding a protected getKernel(StatisticalSummary) that defaults to provide a normal distribution will enable this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-672) EmpiricalDistribution(Impl) should implement the Distribution interface
[ https://issues.apache.org/jira/browse/MATH-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-672: Fix Version/s: (was: 3.1) 3.2 EmpiricalDistribution(Impl) should implement the Distribution interface --- Key: MATH-672 URL: https://issues.apache.org/jira/browse/MATH-672 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 3.2 To compute cumulative probability at a point x if no data have been loaded, throw IllegalStateException if x is below the global min, return 0 if x is above the global max, return 1 otherwise find the bin that x belongs to, sum the probabilities of the bins below x's bin and use the configured kernel to compute how much of the containing bin's mass should be added the total -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-803) Bugs in RealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-803:
Affects Version/s: (was: 4.0)
3.0
Bugs in RealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
Key: MATH-803
URL: https://issues.apache.org/jira/browse/MATH-803
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Fix For: 4.0
{{OpenMapRealVector.ebeMultiply(RealVector)}} and
{{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
understand. Here is the current implementation of {{ebeMultiply}}
{code:java}
public OpenMapRealVector ebeMultiply(RealVector v) {
checkVectorDimensions(v.getDimension());
OpenMapRealVector res = new OpenMapRealVector(this);
Iterator iter = entries.iterator();
while (iter.hasNext()) {
iter.advance();
res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
}
return res;
}
{code}
The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
not true. The bug is easy enough to identify, but more complex to solve. The
only solution I can come up with is to loop through *all* entries of v
(instead of those entries which correspond to non-zero entries of this). I'm
afraid about performance losses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-803) Bugs in RealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-803:
Fix Version/s: 4.0
Bugs in RealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
Key: MATH-803
URL: https://issues.apache.org/jira/browse/MATH-803
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Fix For: 4.0
{{OpenMapRealVector.ebeMultiply(RealVector)}} and
{{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
understand. Here is the current implementation of {{ebeMultiply}}
{code:java}
public OpenMapRealVector ebeMultiply(RealVector v) {
checkVectorDimensions(v.getDimension());
OpenMapRealVector res = new OpenMapRealVector(this);
Iterator iter = entries.iterator();
while (iter.hasNext()) {
iter.advance();
res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
}
return res;
}
{code}
The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
not true. The bug is easy enough to identify, but more complex to solve. The
only solution I can come up with is to loop through *all* entries of v
(instead of those entries which correspond to non-zero entries of this). I'm
afraid about performance losses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-819) SimplexSolver - InfeasibleSolution when feasible
[ https://issues.apache.org/jira/browse/MATH-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-819: Fix Version/s: 3.2 SimplexSolver - InfeasibleSolution when feasible Key: MATH-819 URL: https://issues.apache.org/jira/browse/MATH-819 Project: Commons Math Issue Type: Bug Affects Versions: 3.1 Environment: Windows 7, JDK 1.7.0_03 Reporter: Raghu Rangarajan Assignee: Thomas Neidhart Fix For: 3.2 Attachments: CommonsSolver2.java, lp-octave.txt, test.log, test.mod, test.out I am seeing an odd behavior with the latest code in the main trunk (Directory revision: 1358535). The solver throws NoFeasibleSolutionException for a problem which has a feasible solution. Just by commenting out the last constraint, we get a feasible solution. And for that solution, the constraint in question does not seem to be playing a role. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-738) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b
[ https://issues.apache.org/jira/browse/MATH-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-738: Affects Version/s: (was: 4.0) (was: 3.1) 3.0 Fix Version/s: 4.0 3.1 Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b Key: MATH-738 URL: https://issues.apache.org/jira/browse/MATH-738 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Labels: special-functions Fix For: 3.1, 4.0 This was first reported in MATH-718. The result of the current implementation of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are large-ish. I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], GSL, [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html] as well as NR. At first sight, neither uses the same method to compute this function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the best option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481377#comment-13481377 ] Gilles commented on MATH-757: - What's the status of this issue? Is the class in a consistent state? Should this class really be advertized as thread-safe? Primarily, it's a utility for CM's internal use; currently, it's used in * ExponentialDistribution (as a local variable used only at class initialization) * DescriptiveStatistics (as a private field) with no need of thread-safety. If the answer to the above is no, could we just drop all synchronized keywords and be done with this issue? ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-758) Fields which could be private and/or final
[ https://issues.apache.org/jira/browse/MATH-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-758: Fix Version/s: 4.0 Fields which could be private and/or final -- Key: MATH-758 URL: https://issues.apache.org/jira/browse/MATH-758 Project: Commons Math Issue Type: Bug Reporter: Sebb Fix For: 4.0 BaseAbstractUnivariateIntegrator has several fields that are not currently changed after construction and could be final: protected double absoluteAccuracy; protected double relativeAccuracy; protected int minimalIterationCount; protected Incrementor iterations; protected Incrementor evaluations; These all have getters as well, so could also be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-759) ListUnivariateImpl does not always access windowSize using synch.
[ https://issues.apache.org/jira/browse/MATH-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-759: Fix Version/s: 3.1 It seems that this issue can be resolved. Please confirm. ListUnivariateImpl does not always access windowSize using synch. - Key: MATH-759 URL: https://issues.apache.org/jira/browse/MATH-759 Project: Commons Math Issue Type: Bug Reporter: Sebb Priority: Minor Fix For: 3.1 ListUnivariateImpl has two synch. methods: getWindowSize setWindowSize However, windowSize is frequently referenced elsewhere without synch. It's not clear why the methods need synch., but if there is a need, then windowSize should always be read using synch. The code should use the super-class getter and setter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-788) Complex bug with NaN: the operation new Complex(0.0).multiply(new Complex(Double.POSITIVE_INFINITY)) gives (Infinity, Infinity) instead of NaN
[ https://issues.apache.org/jira/browse/MATH-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-788. - Resolution: Won't Fix Older discussions concluded that this won't be fixed in the Complex class as it currently exists in Commons Math. We are open to have other implementations (where the result of some operation may be more consistent with other conventions or standards), as outlined in MATH-667. Complex bug with NaN: the operation new Complex(0.0).multiply(new Complex(Double.POSITIVE_INFINITY)) gives (Infinity, Infinity) instead of NaN -- Key: MATH-788 URL: https://issues.apache.org/jira/browse/MATH-788 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Stanislav Poslavsky Priority: Minor Labels: patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-757: Fix Version/s: 3.1 ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb Fix For: 3.1 ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-672) EmpiricalDistribution(Impl) should implement the Distribution interface
[ https://issues.apache.org/jira/browse/MATH-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481393#comment-13481393 ] Phil Steitz commented on MATH-672: -- I have this coded, am just finishing tests. I may be able to get it in for 3.1, if MATH-878 does not take me too long. I am OK waiting on this one though if we are ready to roll 3.1 EmpiricalDistribution(Impl) should implement the Distribution interface --- Key: MATH-672 URL: https://issues.apache.org/jira/browse/MATH-672 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 3.2 To compute cumulative probability at a point x if no data have been loaded, throw IllegalStateException if x is below the global min, return 0 if x is above the global max, return 1 otherwise find the bin that x belongs to, sum the probabilities of the bins below x's bin and use the configured kernel to compute how much of the containing bin's mass should be added the total -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods
[ https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481395#comment-13481395 ] Phil Steitz commented on MATH-757: -- +1 to just drop the syncs. ResizableDoubleArray is not thread-safe yet has some synch. methods --- Key: MATH-757 URL: https://issues.apache.org/jira/browse/MATH-757 Project: Commons Math Issue Type: Bug Reporter: Sebb Fix For: 3.1 ResizableDoubleArray has several synchronised methods, but is not thread-safe, because class variables are not always accessed using the lock. Is the class supposed to be thread-safe? If so, all accesses (read and write) need to be synch. If not, the synch. qualifiers could be dropped. In any case, the protected fields need to be made private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-880) Polygon difference produces erronious results in some cases
[
https://issues.apache.org/jira/browse/MATH-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481399#comment-13481399
]
Luc Maisonobe commented on MATH-880:
Well, the remaining problem is worse than expected. The current version even
fails on the simplistic following case:
{code}
Vector2D[] vertices = new Vector2D[] {
new Vector2D(-6, -4), new Vector2D(-8, -8), new Vector2D( 8, -8),
new Vector2D( 6, -4), new Vector2D(10, 4), new Vector2D(-10, 4)
};
PolygonsSet set = new PolygonsSet(1.0e-10, vertices);
{code}
Still working on it :-(
Polygon difference produces erronious results in some cases
---
Key: MATH-880
URL: https://issues.apache.org/jira/browse/MATH-880
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Curtis Jensen
Fix For: 3.1
Attachments: PolygonDiffAll.png, PolygonDiffResults.png,
PolygonInputs.png
The 2D polygon difference method is returning incorrect
results. Below is a test case of subtracting two polygons (Sorry,
this is the simplest case that I could find that duplicates the
problem).
There are three problems with the result. The first is that the first
point of the first set of vertices is null (and the first point of the
second set is also null). The second is that, even if the first null
points are ignored, the returned polygon is not the correct result.
The first and last points are way off, and the remaining points do not
match the original polygon boundaries. Additionally, there are two
holes that are returned in the results. This subtraction case should
not have holes.
{code:title=Complex Polygon Difference Test}
public void testComplexDifference() {
Vector2D[][] vertices1 = new Vector2D[][] {
new Vector2D[] {
new Vector2D( 90.08714908223715, 38.370299337260235),
new Vector2D( 90.08709517675004, 38.3702895991413),
new Vector2D( 90.08401538704919, 38.368849330127944),
new Vector2D( 90.08258210430711, 38.367634558585564),
new Vector2D( 90.08251455106665, 38.36763409247078),
new Vector2D( 90.08106599752608, 38.36761621664249),
new Vector2D( 90.08249585300035, 38.36753627557965),
new Vector2D( 90.09075743352184, 38.35914647644972),
new Vector2D( 90.09099945896571, 38.35896264724079),
new Vector2D( 90.09269383800086, 38.34595756121246),
new Vector2D( 90.09638631543191, 38.3457988093121),
new Vector2D( 90.09666417351019, 38.34523360999418),
new Vector2D( 90.1297082145872, 38.337670454923625),
new Vector2D( 90.12971687748956, 38.337669827794684),
new Vector2D( 90.1240820219179, 38.34328502001131),
new Vector2D( 90.13084259656404, 38.34017811765017),
new Vector2D( 90.13378567942857, 38.33860579180606),
new Vector2D( 90.13519557833206, 38.33621054663689),
new Vector2D( 90.13545616732307, 38.33614965452864),
new Vector2D( 90.13553111202748, 38.33613962818305),
new Vector2D( 90.1356903436448, 38.33610227127048),
new Vector2D( 90.13576283227428, 38.33609255422783),
new Vector2D( 90.13595870833188, 38.33604606376991),
new Vector2D( 90.1361556630693, 38.3360024198866),
new Vector2D( 90.13622408795709, 38.335987048115726),
new Vector2D( 90.1369618904, 38.33581914328681),
new Vector2D( 90.13746655304897, 38.33616706665265),
new Vector2D( 90.13845973716064, 38.33650776167099),
new Vector2D( 90.13950901827667, 38.3368469456463),
new Vector2D( 90.14393814424852, 38.337591835857495),
new Vector2D( 90.14483839716831, 38.337076122362475),
new Vector2D( 90.14565474433601, 38.33769000964429),
new Vector2D( 90.14569421179482, 38.3377117256905),
new Vector2D( 90.14577067124333, 38.33770883625908),
new Vector2D( 90.14600350631684, 38.337714326520995),
new Vector2D( 90.14600355139731, 38.33771435193319),
new Vector2D( 90.14600369112401, 38.33771443882085),
new Vector2D( 90.14600382486884, 38.33771453466096),
new Vector2D( 90.14600395205912, 38.33771463904344),
new Vector2D( 90.14600407214999,
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481477#comment-13481477 ] Charles Honton commented on LANG-769: - What's the semantic difference between NotImplementedException and java.lang.UnsupportedOperationException? Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Components: lang.exception.* Reporter: david cogen Priority: Minor Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, This exception supplements the standard exception classes by providing a more semantically rich description of the problem. Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXEC-68) Watchdog kills process immediately if timeout is too large
Joel McCance created EXEC-68:
Summary: Watchdog kills process immediately if timeout is too large
Key: EXEC-68
URL: https://issues.apache.org/jira/browse/EXEC-68
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1, 1.1.1
Environment: Should exist for all platforms, but specifically
identified on Windows 7.
Reporter: Joel McCance
Priority: Minor
When using the ExecuteWatchdog with a very large timeout (e.g.,
Long.MAX_VALUE), the Watchdog immediately destroys the process instead of
waiting for the duration of the timeout. For example, the following code
snippet would continue immediately:
{code}
DefaultExecutor executor = new DefaultExecutor();
ExecuteWatchdog watchdog = new ExecuteWatchdog(Long.MAX_VALUE);
executor.setWatchdog(watchdog);
executor.execute(cmd); // Where `cmd` could be any valid command.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (EXEC-68) Watchdog kills process immediately if timeout is too large
[
https://issues.apache.org/jira/browse/EXEC-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481509#comment-13481509
]
Joel McCance edited comment on EXEC-68 at 10/22/12 5:17 PM:
Bug is a result of the current timeout polling loop relying on being able to
add the current system time to the timeout without it overflowing. With very
large timeout values, the sum of these two items overflows, so the polling loop
exits immediately.
Attached patch changes behavior of Watchdog#run() so that it does not have to
add the current millis time to the timeout, as well as a regression test for
DefaultExecutorTest to reproduce the bug should it recur.
was (Author: jmccance):
Bug is a result of the current timeout polling loop relying on being able
to add the current system time to the timeout without it overflowing. With very
large timeout values, the sum of these two items overflows, so the polling loop
exits immediately.
Attached patch changes behavior of Watchdog#run() so that it does not have to
add the current millis time to the timeout.
Watchdog kills process immediately if timeout is too large
--
Key: EXEC-68
URL: https://issues.apache.org/jira/browse/EXEC-68
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1, 1.1.1
Environment: Should exist for all platforms, but specifically
identified on Windows 7.
Reporter: Joel McCance
Priority: Minor
Attachments: EXEC-68.patch
When using the ExecuteWatchdog with a very large timeout (e.g.,
Long.MAX_VALUE), the Watchdog immediately destroys the process instead of
waiting for the duration of the timeout. For example, the following code
snippet would continue immediately:
{code}
DefaultExecutor executor = new DefaultExecutor();
ExecuteWatchdog watchdog = new ExecuteWatchdog(Long.MAX_VALUE);
executor.setWatchdog(watchdog);
executor.execute(cmd); // Where `cmd` could be any valid command.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-759) ListUnivariateImpl does not always access windowSize using synch.
[ https://issues.apache.org/jira/browse/MATH-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-759. -- Resolution: Fixed I can confirm that the issue can be closed. ListUnivariateImpl does not always access windowSize using synch. - Key: MATH-759 URL: https://issues.apache.org/jira/browse/MATH-759 Project: Commons Math Issue Type: Bug Reporter: Sebb Priority: Minor Fix For: 3.1 ListUnivariateImpl has two synch. methods: getWindowSize setWindowSize However, windowSize is frequently referenced elsewhere without synch. It's not clear why the methods need synch., but if there is a need, then windowSize should always be read using synch. The code should use the super-class getter and setter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXEC-68) Watchdog kills process immediately if timeout is too large
[
https://issues.apache.org/jira/browse/EXEC-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved EXEC-68.
-
Resolution: Fixed
Fix Version/s: 1.1.1
commit -m [EXEC-68] Watchdog kills process immediately if timeout is too
large.
C:/svn/org/apache/commons/trunks-proper/exec/src/test/java/org/apache/commons/exec/DefaultExecutorTest.java
C:/svn/org/apache/commons/trunks-proper/exec/src/main/java/org/apache/commons/exec/Watchdog.java
C:/svn/org/apache/commons/trunks-proper/exec/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/exec/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/exec/src/main/java/org/apache/commons/exec/Watchdog.java
Sending
C:/svn/org/apache/commons/trunks-proper/exec/src/test/java/org/apache/commons/exec/DefaultExecutorTest.java
Transmitting file data ...
Committed revision 1401016.
Watchdog kills process immediately if timeout is too large
--
Key: EXEC-68
URL: https://issues.apache.org/jira/browse/EXEC-68
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1, 1.1.1
Environment: Should exist for all platforms, but specifically
identified on Windows 7.
Reporter: Joel McCance
Priority: Minor
Fix For: 1.1.1
Attachments: EXEC-68.patch
When using the ExecuteWatchdog with a very large timeout (e.g.,
Long.MAX_VALUE), the Watchdog immediately destroys the process instead of
waiting for the duration of the timeout. For example, the following code
snippet would continue immediately:
{code}
DefaultExecutor executor = new DefaultExecutor();
ExecuteWatchdog watchdog = new ExecuteWatchdog(Long.MAX_VALUE);
executor.setWatchdog(watchdog);
executor.execute(cmd); // Where `cmd` could be any valid command.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-880) Polygon difference produces erronious results in some cases
[
https://issues.apache.org/jira/browse/MATH-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-880.
Resolution: Fixed
Fixed in subversion repository as of r1401022.
Note that the unit test corresponding to the issue uses a value equal to 1.0e-8
for the hyperplaneThickness parameter. Smaller values do not work due to
numerical issues. This new parameter is therefore an important one for such
problems and too small values should be avoided.
There are no definitive value that can be suggested and would work in every
case. The appropriate value depends on the polygon (does it have thin pikes or
dents, does it have vertices with almost flat angles, does it have independent
edges that happen to be almost aligned despite they are not directly connected
..).
Thanks for reporting the problem.
Polygon difference produces erronious results in some cases
---
Key: MATH-880
URL: https://issues.apache.org/jira/browse/MATH-880
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Curtis Jensen
Fix For: 3.1
Attachments: PolygonDiffAll.png, PolygonDiffResults.png,
PolygonInputs.png
The 2D polygon difference method is returning incorrect
results. Below is a test case of subtracting two polygons (Sorry,
this is the simplest case that I could find that duplicates the
problem).
There are three problems with the result. The first is that the first
point of the first set of vertices is null (and the first point of the
second set is also null). The second is that, even if the first null
points are ignored, the returned polygon is not the correct result.
The first and last points are way off, and the remaining points do not
match the original polygon boundaries. Additionally, there are two
holes that are returned in the results. This subtraction case should
not have holes.
{code:title=Complex Polygon Difference Test}
public void testComplexDifference() {
Vector2D[][] vertices1 = new Vector2D[][] {
new Vector2D[] {
new Vector2D( 90.08714908223715, 38.370299337260235),
new Vector2D( 90.08709517675004, 38.3702895991413),
new Vector2D( 90.08401538704919, 38.368849330127944),
new Vector2D( 90.08258210430711, 38.367634558585564),
new Vector2D( 90.08251455106665, 38.36763409247078),
new Vector2D( 90.08106599752608, 38.36761621664249),
new Vector2D( 90.08249585300035, 38.36753627557965),
new Vector2D( 90.09075743352184, 38.35914647644972),
new Vector2D( 90.09099945896571, 38.35896264724079),
new Vector2D( 90.09269383800086, 38.34595756121246),
new Vector2D( 90.09638631543191, 38.3457988093121),
new Vector2D( 90.09666417351019, 38.34523360999418),
new Vector2D( 90.1297082145872, 38.337670454923625),
new Vector2D( 90.12971687748956, 38.337669827794684),
new Vector2D( 90.1240820219179, 38.34328502001131),
new Vector2D( 90.13084259656404, 38.34017811765017),
new Vector2D( 90.13378567942857, 38.33860579180606),
new Vector2D( 90.13519557833206, 38.33621054663689),
new Vector2D( 90.13545616732307, 38.33614965452864),
new Vector2D( 90.13553111202748, 38.33613962818305),
new Vector2D( 90.1356903436448, 38.33610227127048),
new Vector2D( 90.13576283227428, 38.33609255422783),
new Vector2D( 90.13595870833188, 38.33604606376991),
new Vector2D( 90.1361556630693, 38.3360024198866),
new Vector2D( 90.13622408795709, 38.335987048115726),
new Vector2D( 90.1369618904, 38.33581914328681),
new Vector2D( 90.13746655304897, 38.33616706665265),
new Vector2D( 90.13845973716064, 38.33650776167099),
new Vector2D( 90.13950901827667, 38.3368469456463),
new Vector2D( 90.14393814424852, 38.337591835857495),
new Vector2D( 90.14483839716831, 38.337076122362475),
new Vector2D( 90.14565474433601, 38.33769000964429),
new Vector2D( 90.14569421179482, 38.3377117256905),
new Vector2D( 90.14577067124333, 38.33770883625908),
new Vector2D( 90.14600350631684, 38.337714326520995),
new Vector2D( 90.14600355139731, 38.33771435193319),
new
[jira] [Commented] (MATH-816) Multivariate Normal Mixture Models
[ https://issues.apache.org/jira/browse/MATH-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13481986#comment-13481986 ] Jared Becksfort commented on MATH-816: -- Gilles, I just got back in town. I will try to modify the test tomorrow and submit. Jared Multivariate Normal Mixture Models -- Key: MATH-816 URL: https://issues.apache.org/jira/browse/MATH-816 Project: Commons Math Issue Type: New Feature Reporter: Jared Becksfort Priority: Minor Fix For: 3.2 Attachments: MixtureMultivariateRealDistribution.java, MixtureMultivariateRealDistribution.java, MultivariateNormalMixtureModelDistribution.java, MultivariateNormalMixtureModelDistributionTest.java Original Estimate: 1m Remaining Estimate: 1m I will submit a class for Multivariate Normal Mixture Models. Not sure it will allow sampling initially. Hello, I have implemented some classes for multivariate Normal distributions, multivariate normal mixture models, and an expectation maximization fitting class for the mixture model. I would like to submit it to Apache Commons Math. I still have some touching up to do so that they fit the style guidelines and implement the correct interfaces. Before I do so, I thought I would at least ask if the developers of the project are interested in me submitting them. Thanks, Jared Becksfort Dear Jared, Yes, that would be very nice to have such an addition! Remember to also include unit tests (refer to the current ones for examples). The best would be to split a submission up into multiple minor ones, each covering a natural submission (e.g. multivariate Normal distribution in one submission), and create an issue as described at http://commons.apache.org/math/issue-tracking.html . If you run into any problems, please do not hesitate to ask on this mailing list. Cheers, Mikkel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482036#comment-13482036 ] Sebb commented on LANG-769: --- The Javadoc for UnsupportedOperationException says: bq. Thrown to indicate that the requested operation is not supported. It does not imply that the operation cannot be implemented. Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Components: lang.exception.* Reporter: david cogen Priority: Minor Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, This exception supplements the standard exception classes by providing a more semantically rich description of the problem. Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482109#comment-13482109
]
Gary D. Gregory commented on VFS-440:
-
Thank you for the patch and sorry it has taken me so long to take a look.
I just started to review the patch, but it would be helpful if it did NOT
contain ANY formatting changes. That makes the while process take longer. So,
if you can attach a patch that contains the semantic changes only, this will
all go faster.
One thing that I noticed in private static void connect(String name, final
InputStream in, final OutputStream out, final ExitCallback callback):
+catch (SshException ex)
+{
+
+}
That's probably not great unless I am missing something.
Also, do not hesitate to comment the code some more, that helps too :)
Thank you,
Gary
[SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
-
Key: VFS-440
URL: https://issues.apache.org/jira/browse/VFS-440
Project: Commons VFS
Issue Type: Improvement
Reporter: Benjamin Piwowarski
Priority: Minor
Labels: proxy, sftp
Attachments: sftp-stream-proxy.diff
What I propose is to add the possibility to connect to a remote SSH server
through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
instance
http://backdrift.org/transparent-proxy-with-ssh
for a use case.
This simulates a ProxyCommand where the command is run on a SSH host.
The patch also contains a test for the new functionality.
Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
{code:java}
builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
builder.setProxyHost(opts, gate.way.host);
builder.setProxyPort(opts, 22);
builder.setProxyOptions(opts, proxyOptions);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
[
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482109#comment-13482109
]
Gary D. Gregory edited comment on VFS-440 at 10/23/12 4:44 AM:
---
Thank you for the patch and sorry it has taken me so long to take a look.
I just started to review the patch, but it would be helpful if it did NOT
contain ANY formatting changes. That makes the while process take longer. So,
if you can attach a patch that contains the semantic changes only, this will
all go faster.
One thing that I noticed in private static void connect(String name, final
InputStream in, final OutputStream out, final ExitCallback callback):
{noformat}
+catch (SshException ex)
+{
+
+}
{noformat}
That's probably not great unless I am missing something.
Also, do not hesitate to comment the code some more, that helps too :)
Thank you,
Gary
was (Author: garydgregory):
Thank you for the patch and sorry it has taken me so long to take a look.
I just started to review the patch, but it would be helpful if it did NOT
contain ANY formatting changes. That makes the while process take longer. So,
if you can attach a patch that contains the semantic changes only, this will
all go faster.
One thing that I noticed in private static void connect(String name, final
InputStream in, final OutputStream out, final ExitCallback callback):
+catch (SshException ex)
+{
+
+}
That's probably not great unless I am missing something.
Also, do not hesitate to comment the code some more, that helps too :)
Thank you,
Gary
[SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
-
Key: VFS-440
URL: https://issues.apache.org/jira/browse/VFS-440
Project: Commons VFS
Issue Type: Improvement
Reporter: Benjamin Piwowarski
Priority: Minor
Labels: proxy, sftp
Attachments: sftp-stream-proxy.diff
What I propose is to add the possibility to connect to a remote SSH server
through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for
instance
http://backdrift.org/transparent-proxy-with-ssh
for a use case.
This simulates a ProxyCommand where the command is run on a SSH host.
The patch also contains a test for the new functionality.
Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
{code:java}
builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
builder.setProxyHost(opts, gate.way.host);
builder.setProxyPort(opts, 22);
builder.setProxyOptions(opts, proxyOptions);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
