[jira] [Commented] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083005#comment-13083005 ] Nils Hildebrand commented on DBCP-350: -- Hi, I asked the question on a GIS-Forum at Stack-Exchange. I’ve got an answer that sounds very like the root-cause of the problem – located within hibernatespatial. See below… Does it ring a bell with you? Kind regards Nils Von: Stack Exchange [mailto:do-not-re...@stackexchange.com] Gesendet: Donnerstag, 11. August 2011 06:00 Any known problems after Tomcat-upgrade using oracle locator? http://gis.stackexchange.com/questions/13105/any-known-problems-after-tomcat-upgrade-using-oracle-locator Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JXPATH-152) Concurrent access on hashmap of JXPathIntrospector
Concurrent access on hashmap of JXPathIntrospector -- Key: JXPATH-152 URL: https://issues.apache.org/jira/browse/JXPATH-152 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.3 Environment: Java5, Windows/AIX Reporter: pleutre Priority: Minor JXPathIntrospector.registerDynamicClass method can be called in static part of classes. If two classes A B try to registerDynamicClass in the same time a concurrent access exception can append on hashmap of JXPathIntrospector. Replace hashmap by concurrent hashmap or synchronized access to these hashmaps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-350. -- Resolution: Not A Problem The analysis shows that this is caused by hibernate needing to access the raw Oracle connection but DBCP is returning wrapped objects. That makes this a hibernate issue unless DBCP does not provide a mechanism for hibernate to access the raw connection (which I believe it does). I don't see anything for DBCP to fix here. Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083055#comment-13083055 ] Nils Hildebrand commented on DBCP-350: -- Hi Mark, so dbcp does not use hibernate? I am confused. I am not a developer - I just want to see this bug fixed in Tomcat so I can use a standard-tomcat again. I played the game to escalate this to dbcp. But I will not play the game to escalate this further to hibernate - there seems to be a ready to use bug-fix there (at hibernate). So implement it into dbcp 1.3.n or 1.4.n and I am willing to test it again. If that fixes the problem I will report back to Tomcat so they can upgrade to dbcp 1.3.n or dbcp 1.4.n as well. Is this open source or is this I am the big bug closer, but am not interested in fixing problems? I've got my working workaround in place (commons.dbcp 1.2.2) - but I don't think this is helpful neither for tomcat nor dbcp nor the community. Regards Nils Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083058#comment-13083058 ] Mark Thomas commented on DBCP-350: -- No, DBCP does not use hibernate. Your application is using hibernate and hibernate is using DBCP, a version of which is packaged inside Apache Tomcat. There is no bug in Tomcat or DBCP to fix. The bug - if there is one - in hibernate or possibly your application. The hibernate folks are taking the understandable view that this is not a bug in hibernate. In this case hibernate needs access to the raw connection and it isn't really practical for hibernate to handle all possible scenarios for what it might need to do to access the raw connection. Hibernate provides a default mechanism to obtain the raw connection and provides an extension point for users to provide their own mechanism where the default mechanism doesn't work. The application that is using hibernate needs to provide an appropriate implementation of hibernate's ConnectionFinder. Yes this is open source but just because you are using DBCP as embedded in Tomcat that does not make all database problems you come across DBCP or Tomcat bugs. While the problem you are seeing was triggered by a change to DBCP that still does not make this a DBCP bug. Hibernate was relying on the raw connection being available which is not a valid assumption in an environment using connection pooling. The community has provided you with all the information you need to fix the problem you are experiencing with your application. Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-419) Not possible to call FTPClient.abort() method correctly
Not possible to call FTPClient.abort() method correctly --- Key: NET-419 URL: https://issues.apache.org/jira/browse/NET-419 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0 Environment: java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Reporter: Tomas Mysik Unfortunately, it seems that there are difficulties of using FTPClient.abort() method [1][2]. Also, it is really not clear how the abort() method should be called/used at all - if from another thread (as I would expect) then there is a problem with thread-safety: FTPClient itself is not thread-safe so it means that some custom lock/monitor must be used; but this lock will prevent calling abort() on the FTPClient while it is downloading/uploading file since file upload/download itself is blocking... If I'm wrong and the abort() method works then an example in Javadoc would be more than welcome. Thanks a lot. [1] http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083071#comment-13083071 ] Nils Hildebrand commented on DBCP-350: -- Hi Mark, thanks for this explanation and my apologies for not knowing the technical implications. The question that still arises is: If it is an application and/or hibernate problem (which is quite sure now) - why does the problem not hit the application when using the old dbcp 1.2.2? Was DBCP more error tolerant with regards to hybernate in that version? Kind regards Nils Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[
https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083179#comment-13083179
]
Matthew Pocock commented on CODEC-125:
--
The lucene/solr source seems not to reference StringEncoder. All references go
via Encoder. In org.apache.lucene.analysis.phonetic.PhoneticFilter, it has the
code:
String value = termAtt.toString();
String phonetic = null;
try {
String v = encoder.encode(value).toString();
if (v.length() 0 !value.equals(v)) phonetic = v;
} catch (Exception ignored) {} // just use the direct text
In org.apache.solr.analysis.PhoneticFilterFactory, there's a registry map of
encoders listing the (known) StringEncoder instances but typed to Encoder.
I agree that encoding sets of results as single strings is not ideal, and in an
ideal world would prefer to see CharSequence - SetCharSequence as the
interface. This would not only be more correct, but also lower the
computational overhead as we can use HashSet internally throughout, which is
much more efficient for working with string-keyed sets than TreeSet is. This
encoder is not unique in producing multiple outputs - it's a feature shared by
most sounds-like phonetic encodings, and if you look at the lucene code above,
all of these endoding strategies will not be handled gracefully by lucene.
The output strings right now are alphabetised, so the resulting string is
always in canonical form. It is not possible for it to produce different
strings for the same set.
The timeline I'd prefer to see is:
a) a release of commons-codec with the bmpm code, and work with lucene to
provide a follow-on lucene/solr releases using this, so as to make the codec
available at the earliest opportunity to people
b) bump a big version number for codec and make it fully Java 5 compliant, with
generics throughout both the internals and public interfaces, together with any
refactoring that may entail
c) encourage lucene/solr to put out a further release against this, handling
multiple encodings, and if needed helping them to adapt to the new interfaces
Implement a Beider-Morse phonetic matching codec
Key: CODEC-125
URL: https://issues.apache.org/jira/browse/CODEC-125
Project: Commons Codec
Issue Type: New Feature
Reporter: Matthew Pocock
Priority: Minor
Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff,
bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch,
bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch,
fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch,
majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html,
testEncodeGna.patch
I have implemented Beider Morse Phonetic Matching as a codec against the
commons-codec svn trunk. I would like to contribute this to commons-codec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083198#comment-13083198 ] Sebb commented on CODEC-125: Changing API means more than a version bump; for Commons it generally requires a change of package name and Maven id so that old and new versions can co-exist. So it's important to get the API correct before release if at all possible. In the case of brand new code, maybe it would be possible to document it as being unstable, and therefore allow changes to the API. But this should be discussed on the developer list first. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch, majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXEC-60) Possible deadlock when a process is terminating at the same time its timing out
Possible deadlock when a process is terminating at the same time its timing out --- Key: EXEC-60 URL: https://issues.apache.org/jira/browse/EXEC-60 Project: Commons Exec Issue Type: Bug Affects Versions: 1.1, 1.0.1 Reporter: Gui Forget Priority: Minor I ran into a deadlock when executing a process monitored by ExecuteWatchDog. This happened in 1.0.1 for me but looking at the code in 1.1 it seems to me that this could happen in this version as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EXEC-60) Possible deadlock when a process is terminating at the same time its timing out
[ https://issues.apache.org/jira/browse/EXEC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gui Forget updated EXEC-60: --- Attachment: deadlock.txt The thread dump showing the deadlock Possible deadlock when a process is terminating at the same time its timing out --- Key: EXEC-60 URL: https://issues.apache.org/jira/browse/EXEC-60 Project: Commons Exec Issue Type: Bug Affects Versions: 1.0.1, 1.1 Reporter: Gui Forget Priority: Minor Attachments: deadlock.txt I ran into a deadlock when executing a process monitored by ExecuteWatchDog. This happened in 1.0.1 for me but looking at the code in 1.1 it seems to me that this could happen in this version as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-460) reloadStrategy does not work for files inside additional tag using DefaultConfigurationBuilder
reloadStrategy does not work for files inside additional tag using DefaultConfigurationBuilder Key: CONFIGURATION-460 URL: https://issues.apache.org/jira/browse/CONFIGURATION-460 Project: Commons Configuration Issue Type: Bug Components: File reloading Affects Versions: 1.6 Environment: Linux x86_64 Reporter: Azfar Kazmi In the configuration file that DefaultConfigurationBuilder reads to build a CombinedConfiguration, it's possible to include configuration file either inside override or additional xml elements. Each such declaration, of a file, allows a realodStrategy to be specified (see example below). It appears that the reload occurs only for the files inside override and not for the ones inside additional. Example: configuration header result forceReloadCheck=true expressionEngine config-class=org.apache.commons.configuration.tree.xpath.XPathExpressionEngine/ /result /header override properties fileName=user.properties config-optional=true reloadingStrategy refreshDelay=100 config-class=org.apache.commons.configuration.reloading.FileChangedReloadingStrategy/ /properties /override additional properties fileName=application.properties reloadingStrategy refreshDelay=100 config-class=org.apache.commons.configuration.reloading.FileChangedReloadingStrategy/ /properties /additional /configuration In above example, both user.properties and application.properties are supposed to reload upon change. However, as tested by the following code, one user.properties gets reloaded: DefaultConfigurationBuilder dcb = new DefaultConfigurationBuilder(example.xml); Configuration conf = dcb.getConfiguration(); System.out.println(user: + conf.getBoolean(user)); System.out.println(application: + conf.getBoolean(application)); System.out.println(Change files and then press to continue...); System.in.read(); System.out.println(user: + conf.getBoolean(user)); System.out.println(application: + conf.getBoolean(application)); Output from above code: user: true application: true Change files and then press to continue... 0 [main] INFO org.apache.commons.configuration.PropertiesConfiguration - Reloading configuration. URL is file:snipped/user.properties user: false application: true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[
https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083402#comment-13083402
]
Gary D. Gregory commented on CODEC-125:
---
Hi Matthew, Sebb, and all:
The next release will already be a big bump to *2.0* (from 1.5.) The trunk code
is already on Java 5 but generics have not been implemented. Implementing
generics will probably change some of class/API layout due to some encoders
supporting multiple input/output types.
The trunk also has removed deprecated methods, which means binary
incompatibilities, which means the package name and POM should change.
*Right, Seeb? Others?*
This would also mean that codec2 would not be a drop in for codec1 but that
both could live side by side.
If we set the API to {{CharSequence encode(SetCharSequence)}} or {{String
encode(SetString)}}, doing a toString on a HashSet will yield a usable String
in a similar vein as trunk now. For example, for a Set of Strings {{a}},
{{b}} and {{c}}, {{HashSet.toString()}} returns {{[a, b, c]}} which no
worse than {{a|b|c}} IMO.
So we can have our cake and eat it too.
Implement a Beider-Morse phonetic matching codec
Key: CODEC-125
URL: https://issues.apache.org/jira/browse/CODEC-125
Project: Commons Codec
Issue Type: New Feature
Reporter: Matthew Pocock
Priority: Minor
Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff,
bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch,
bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch,
fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch,
majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html,
testEncodeGna.patch
I have implemented Beider Morse Phonetic Matching as a codec against the
commons-codec svn trunk. I would like to contribute this to commons-codec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083416#comment-13083416 ] Matthew Pocock commented on CODEC-125: -- hashSet.toString isn't deterministic between runs, as hashCodes vary. However, using a sorted set solves this. I think we've strayed beyond the original ticket. The bmpm functionality has been added. Should we either move to the ml, or open a separate generification for 2.0 release ticket to discuss this? Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch, majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083428#comment-13083428 ] Sebb commented on CODEC-125: @Gary. If there is already a need to break compat., then I don't have an issue with changing the bmpm api at the same time. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch, majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083432#comment-13083432 ] Gary D. Gregory commented on CODEC-125: --- BUT... BM is a *new* codec for 2.0. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch, majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-641) Implement distance methods on 2D and 3D Lines as well as Line Segments.
[ https://issues.apache.org/jira/browse/MATH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-641: - Affects Version/s: (was: 3.0) Fix Version/s: (was: 3.0) 3.1 Enhancement can wait until 3.1 Implement distance methods on 2D and 3D Lines as well as Line Segments. --- Key: MATH-641 URL: https://issues.apache.org/jira/browse/MATH-641 Project: Commons Math Issue Type: New Feature Reporter: Curtis Jensen Priority: Minor Fix For: 3.1 Original Estimate: 4h Remaining Estimate: 4h Implement a method that calculates the distance from a point to 3D and 2D lines and line segements (similar to what already exists in the 3D Line class). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-593) 3D SubLine
[ https://issues.apache.org/jira/browse/MATH-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-593: - Affects Version/s: (was: 3.0) Fix Version/s: (was: 3.0) 3.1 Enhancement can wait until 3.1 3D SubLine -- Key: MATH-593 URL: https://issues.apache.org/jira/browse/MATH-593 Project: Commons Math Issue Type: New Feature Reporter: Curtis Jensen Priority: Minor Labels: Geometry, math Fix For: 3.1 Original Estimate: 24h Remaining Estimate: 24h Add a SubLine class in the org.apache.commons.math.geometry.euclidean.threed package (similar to 2D and 3D lines). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083501#comment-13083501 ] Sebb commented on CODEC-125: @Gary: yes, I know it's new; my concern is about the next release after adding bmpm. I am concerned that the bmpm API is not stable, and that an early release might entail an incompatible change later. Hence the suggestion to discuss if that would require a package/maven name change, given that few external classes would be using it. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, handleH.patch, majorFix.patch, performanceAndBugs.patch, testAllChars-mem-profile.html, testEncodeGna.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-464) LegendreGaussIntegrator ignores defaultMaximalIterationCount and does 38 million iterations
[
https://issues.apache.org/jira/browse/MATH-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083502#comment-13083502
]
Phil Steitz commented on MATH-464:
--
+1 for your suggestion, Luc. Lets try to get this into 3.0.
LegendreGaussIntegrator ignores defaultMaximalIterationCount and does 38
million iterations
---
Key: MATH-464
URL: https://issues.apache.org/jira/browse/MATH-464
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Reporter: Michael Borcherds
Priority: Critical
Fix For: 3.0
Original Estimate: 3h
Remaining Estimate: 3h
The following code results in count = 37801710 which is effectively an
infinite loop for typical functions we are using
(in GeoGebra)
The argument defaultMaximalIterationCount = 100 is being ignored
This is the version we are using:
http://www.geogebra.org/trac/browser/trunk/geogebra/org/apache/commons/math/analysis/integration/LegendreGaussIntegrator.java
LegendreGaussIntegrator gauss = new LegendreGaussIntegrator(5, 100);
try {
double result = gauss.integrate(new testFun(), -10,
0.32462367623786328);
} catch (Exception ee) {
ee.printStackTrace();
}
class testFun implements UnivariateRealFunction {
public double value(double x) throws FunctionEvaluationException {
count ++;
if (x=0 x=5) return 0.2; else return 0;
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-460) Levy Distribution
[ https://issues.apache.org/jira/browse/MATH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083505#comment-13083505 ] Phil Steitz commented on MATH-460: -- Any comments on this? Anyone else want to claim it? ;) Levy Distribution - Key: MATH-460 URL: https://issues.apache.org/jira/browse/MATH-460 Project: Commons Math Issue Type: New Feature Reporter: Pavel Ryzhov Priority: Minor Fix For: 3.0 Attachments: levy_math_460.patch Pretty straightforward implementation of Levy Distribution (not Levy alpha-stable) according to http://en.wikipedia.org/wiki/Lévy_distribution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-449) Storeless covariance
[
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-449:
-
Fix Version/s: (was: 3.0)
3.1
Pushing out to 3.1, awaiting patch
Storeless covariance
Key: MATH-449
URL: https://issues.apache.org/jira/browse/MATH-449
Project: Commons Math
Issue Type: Improvement
Reporter: Patrick Meyer
Fix For: 3.1
Original Estimate: 168h
Remaining Estimate: 168h
Currently there is no storeless version for computing the covariance.
However, Pebay (2008) describes algorithms for on-line covariance
computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have
provided a simple class for implementing this algorithm. It would be nice to
have this integrated into org.apache.commons.math.stat.correlation.Covariance.
{code}
//This code is granted for inclusion in the Apache Commons under the terms of
the ASL.
public class StorelessCovariance{
private double deltaX = 0.0;
private double deltaY = 0.0;
private double meanX = 0.0;
private double meanY = 0.0;
private double N=0;
private Double covarianceNumerator=0.0;
private boolean unbiased=true;
public Covariance(boolean unbiased){
this.unbiased = unbiased;
}
public void increment(Double x, Double y){
if(x!=null y!=null){
N++;
deltaX = x - meanX;
deltaY = y - meanY;
meanX += deltaX/N;
meanY += deltaY/N;
covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
}
}
public Double getResult(){
if(unbiased){
return covarianceNumerator/(N-1.0);
}else{
return covarianceNumerator/N;
}
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-364) Make Erf more precise in the tails by providing erfc
[
https://issues.apache.org/jira/browse/MATH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083514#comment-13083514
]
Phil Steitz commented on MATH-364:
--
Any comments on this?
Make Erf more precise in the tails by providing erfc
Key: MATH-364
URL: https://issues.apache.org/jira/browse/MATH-364
Project: Commons Math
Issue Type: Improvement
Affects Versions: 1.1, 1.2, 2.0, 2.1
Reporter: Christian Winter
Priority: Minor
Fix For: 3.0
First I want to thank Phil Steitz for making Erf stable in the tails through
adjusting the choices in calculating the regularized gamma functions, see
[Math-282|https://issues.apache.org/jira/browse/MATH-282]. However, the
precision of Erf in the tails is limitted to fixed point precision because of
the closeness to +/-1.0, although the Gamma class could provide much more
accuracy. Thus I propose to add the methods erfc(double) and erf(double,
double) to the class Erf:
{code:borderStyle=solid}
/**
* Returns the complementary error function erfc(x).
* @param x the value
* @return the complementary error function erfc(x)
* @throws MathException if the algorithm fails to converge
*/
public static double erfc(double x) throws MathException {
double ret = Gamma.regularizedGammaQ(0.5, x * x, 1.0e-15, 1);
if (x 0) {
ret = -ret;
}
return ret;
}
/**
* Returns the difference of the error function values of x1 and x2.
* @param x1 the first bound
* @param x2 the second bound
* @return erf(x2) - erf(x1)
* @throws MathException
*/
public static double erf(double x1, double x2) throws MathException {
if(x1x2)
return erf(x2, x1);
if(x1==x2)
return 0.0;
double f1 = erf(x1);
double f2 = erf(x2);
if(f2 0.5)
if(f1 0.5)
return erfc(x1) - erfc(x2);
else
return (0.5-erfc(x2)) + (0.5-f1);
else
if(f1 -0.5)
if(f2 -0.5)
return erfc(-x2) - erfc(-x1);
else
return (0.5-erfc(-x1)) + (0.5+f2);
else
return f2 - f1;
}
{code}
Further this can be used to improve the NormalDistributionImpl through
{code:borderStyle=solid}
@Override
public double cumulativeProbability(double x0, double x1) throws
MathException {
return 0.5 * Erf.erf(
(x0 - getMean()) / (getStandardDeviation() * sqrt2),
(x1 - getMean()) / (getStandardDeviation() * sqrt2) );
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-355) State of the art SVD Algorithm
[ https://issues.apache.org/jira/browse/MATH-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-355: - Fix Version/s: (was: 3.0) 3.1 If we do decide to add another impl or enhance SVD further, this can wait until 3.1 State of the art SVD Algorithm -- Key: MATH-355 URL: https://issues.apache.org/jira/browse/MATH-355 Project: Commons Math Issue Type: Improvement Affects Versions: 2.0, 2.1 Reporter: Bruce A Johnson Labels: svd Fix For: 3.1 There has been a lot of recent activity on the SVD algorithm for Commons Math. The SVD has also been in the news lately because of the development of a new algorithm that is both faster and more accurate than previous algorithms. Given the importance of the SVD in many applications it would be useful to have a Java implementation of this new algorithm in Commons Math. News article on the new algorithm: http://www.siam.org/pdf/news/1696.pdf Manuscripts on the new algorithm: http://www.netlib.org/lapack/lawnspdf/lawn169.pdf http://www.netlib.org/lapack/lawnspdf/lawn170.pdf Implementation in LAPACK 3.2.1 dgesvj.f -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-353) Constrained version of the Nelder-Mead simplex method and bi-cubic interpolation
[ https://issues.apache.org/jira/browse/MATH-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-353: - Fix Version/s: (was: 3.0) 3.1 Enhancement can wait until 3.1. Constrained version of the Nelder-Mead simplex method and bi-cubic interpolation Key: MATH-353 URL: https://issues.apache.org/jira/browse/MATH-353 Project: Commons Math Issue Type: Wish Affects Versions: 2.0, 2.1 Reporter: Dimitri Pourbaix Priority: Minor Fix For: 3.1 The library http://www.ee.ucl.ac.uk/~mflanaga/java/ offers a constrained version of the Nelder-Mead simplex method through the addition of a penalty function. Such a possibility seems to be missing from commons-math. The same library also offers some bi-cubic interpolation which is also absent in commons-math. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-345) A new secant solver that does not enforce bracketing
[ https://issues.apache.org/jira/browse/MATH-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-345. -- Resolution: Fixed MATH-599 A new secant solver that does not enforce bracketing Key: MATH-345 URL: https://issues.apache.org/jira/browse/MATH-345 Project: Commons Math Issue Type: New Feature Affects Versions: 2.0 Reporter: Volkan Aktas Priority: Minor Fix For: 3.0 Existing SecantSolver is only able to find a root in the specified bracket. Non-bracketing versions exist and adding one to the suite would be useful. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-284) Avoid ArrayStoreException
[
https://issues.apache.org/jira/browse/MATH-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083523#comment-13083523
]
Phil Steitz commented on MATH-284:
--
Can we just apply original suggestion and resolve this now?
Avoid ArrayStoreException
-
Key: MATH-284
URL: https://issues.apache.org/jira/browse/MATH-284
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Klaus
Priority: Minor
Fix For: 3.0
Attachments: math-284.patch
Add a new method
org.apache.commons.math,Field#getRuntimeClass():
...
/**
* Returns the runtime class of the FieldElement.
*
* @return The {@code Class} object that represents the runtime
* class of this object.
*/
Class? extends FieldElement getRuntimeClass();
...
and replace all occurrences of
Array.newInstance(field.getZero().getClass(),)
with
Array.newInstance(field.getRuntimeClass(),)
to avoid the throwing of ArrayStoreException in the case you have a type
hierachy of Fields with a common interface
and the array should have the interface type at runtime.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-235) Eigenvalues/eigenvectors of real asymmetric matrices
[ https://issues.apache.org/jira/browse/MATH-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083524#comment-13083524 ] Phil Steitz commented on MATH-235: -- Anyone want to take a stab at this for 3.0? Eigenvalues/eigenvectors of real asymmetric matrices Key: MATH-235 URL: https://issues.apache.org/jira/browse/MATH-235 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: James Housden Priority: Minor Fix For: 3.0 The EigenDecompositionImpl class contains methods to calculate the eigenvalues/eigenvectors of real symmetric matrices. However, for real asymmetric matrices there are currently no methods available to do this. It would be nice if commons-math could be enhanced to provide this extra functionality. Please note that the JAMA package contains a possible implementation in its EigenvalueDecomposition class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-228) Feature request for one and two sample Kolmogorov-Smirnov test as well as Lilliefors test
[ https://issues.apache.org/jira/browse/MATH-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-228: - Fix Version/s: (was: 3.0) 3.1 Moving to 3.1, awaiting patch. Feature request for one and two sample Kolmogorov-Smirnov test as well as Lilliefors test - Key: MATH-228 URL: https://issues.apache.org/jira/browse/MATH-228 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Environment: All Reporter: Anirban Basu Priority: Minor Fix For: 3.1 Original Estimate: 336h Remaining Estimate: 336h It would be very helpful to have implementations of one and two sample [Kolmogorov-Smirnov test|http://en.wikipedia.org/wiki/Kolmogorov-Smirnov_test] as well as [Lilliefors test|http://en.wikipedia.org/wiki/Lilliefors_test] with MATLAB-style results in future versions of Commons Math. For example, Lilliefors test on sample data: sampleVector = [0.0033413022337048857, 0.008527692135731013, -0.004902763950955454, 0.033018433100296396, -0.020495504044139023, 0.003978726052913162, 0.003847972673931109, 0.009160477945515444, -0.03437653216639, -0.01164235145079795, 0.017180306607011864, -0.01818483009998717, -0.010479811709006803, -0.033991339307749, -0.007057160031600951, -1.2398497120424956E-4, 0.0026913151777877564, 0.03580425341677764, -0.006404370278251359, 0.007579083257585828, -0.005912037207256193, 0.01241830354576745, -0.0012524631744377235, -0.005900927958040758, 0.0028847985848513558, 0.005313417226899042, 0.018923743379700153, 0.010976836172447269, -0.017847220928846164, 0.0024067380689056783, -0.011912393656503872, -0.019985462687391875, 0.017318878212931876, 0.003592873590795409, -0.00332615776078915, -0.018222673013956525, -0.021591768336351125]; [h, p] = lillietest(sampleVector) Warning: P is greater than the largest tabulated value, returning 0.5. In lillietest at 166 h = 0 p = 0.5000 This uses Lilliefors test for normality. The test returns that h=0, i.e. the null hypothesis that the data vector obeys Normal distribution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-284) Avoid ArrayStoreException
[
https://issues.apache.org/jira/browse/MATH-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083677#comment-13083677
]
Luc Maisonobe commented on MATH-284:
If the patch still works, we could add it.
Avoid ArrayStoreException
-
Key: MATH-284
URL: https://issues.apache.org/jira/browse/MATH-284
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Klaus
Priority: Minor
Fix For: 3.0
Attachments: math-284.patch
Add a new method
org.apache.commons.math,Field#getRuntimeClass():
...
/**
* Returns the runtime class of the FieldElement.
*
* @return The {@code Class} object that represents the runtime
* class of this object.
*/
Class? extends FieldElement getRuntimeClass();
...
and replace all occurrences of
Array.newInstance(field.getZero().getClass(),)
with
Array.newInstance(field.getRuntimeClass(),)
to avoid the throwing of ArrayStoreException in the case you have a type
hierachy of Fields with a common interface
and the array should have the interface type at runtime.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-364) Make Erf more precise in the tails by providing erfc
[
https://issues.apache.org/jira/browse/MATH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083680#comment-13083680
]
Luc Maisonobe commented on MATH-364:
I'm not sure I understand.
If adding an erfc(x1, x2) method that compute the difference erc(x1)-erfc(x2)
accurately, then it seems a good improvement.
Make Erf more precise in the tails by providing erfc
Key: MATH-364
URL: https://issues.apache.org/jira/browse/MATH-364
Project: Commons Math
Issue Type: Improvement
Affects Versions: 1.1, 1.2, 2.0, 2.1
Reporter: Christian Winter
Priority: Minor
Fix For: 3.0
First I want to thank Phil Steitz for making Erf stable in the tails through
adjusting the choices in calculating the regularized gamma functions, see
[Math-282|https://issues.apache.org/jira/browse/MATH-282]. However, the
precision of Erf in the tails is limitted to fixed point precision because of
the closeness to +/-1.0, although the Gamma class could provide much more
accuracy. Thus I propose to add the methods erfc(double) and erf(double,
double) to the class Erf:
{code:borderStyle=solid}
/**
* Returns the complementary error function erfc(x).
* @param x the value
* @return the complementary error function erfc(x)
* @throws MathException if the algorithm fails to converge
*/
public static double erfc(double x) throws MathException {
double ret = Gamma.regularizedGammaQ(0.5, x * x, 1.0e-15, 1);
if (x 0) {
ret = -ret;
}
return ret;
}
/**
* Returns the difference of the error function values of x1 and x2.
* @param x1 the first bound
* @param x2 the second bound
* @return erf(x2) - erf(x1)
* @throws MathException
*/
public static double erf(double x1, double x2) throws MathException {
if(x1x2)
return erf(x2, x1);
if(x1==x2)
return 0.0;
double f1 = erf(x1);
double f2 = erf(x2);
if(f2 0.5)
if(f1 0.5)
return erfc(x1) - erfc(x2);
else
return (0.5-erfc(x2)) + (0.5-f1);
else
if(f1 -0.5)
if(f2 -0.5)
return erfc(-x2) - erfc(-x1);
else
return (0.5-erfc(-x1)) + (0.5+f2);
else
return f2 - f1;
}
{code}
Further this can be used to improve the NormalDistributionImpl through
{code:borderStyle=solid}
@Override
public double cumulativeProbability(double x0, double x1) throws
MathException {
return 0.5 * Erf.erf(
(x0 - getMean()) / (getStandardDeviation() * sqrt2),
(x1 - getMean()) / (getStandardDeviation() * sqrt2) );
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-235) Eigenvalues/eigenvectors of real asymmetric matrices
[ https://issues.apache.org/jira/browse/MATH-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083685#comment-13083685 ] Luc Maisonobe commented on MATH-235: We have already used some code directly from Jama. Perhaps we could do the same here ? What do our linear algebra gurus think ? Eigenvalues/eigenvectors of real asymmetric matrices Key: MATH-235 URL: https://issues.apache.org/jira/browse/MATH-235 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: James Housden Priority: Minor Fix For: 3.0 The EigenDecompositionImpl class contains methods to calculate the eigenvalues/eigenvectors of real symmetric matrices. However, for real asymmetric matrices there are currently no methods available to do this. It would be nice if commons-math could be enhanced to provide this extra functionality. Please note that the JAMA package contains a possible implementation in its EigenvalueDecomposition class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-364) Make Erf more precise in the tails by providing erfc
[
https://issues.apache.org/jira/browse/MATH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083702#comment-13083702
]
Phil Steitz commented on MATH-364:
--
I agree it would be good if it is more accurate and I suspect it probably is,
but I have not been able to derive justification for that statement myself or
find a reference for the supposedly improved algorithm (in the first code
segment above).
Make Erf more precise in the tails by providing erfc
Key: MATH-364
URL: https://issues.apache.org/jira/browse/MATH-364
Project: Commons Math
Issue Type: Improvement
Affects Versions: 1.1, 1.2, 2.0, 2.1
Reporter: Christian Winter
Priority: Minor
Fix For: 3.0
First I want to thank Phil Steitz for making Erf stable in the tails through
adjusting the choices in calculating the regularized gamma functions, see
[Math-282|https://issues.apache.org/jira/browse/MATH-282]. However, the
precision of Erf in the tails is limitted to fixed point precision because of
the closeness to +/-1.0, although the Gamma class could provide much more
accuracy. Thus I propose to add the methods erfc(double) and erf(double,
double) to the class Erf:
{code:borderStyle=solid}
/**
* Returns the complementary error function erfc(x).
* @param x the value
* @return the complementary error function erfc(x)
* @throws MathException if the algorithm fails to converge
*/
public static double erfc(double x) throws MathException {
double ret = Gamma.regularizedGammaQ(0.5, x * x, 1.0e-15, 1);
if (x 0) {
ret = -ret;
}
return ret;
}
/**
* Returns the difference of the error function values of x1 and x2.
* @param x1 the first bound
* @param x2 the second bound
* @return erf(x2) - erf(x1)
* @throws MathException
*/
public static double erf(double x1, double x2) throws MathException {
if(x1x2)
return erf(x2, x1);
if(x1==x2)
return 0.0;
double f1 = erf(x1);
double f2 = erf(x2);
if(f2 0.5)
if(f1 0.5)
return erfc(x1) - erfc(x2);
else
return (0.5-erfc(x2)) + (0.5-f1);
else
if(f1 -0.5)
if(f2 -0.5)
return erfc(-x2) - erfc(-x1);
else
return (0.5-erfc(-x1)) + (0.5+f2);
else
return f2 - f1;
}
{code}
Further this can be used to improve the NormalDistributionImpl through
{code:borderStyle=solid}
@Override
public double cumulativeProbability(double x0, double x1) throws
MathException {
return 0.5 * Erf.erf(
(x0 - getMean()) / (getStandardDeviation() * sqrt2),
(x1 - getMean()) / (getStandardDeviation() * sqrt2) );
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083924#comment-13083924 ] Henri Yandell commented on DBUTILS-78: -- I've moved DbUtils to Java6. People can comment if they feel that is too soon. I've committed the patch - I agree that the classes should have a base class, but I think it'll be easier to do the other items (base class, documentation of example use and when you would use this) as subsequent patches. Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083926#comment-13083926 ] Henri Yandell commented on DBUTILS-53: -- I'd keep them separate, possibly having a base class if there are common tests to apply. Set Derby up as a unit test database Key: DBUTILS-53 URL: https://issues.apache.org/jira/browse/DBUTILS-53 Project: Commons DbUtils Issue Type: Task Reporter: Henri Yandell Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-66) ScalarHandler, ColumnHandler and KeyedHandler are missing generics
[ https://issues.apache.org/jira/browse/DBUTILS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBUTILS-66: - Fix Version/s: 1.4 ScalarHandler, ColumnHandler and KeyedHandler are missing generics -- Key: DBUTILS-66 URL: https://issues.apache.org/jira/browse/DBUTILS-66 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.3 Reporter: Michael Osipov Fix For: 1.4 Attachments: DBUTILS-66.patch Introcuding generics is great but some handles are not generics-aware. I have patched those and attached the file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-67) Add a BeanMapHandler
[ https://issues.apache.org/jira/browse/DBUTILS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBUTILS-67: - Fix Version/s: 1.4 Add a BeanMapHandler Key: DBUTILS-67 URL: https://issues.apache.org/jira/browse/DBUTILS-67 Project: Commons DbUtils Issue Type: New Feature Affects Versions: 1.3 Environment: JDK 6, WinXP SP3 + HP-UX Reporter: Michael Osipov Fix For: 1.4 Attachments: DBUTILS-67.patch Based on code which has been posted here a long time ago I have built a generic BeanMapHandler based on the AbstractKeyedHandler. See the patch. Modify as you think fit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-53) Set Derby up as a unit test database
[ https://issues.apache.org/jira/browse/DBUTILS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBUTILS-53: - Fix Version/s: 1.4 Set Derby up as a unit test database Key: DBUTILS-53 URL: https://issues.apache.org/jira/browse/DBUTILS-53 Project: Commons DbUtils Issue Type: Task Reporter: Henri Yandell Fix For: 1.4 Or hsqldb. I used Derby for Taglibs to test the sql tags and it worked well enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-78) Add asynchronous batch, query, and update calls
[ https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083949#comment-13083949 ] Simone Tripodi commented on DBUTILS-78: --- Hen, I agree on moving DBUtils to Java6: Java5 is no longer supported and in order to get as much as possible advantages - especially in the JDBC field - that move sounds more than reasonable. As a side note: in MyBatis (formerly Apache iBATIS) we had to take the same choice in order to take advantage from JDBC4 APIs. Add asynchronous batch, query, and update calls --- Key: DBUTILS-78 URL: https://issues.apache.org/jira/browse/DBUTILS-78 Project: Commons DbUtils Issue Type: New Feature Reporter: William R. Speirs Priority: Minor Fix For: 1.4 Attachments: AsyncQueryRunner.java, AsyncQueryRunnerTest.java, pom.diff I propose a new QueryRunner class, AsyncQueryRunner, which changes the return type of batch, query, and update methods. Instead of returning their respective return types, the methods would return a RunnableFuture. This would allow callers to either execute the RunnableFuture in a thread or via an CompletionService like the ExecutorCompletionService. I have attached a first cut at this class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-624) Need a method to solve upper and lower triangular systems
[ https://issues.apache.org/jira/browse/MATH-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-624. -- Resolution: Fixed Patch applied in r1156968 with one change: s/MathRuntimeException.CreateXxx/new Xxx throughout. The former usage is deprecated. Thanks for the patch! Need a method to solve upper and lower triangular systems - Key: MATH-624 URL: https://issues.apache.org/jira/browse/MATH-624 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: Java Reporter: greg sterijevski Assignee: Phil Steitz Labels: Backsolve, Forwardsolve, LowerTriangular, UpperTriangular Fix For: 3.0 Attachments: upperlowermethods, upperlowertests Original Estimate: 0h Remaining Estimate: 0h I have run into a need to solve triangular systems. While (as Phil and Ted point out) I could use the LU and QR decompositions, it seems cleaner to have a couple of static functions which do this. I am including a patch to provide an implementation and the tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
