[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090164#comment-13090164
]
Gilles commented on MATH-646:
-
Committed, with some small changes, in revision 1161064.
Before posting a patch, please don't forget to look at the output of mvn clean
site for Javadoc warnings and at checkstyle.html (in target/site).
Couldn't we call the unmodifiableRealVector method simply
unmodifiableVector?
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090179#comment-13090179
]
Sébastien Brisard commented on MATH-646:
{quote}
Before posting a patch, please don't forget to look at the output of mvn clean
site for Javadoc warnings and at checkstyle.html (in target/site).
{quote}
I'm sorry, I'll do that next time. I must have mis-configured checkstyle in my
Eclipse. Sorry again to waste your time.
{quote}
Couldn't we call the unmodifiableRealVector method simply
unmodifiableVector?
{quote}
I'm all for it.
While we are at it, shouldn't we provide an unmodifiable view of matrices,
following the same lines? Shall I open a JIRA ticket?
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090179#comment-13090179
]
Sébastien Brisard edited comment on MATH-646 at 8/24/11 12:40 PM:
--
{quote}
Before posting a patch, please don't forget to look at the output of mvn clean
site for Javadoc warnings and at checkstyle.html (in target/site).
{quote}
I'm sorry, I'll do that next time. I must have mis-configured checkstyle in my
Eclipse. Sorry again to waste your time.
{quote}
Couldn't we call the unmodifiableRealVector method simply
unmodifiableVector?
{quote}
I'm all for it. Are you going to do it, or should I submit a new patch?
While we are at it, shouldn't we provide an unmodifiable view of matrices,
following the same lines? Shall I open a JIRA ticket?
was (Author: celestin):
{quote}
Before posting a patch, please don't forget to look at the output of mvn clean
site for Javadoc warnings and at checkstyle.html (in target/site).
{quote}
I'm sorry, I'll do that next time. I must have mis-configured checkstyle in my
Eclipse. Sorry again to waste your time.
{quote}
Couldn't we call the unmodifiableRealVector method simply
unmodifiableVector?
{quote}
I'm all for it.
While we are at it, shouldn't we provide an unmodifiable view of matrices,
following the same lines? Shall I open a JIRA ticket?
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090190#comment-13090190
]
Gilles commented on MATH-646:
-
For unmodifiableRealVector - unmodifiableVector, I can do it; I was just
wondering whether there could be any side-effects (like the risk of having
another method like this in the future) or whether it would be better to have a
suffix that is exactly the name of the returned type...
For the matrix view, do you have a need for it now? If not, it could be delayed
to 3.1 and, if you want, you could tackle issues that must be resolved before
3.0.
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-650) FastMath has static code which slows the first access to FastMath
FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090224#comment-13090224
]
Sebb commented on MATH-650:
---
Any change needs to bear in mind that the fields need to remain thread-safe,
i.e. whatever generates them must publish the values safely to all threads.
This is currently achieved by using the static{} block with final fields.
Seems to me there are two possible approaches to fix this:
- improve the performance of the existing code
- change the code to use initialisation on demand, so only the required parts
are intialised.
Static holder classes can probably be used here to ensure safe publication.
In the case of floor(), that does not need the calculated fields, so it would
speed it up.
Note that the FastMath version of floor() is likely to have similar performance
to Math.floor(), as it's not an algorithm that benefits from (or indeed needs)
the FastMath approach.
It would be useful to have performance figures for more complicated
calculations, where FastMath should start to show benefits.
FastMath has static code which slows the first access to FastMath
-
Key: MATH-650
URL: https://issues.apache.org/jira/browse/MATH-650
Project: Commons Math
Issue Type: Improvement
Affects Versions: Nightly Builds
Environment: Android 2.3 (Dalvik VM with JIT)
Reporter: Alexis Robert
Priority: Minor
Working on an Android application using Orekit, I've discovered that a simple
FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the
first time it's called). I've launched the Android profiling tool (traceview)
and the problem seems to be linked with the static portion of FastMath code
named // Initialize tables
The timing resulted in :
- FastMath.slowexp (40.8%)
- FastMath.expint (39.2%)
\- FastMath.quadmult() (95.6% of expint)
- FastMath.slowlog (18.2%)
Hoping that would help
Thanks!
Alexis Robert
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090254#comment-13090254
]
Sébastien Brisard commented on MATH-646:
I could use unmodifiable views of matrices, but I'm happy implementing it
outside the o.a.c.m library for the time being, and submitting it later on.
I can then concentrate on other issues.
I guess MATH-581 is still scheduled for 3.0 (support for iterative linear
solvers)?
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-215) Cannot set local username and password for a Win32 service
Cannot set local username and password for a Win32 service -- Key: DAEMON-215 URL: https://issues.apache.org/jira/browse/DAEMON-215 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.7 Environment: win32 / server 2003 Reporter: wessels Priority: Minor Fix For: 1.0.7 installing a new service without supplying the --ServiceUser --ServicePassword installs the service correctly but using the LocalSystem account. If you want to use a local user, which of course has at least the log on as a service right, and supply the credentials via the parameters you get an error. To be more specific, in service.c line 211, the CHANGE_SERVICE macro fails with error 87L ERROR_INVALID_PARAMETER. This happens at least when creating and updating a service. Setting other options via this macro work fine, just the username password fail (standalone and in combination with other parameters). The solution is specifying SERVICE_WIN32_OWN_PROCESS as ServiceType parameter instead of SERVICE_NO_CHANGE in ChangeServiceConfigW line 27 second parameter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090294#comment-13090294 ] Luc Maisonobe commented on MATH-650: The problem is not specific to the floor method. In fact, the first call to any method in FastMath loads the class and at class loading the static constant tables are populated. This problem has already been identified some time ago (I can't find the thread, but I think the example at that time was about the first calls to FastMath.exp). There are several places where we compute some initial constants or tables and use them later. The computed constants are always the same, and in fact they could be compile-time constants. I wonder if we should have some way to compute these tables at compile time and have them simply loaded without recomputation. The precomputed tables could be either literal doubles in automatically generated java source code or they could be stored in some text files embedded withing the jar. The same problem occurs for the constants in the Legendre-Gauss integrator (we could use higher degrees if we could store constants), for some ODE integrators, for the Dfp class (in this case they are string literals with a very large number of significant digits) ... FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090308#comment-13090308 ] Sebb commented on MATH-650: --- bq. I wonder if we should have some way to compute these tables at compile time and have them simply loaded without recomputation. Not sure the compiler can create the values. But we could add code to print out the generated data, and then incorporate back into the source. Should be no need to update it once created, however to check the ongoing accuracy of the tables, the generating code could be moved into a test class, and used to compare against the fixed data. This would probably require some package protected helper methods to give access to the private data. Or the generator code could remain in the FastMath class, to be called by the unit test code only. FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-501) Refactor package analysis.integration
[ https://issues.apache.org/jira/browse/MATH-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-501. Resolution: Fixed Fixed in subversion repository as of r1161181. Refactor package analysis.integration --- Key: MATH-501 URL: https://issues.apache.org/jira/browse/MATH-501 Project: Commons Math Issue Type: Improvement Reporter: Gilles Priority: Minor Fix For: 3.0 This package should be refactored similarly to what has been done in package analysis.solvers: avoid protected fields, remove unnecessary state variable result and associated method, remove deprecated code, use new exceptions... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-123) ColognePhonetic Javadoc should use HTML entities for special characters.
[ https://issues.apache.org/jira/browse/CODEC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-123: -- Fix Version/s: (was: 2.0) 1.6 ColognePhonetic Javadoc should use HTML entities for special characters. Key: CODEC-123 URL: https://issues.apache.org/jira/browse/CODEC-123 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Priority: Minor Fix For: 1.6 The ColognePhonetic class contains Javadoc with umlauts and other characters that do not always play well in editors. Change these characters to HTML entities. This means we should also be able to remove the UTF-8 settings in the POM for Javadoc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-120) Migrate to JUnit 4
[ https://issues.apache.org/jira/browse/CODEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-120: -- Fix Version/s: (was: 2.0) 1.6 Migrate to JUnit 4 -- Key: CODEC-120 URL: https://issues.apache.org/jira/browse/CODEC-120 Project: Commons Codec Issue Type: Improvement Reporter: Gary D. Gregory Fix For: 1.6 Migrate to JUnit 4 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CODEC-126) Make org.apache.commons.codec.net.URLCodec charset field final
[ https://issues.apache.org/jira/browse/CODEC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reopened CODEC-126: --- Reopening for 2.0, 1.6 will not include this and will be reverted from trunk. Make org.apache.commons.codec.net.URLCodec charset field final --- Key: CODEC-126 URL: https://issues.apache.org/jira/browse/CODEC-126 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.5 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 2.0 Make org.apache.commons.codec.net.URLCodec charset field final. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-119) Migrate to Java 5
[ https://issues.apache.org/jira/browse/CODEC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-119: -- Affects Version/s: 1.5 Fix Version/s: (was: 2.0) 1.6 Migrate to Java 5 - Key: CODEC-119 URL: https://issues.apache.org/jira/browse/CODEC-119 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.5 Reporter: Gary D. Gregory Fix For: 1.6 Migrate to Java 5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-119) Migrate to Java 5
[ https://issues.apache.org/jira/browse/CODEC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-119. --- Resolution: Fixed Done (for a while.) Migrate to Java 5 - Key: CODEC-119 URL: https://issues.apache.org/jira/browse/CODEC-119 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.5 Reporter: Gary D. Gregory Fix For: 1.6 Migrate to Java 5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-125: -- Fix Version/s: 1.6 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 Fix For: 1.6 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] (CODEC-127) Non-ascii characters in source files
[
https://issues.apache.org/jira/browse/CODEC-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-127:
--
Affects Version/s: 1.5
Fix Version/s: 1.6
Non-ascii characters in source files
Key: CODEC-127
URL: https://issues.apache.org/jira/browse/CODEC-127
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.5
Reporter: Sebb
Fix For: 1.6
Some of the test cases include characters in a native encoding (possibly
UTF-8), rather than using Unicode escapes.
This can cause a problem for IDEs if they don't know the encoding (e.g. cause
compilation errors, which is how I found the issue), and possibly some
transformations may corrupt the contents, e.g. fixing EOL.
I think we should have a rule of using Unicode escapes for all such non-ascii
characters.
It's particularly important for non-ISO-8859-1 characters.
Some example classes with non-ascii characters:
{code}
binary\Base64Test.java:96 byte[] decode =
b64.decode(SGVsbG{´┐¢´┐¢´┐¢´┐¢´┐¢´┐¢}8gV29ybGQ=);
language\ColognePhoneticTest.java:110 {m├Ânchengladbach,
664645214},
language\ColognePhoneticTest.java:130 String[][] data =
{{bergisch-gladbach, 174845214}, {M├╝ller-L├╝denscheidt, 65752682}};
language\ColognePhoneticTest.java:137 {Meyer, M├╝ller},
language\ColognePhoneticTest.java:143 {ganz, Gänse},
language\DoubleMetaphoneTest.java:1222
this.getDoubleMetaphone().isDoubleMetaphoneEqual(´┐¢, S);
language\DoubleMetaphoneTest.java:1227
this.getDoubleMetaphone().isDoubleMetaphoneEqual(´┐¢, N);
language\SoundexTest.java:367 if (Character.isLetter('´┐¢')) {
language\SoundexTest.java:369 Assert.assertEquals(´┐¢000,
this.getSoundexEncoder().encode(´┐¢));
language\SoundexTest.java:375 Assert.assertEquals(,
this.getSoundexEncoder().encode(´┐¢));
language\SoundexTest.java:387 if (Character.isLetter('´┐¢')) {
language\SoundexTest.java:389 Assert.assertEquals(´┐¢000,
this.getSoundexEncoder().encode(´┐¢));
language\SoundexTest.java:395 Assert.assertEquals(,
this.getSoundexEncoder().encode(´┐¢));
{code}
The characters are probably not correct above, because I used a crude perl
script to find them:
{code}
perl -ne $.=1 if $s ne $ARGV;print qq($ARGV:$. $_) if
m/\P{ASCII}/;$s=$ARGV; .java
{code}
language\SoundexTest.java:367 in particular is incorrect, because it's
supposed to be a single character.
Now one might think that native2ascii -encoding UTF-8 would fix that, but it
gives:
if (Character.isLetter('\ufffd'))
which is an unknown character.
Similarly for binary\Base64Test.java:96.
It's not all that clear what the Unicode escapes should be in these cases,
but probably not the unknown character.
[Possibly the characters got mangled at some point, or maybe they have always
been wrong]
The ColognePhoneticTest.java cases are less serious, as the characters are
valid ISO-8859-1 (accented German), but given that the rest of the file uses
unicode escaps, I think they should be changed too (but add comments to say
what they are, e.g. o-umlaut, u-umlaut)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-124) Remove deprecated code for 2.0.
[ https://issues.apache.org/jira/browse/CODEC-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-124: -- Fix Version/s: (was: 1.6) 2.0 Remove deprecated code for 2.0. --- Key: CODEC-124 URL: https://issues.apache.org/jira/browse/CODEC-124 Project: Commons Codec Issue Type: Task Affects Versions: 1.5, 1.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 2.0 Remove deprecated code for 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CODEC-124) Remove deprecated code for 2.0.
[ https://issues.apache.org/jira/browse/CODEC-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reopened CODEC-124: --- This will be for 2.0, not 1.6. Remove deprecated code for 2.0. --- Key: CODEC-124 URL: https://issues.apache.org/jira/browse/CODEC-124 Project: Commons Codec Issue Type: Task Affects Versions: 1.5, 1.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 2.0 Remove deprecated code for 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCS-83) Recovery Element from Lateral Auxiliary Cache when stop/start tomcat occurs
Recovery Element from Lateral Auxiliary Cache when stop/start tomcat occurs --- Key: JCS-83 URL: https://issues.apache.org/jira/browse/JCS-83 Project: JCS Issue Type: Wish Components: TCP Lateral Cache Affects Versions: jcs-1.3 Environment: Two Windows Servers with Tomcat 6 servers Reporter: Julio Matheus Vaz Assignee: Aaron Smuts This issue is relationed with #JCS-39 issue: https://issues.apache.org/jira/browse/JCS-39; I have declared a region with a TCP Lateral Cache Auxiliary with two separate servers. If the two Tomcats on the two machines are working than everything works fine. When one Tomcat update the cache it is seen also on the other Tomcat. Now the issue arises when I restart one of the Tomcats . Than it loses all cache elements and if I make a get to an element that exists in the other Tomcat I get a null. My allowGet flag is set to True but it still not works. In my opinion, something is missing in my cache.ccf, could you find out what is? Here is the cache.ccf file: # DEFAULT CACHE REGION # sets the default aux value for any non configured caches jcs.default=LTCP jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes jcs.default.cacheattributes.MaxObjects=100 jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache jcs.default.cacheattributes.UseLateral=true jcs.default.cacheattributes.UseRemote=false jcs.default.cacheattributes.UseDisk=false jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes jcs.default.elementattributes.IsEternal=false jcs.default.elementattributes.IsSpool=false jcs.default.elementattributes.IsRemote=false jcs.default.elementattributes.IsLateral=true #LTCP jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes jcs.auxiliary.LTCP.attributes.TcpListenerPort=1 jcs.auxiliary.LTCP.attributes.AllowGet=true jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=false jcs.auxiliary.LTCP.attributes.Receive=true jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.8 jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6780 jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true jcs.auxiliary.LTCP.attributes.FilterRemoveByHashCode=false jcs.auxiliary.LTCP.attributes.SocketTimeoOt=1001 jcs.auxiliary.LTCP.attributes.OpenTimeOut=2002 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-364) BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close())
BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close()) -- Key: DBCP-364 URL: https://issues.apache.org/jira/browse/DBCP-364 Project: Commons Dbcp Issue Type: Improvement Reporter: ori BasicDataSourceFactory#createDataSource currently returns a DataSource instance. It should a return type of BasicDataSourceFactory. Otherwise the caller has to cast it to invoke close (and other methods specific to the implementation). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-364) BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close())
[ https://issues.apache.org/jira/browse/DBCP-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ori updated DBCP-364: - Priority: Trivial (was: Major) BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close()) -- Key: DBCP-364 URL: https://issues.apache.org/jira/browse/DBCP-364 Project: Commons Dbcp Issue Type: Improvement Reporter: ori Priority: Trivial BasicDataSourceFactory#createDataSource currently returns a DataSource instance. It should a return type of BasicDataSourceFactory. Otherwise the caller has to cast it to invoke close (and other methods specific to the implementation). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-651) eigendecompimpl allocates space for array imagEigenvalues when it is not needed
eigendecompimpl allocates space for array imagEigenvalues when it is not needed --- Key: MATH-651 URL: https://issues.apache.org/jira/browse/MATH-651 Project: Commons Math Issue Type: Bug Affects Versions: 3.1 Environment: JAVA Reporter: greg sterijevski Priority: Minor Fix For: 3.1 The class variable imagEigenvalues is allocated even there is no use for it. I propose leaving the reference null. Patch will follow. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-651) eigendecompimpl allocates space for array imagEigenvalues when it is not needed
[ https://issues.apache.org/jira/browse/MATH-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] greg sterijevski updated MATH-651: -- Attachment: eigendecompimpl The patch with proposed changes... eigendecompimpl allocates space for array imagEigenvalues when it is not needed --- Key: MATH-651 URL: https://issues.apache.org/jira/browse/MATH-651 Project: Commons Math Issue Type: Bug Affects Versions: 3.1 Environment: JAVA Reporter: greg sterijevski Priority: Minor Labels: EIGENDECOMPOSITIONIMPL Fix For: 3.1 Attachments: eigendecompimpl The class variable imagEigenvalues is allocated even there is no use for it. I propose leaving the reference null. Patch will follow. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-652) Tridiagonal QR decomposition has a faulty test for zero...
[
https://issues.apache.org/jira/browse/MATH-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
greg sterijevski updated MATH-652:
--
Attachment: tridiagonal
Tridiagonal QR decomposition has a faulty test for zero...
---
Key: MATH-652
URL: https://issues.apache.org/jira/browse/MATH-652
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.1
Environment: JAVA
Reporter: greg sterijevski
Labels: TriDiagonalTransformer
Fix For: 3.1
Attachments: tridiagonal
Original Estimate: 1h
Remaining Estimate: 1h
In the method getQT() of TriDiagonalTransformer we have:
public RealMatrix getQT() {
if (cachedQt == null) {
final int m = householderVectors.length;
cachedQt = MatrixUtils.createRealMatrix(m, m);
// build up first part of the matrix by applying Householder
transforms
for (int k = m - 1; k = 1; --k) {
final double[] hK = householderVectors[k - 1];
cachedQt.setEntry(k, k, 1);
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
if (hK[k] != 0.0) {
double beta = 1.0 / secondary[k - 1];
The faulty line is : final double inv = 1.0 / (secondary[k - 1] * hK[k]);
It should be put after the test for the zero, eg:
public RealMatrix getQT() {
if (cachedQt == null) {
final int m = householderVectors.length;
cachedQt = MatrixUtils.createRealMatrix(m, m);
// build up first part of the matrix by applying Householder
transforms
for (int k = m - 1; k = 1; --k) {
final double[] hK = householderVectors[k - 1];
cachedQt.setEntry(k, k, 1);
if (hK[k] != 0.0) {
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
double beta = 1.0 / secondary[k - 1];
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-652) Tridiagonal QR decomposition has a faulty test for zero...
Tridiagonal QR decomposition has a faulty test for zero...
---
Key: MATH-652
URL: https://issues.apache.org/jira/browse/MATH-652
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.1
Environment: JAVA
Reporter: greg sterijevski
Fix For: 3.1
Attachments: tridiagonal
In the method getQT() of TriDiagonalTransformer we have:
public RealMatrix getQT() {
if (cachedQt == null) {
final int m = householderVectors.length;
cachedQt = MatrixUtils.createRealMatrix(m, m);
// build up first part of the matrix by applying Householder
transforms
for (int k = m - 1; k = 1; --k) {
final double[] hK = householderVectors[k - 1];
cachedQt.setEntry(k, k, 1);
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
if (hK[k] != 0.0) {
double beta = 1.0 / secondary[k - 1];
The faulty line is : final double inv = 1.0 / (secondary[k - 1] * hK[k]);
It should be put after the test for the zero, eg:
public RealMatrix getQT() {
if (cachedQt == null) {
final int m = householderVectors.length;
cachedQt = MatrixUtils.createRealMatrix(m, m);
// build up first part of the matrix by applying Householder
transforms
for (int k = m - 1; k = 1; --k) {
final double[] hK = householderVectors[k - 1];
cachedQt.setEntry(k, k, 1);
if (hK[k] != 0.0) {
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
double beta = 1.0 / secondary[k - 1];
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
