[jira] [Commented] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237481#comment-13237481 ] Moandji Ezana commented on DBUTILS-88: -- Does anything need to happen for this issue and DB-UTILS-87 to be committed? Make AsyncQueryRunner be a decorator around a QueryRunner - Key: DBUTILS-88 URL: https://issues.apache.org/jira/browse/DBUTILS-88 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Priority: Minor Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, DBUTILS-88v1.patch, DBUTILS-88v2.patch AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be possible for AsyncQueryRunner to simply decorate a QueryRunner with async functionality, in the same way a BufferedInputStream might decorate an InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237481#comment-13237481 ] Moandji Ezana edited comment on DBUTILS-88 at 3/24/12 8:53 AM: --- Does anything need to happen for this issue and DBUTILS-87 to be committed? was (Author: mwanji): Does anything need to happen for this issue and DB-UTILS-87 to be committed? Make AsyncQueryRunner be a decorator around a QueryRunner - Key: DBUTILS-88 URL: https://issues.apache.org/jira/browse/DBUTILS-88 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Priority: Minor Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, DBUTILS-88v1.patch, DBUTILS-88v2.patch AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be possible for AsyncQueryRunner to simply decorate a QueryRunner with async functionality, in the same way a BufferedInputStream might decorate an InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-84) Comment handling
Comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-247) [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
[ https://issues.apache.org/jira/browse/DAEMON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237540#comment-13237540 ] Mladen Turk commented on DAEMON-247: Not sure if [error] only would be enough. Think we should exit as well in case explicit JVM path was given and not found. [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error? -- Key: DAEMON-247 URL: https://issues.apache.org/jira/browse/DAEMON-247 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.9 Environment: Windows Server 2008 Service Pack 2, Java 6 update 31 and 7 update 3 installed on same machine. Tomcat 7.0.26 (which uses Daemon 1.0.9). Reporter: Nick Williams Original Estimate: 1h Remaining Estimate: 1h When running Tomcat as a service under Windows (thus using Daemon/procrun), if you mess up the Java Virtual Machine path in the service configurator, it defaults to the JAVA_HOME JRE, which I suppose is okay (but can wreak havoc when you have multiple Java versions installed), except that it doesn't warn you about it. It tells you about it through a DEBUG message, instead, so you have to actually increase the logging detail and wade through more messages to even realize it happened: [2012-03-20 16:32:41] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:32:41] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:32:41] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:32:41] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:32:41] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:32:41] [debug] ( javajni.c:195 ) Invalid RuntimeLib 'D:\Java\jdk6\jre\bin\server\jvm.dll' [2012-03-20 16:32:41] [debug] ( javajni.c:197 ) Using Jre JavaHome 'C:\Program Files\Java\jre7' [2012-03-20 16:32:41] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre7\bin\server\jvm.dll' After correcting the JVM path: [2012-03-20 16:46:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:46:13] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:46:13] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:46:13] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:46:13] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:46:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre6\bin\server\jvm.dll' IMO, this message should be a warning or even an error (preferable) so that server admins know right off the bat that they've done something wrong. Otherwise bad things might happen. Whether or not it should quit instead of defaulting to the system default JRE is a different discussion, but I think the message should at least be changed to a warning or an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-84) Comment handling
[
https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237549#comment-13237549
]
Sebb commented on CSV-84:
-
At present (r1304503), the comment introducer is not recognised whilst
processing a value.
It is only recognised at the start of a value.
This seems wrong, as it makes it impossible to add a trailing comment to the
end of a record without adding a preceeding delimiter. This is not consistent,
see below:
{code}
# No comment following, 4 values found
a,b,c,dEOL
d,e,f,g# comment treated as part of 4th valueEOL
h,i,j,k,# this will be recognised as a comment following 4 fieldsEOL
l,m,n,o,EOL
# previous line should have 5 fields but actually gets merged to previous line.
{code}
Comments currently only work correctly at the start of a record.
Comment handling
Key: CSV-84
URL: https://issues.apache.org/jira/browse/CSV-84
Project: Commons CSV
Issue Type: New Feature
Reporter: Sebb
Comment handling is not currently fully documented / tested.
There are several possible situations:
1) trailing comment following one or more values
2) comment marker starts in the first column
3) comment marker starts in the first non-whitespace column
How should these be handled?
1) The trailing comment should be ignored
2) Entire line should be ignored, i.e. don't treat it as a blank line
3) This is trickier: if whitespace is being trimmed, treat as 2, else treat
as 1, i.e. there is a single value containing whitespace
It might also be useful to consider returning comments to the application
program as part of CSVRecord.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-85) Allow comments to be returned in CSVRecord
Allow comments to be returned in CSVRecord -- Key: CSV-85 URL: https://issues.apache.org/jira/browse/CSV-85 Project: Commons CSV Issue Type: Improvement Reporter: Sebb It might be useful to provide a comment field in the CSVRecord class. This would be null if no comment is present for that record. A line consisting of only a comment would have a size() of 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-247) [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
[ https://issues.apache.org/jira/browse/DAEMON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237577#comment-13237577 ] Nick Williams commented on DAEMON-247: -- I can agree with that completely. It would certainly be the preferable behavior in our environment. And I imagine most other administrators of enterprise production systems would prefer it to fail loudly and obtrusively, instead of silently, when it has been configured incorrectly. [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error? -- Key: DAEMON-247 URL: https://issues.apache.org/jira/browse/DAEMON-247 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.9 Environment: Windows Server 2008 Service Pack 2, Java 6 update 31 and 7 update 3 installed on same machine. Tomcat 7.0.26 (which uses Daemon 1.0.9). Reporter: Nick Williams Assignee: Mladen Turk Original Estimate: 1h Remaining Estimate: 1h When running Tomcat as a service under Windows (thus using Daemon/procrun), if you mess up the Java Virtual Machine path in the service configurator, it defaults to the JAVA_HOME JRE, which I suppose is okay (but can wreak havoc when you have multiple Java versions installed), except that it doesn't warn you about it. It tells you about it through a DEBUG message, instead, so you have to actually increase the logging detail and wade through more messages to even realize it happened: [2012-03-20 16:32:41] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:32:41] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:32:41] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:32:41] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:32:41] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:32:41] [debug] ( javajni.c:195 ) Invalid RuntimeLib 'D:\Java\jdk6\jre\bin\server\jvm.dll' [2012-03-20 16:32:41] [debug] ( javajni.c:197 ) Using Jre JavaHome 'C:\Program Files\Java\jre7' [2012-03-20 16:32:41] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre7\bin\server\jvm.dll' After correcting the JVM path: [2012-03-20 16:46:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log initialized [2012-03-20 16:46:13] [info] ( prunsrv.c:1648) Commons Daemon procrun (1.0.9.0 64-bit) started [2012-03-20 16:46:13] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' Service... [2012-03-20 16:46:13] [debug] ( prunsrv.c:1345) Inside ServiceMain... [2012-03-20 16:46:13] [info] ( prunsrv.c:1089) Starting service... [2012-03-20 16:46:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program Files\Java\jre6\bin\server\jvm.dll' IMO, this message should be a warning or even an error (preferable) so that server admins know right off the bat that they've done something wrong. Otherwise bad things might happen. Whether or not it should quit instead of defaulting to the system default JRE is a different discussion, but I think the message should at least be changed to a warning or an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
[ https://issues.apache.org/jira/browse/MATH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237578#comment-13237578 ] Thomas Neidhart commented on MATH-773: -- Hi Reid, thanks for your contribution, this looks like a reasonable addition to the genetics package. After a short review of the patch, I think the endtime should not be determined at initialization time as this might lead to wrong results (as there might be a delay between creating the stopping condition and actually using it). Thomas You should be able to run evolution simulation for a certain amount of time. Key: MATH-773 URL: https://issues.apache.org/jira/browse/MATH-773 Project: Commons Math Issue Type: Improvement Reporter: Reid Hochstedler Labels: genetics Attachments: MATH-773.txt Original Estimate: 2h Remaining Estimate: 2h You should be able to run your GeneticAlgorithm for a fixed amount of time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-772) Change genetics component API to allow for different types of CrossoverPolicys and SelectionPolicys.
[ https://issues.apache.org/jira/browse/MATH-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237583#comment-13237583 ] Thomas Neidhart commented on MATH-772: -- Hi Reid, thanks again for your interest and contribution. We have to be a bit more careful with something like this, as this would affect the API, and we have just released version 3.0. Do you have a use-case where you would do a crossover from multiple parents? From my understanding this would be at least different from the general definition of a genetic algorithm. Thomas Change genetics component API to allow for different types of CrossoverPolicys and SelectionPolicys. Key: MATH-772 URL: https://issues.apache.org/jira/browse/MATH-772 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Reid Hochstedler Labels: api-change Attachments: MATH-772.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-508) GaussianFunction - Math FastMath
[ https://issues.apache.org/jira/browse/MATH-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-508. -- changing status to closed as 3.0 has been released GaussianFunction - Math FastMath -- Key: MATH-508 URL: https://issues.apache.org/jira/browse/MATH-508 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Ole Ersoy Priority: Trivial Fix For: 3.0 Attachments: GaussianFunction.patch Original Estimate: 0h Remaining Estimate: 0h Just changed Math to FastMath in the GaussianFunction implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-509) GaussianDerivativeFunction Math FastMath
[ https://issues.apache.org/jira/browse/MATH-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-509. -- changing status to closed as 3.0 has been released GaussianDerivativeFunction Math FastMath -- Key: MATH-509 URL: https://issues.apache.org/jira/browse/MATH-509 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Ole Ersoy Priority: Trivial Fix For: 3.0 Attachments: GaussianDerivativeFunction.patch Original Estimate: 0h Remaining Estimate: 0h -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-510) ParametricGaussianFunction Math FastMath
[ https://issues.apache.org/jira/browse/MATH-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-510. -- changing status to closed as 3.0 has been released ParametricGaussianFunction Math FastMath -- Key: MATH-510 URL: https://issues.apache.org/jira/browse/MATH-510 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Ole Ersoy Priority: Trivial Fix For: 3.0 Attachments: ParametricGaussianFunction.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-549) Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static
[ https://issues.apache.org/jira/browse/MATH-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-549. -- changing status to closed as 3.0 has been released Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static --- Key: MATH-549 URL: https://issues.apache.org/jira/browse/MATH-549 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Tomas Salfischberger Priority: Minor Fix For: 3.0 Making PearsonsCorrelation.correlation(double[], double[]) static would allow for calculating a correlation without instantiating a PearsonsCorrelation object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-657) Division by zero
[
https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-657.
--
changing status to closed as 3.0 has been released
Division by zero
Key: MATH-657
URL: https://issues.apache.org/jira/browse/MATH-657
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 3.0
In class {{Complex}}, division by zero always returns NaN. I think that it
should return NaN only when the numerator is also {{ZERO}}, otherwise the
result should be {{INF}}. See
[here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-632) NaN: Method equals in Complex not consistent with == for double primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-632.
--
changing status to closed as 3.0 has been released
NaN: Method equals in Complex not consistent with == for double
primitive type
Key: MATH-632
URL: https://issues.apache.org/jira/browse/MATH-632
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Priority: Minor
Fix For: 3.0
The following tests show several contradictions:
{code}
final double a = Double.NaN;
final double b = Double.NaN;
Assert.assertFalse(a == b, a == b); // (1)
Assert.assertEquals(a != b, a, b, Double.MIN_VALUE); // (2)
Assert.assertFalse(a == b, MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
Assert.assertFalse(a == b, MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
final Double dA = Double.valueOf(a);
final Double dB = Double.valueOf(b);
Assert.assertFalse(dA == dB, dA.doubleValue() == dB.doubleValue()); // (5)
Assert.assertTrue(!dA.equals(dB), dA.equals(dB)); // (6)
final Complex cA = new Complex(a, 0);
final Complex cB = new Complex(b, 0);
Assert.assertTrue(!cA.equals(cB), cA.equals(cB)); // (7)
{code}
They all pass; thus:
# Double does not behave as double: (1) and (5) vs (6)
# Two NaNs are almost equal for Junit: (2)
# Two NaNs are never equal for MathUtils: (3) and (4)
# Complex.NaN is consistent with Object Double.valueOf(NaN) (hence not with
primitive Double.NaN): (7)
This is quite confusing.
In MathUtils, we chose to follow IEEE754 (and Java for primitive double),
i.e. it is correct that assertion (1) is false. Do we want Complex to
conform with this or with the inconsistent behaviour of Double?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-754) Additional Fraction Constructor
[ https://issues.apache.org/jira/browse/MATH-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-754. -- changing status to closed as 3.0 has been released Additional Fraction Constructor --- Key: MATH-754 URL: https://issues.apache.org/jira/browse/MATH-754 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Environment: All Reporter: Travis Hanna Priority: Minor Labels: features, newbie, patch Fix For: 3.0 Attachments: math.patch I'm writing some code which outputs fractional measurements meant for human consumption. I need a constructor for Fraction which allows you to restrict the denominators to a finite set. This is necessary due to the fact that real-world tools are only available with certain fractions. For example, it's next to impossible to find a ruler with 1/7 inch marked :). I'm attaching a patch which implements the functionality. I've attempted to mimic the style of the existing code as much as possible. One caveat: I don't speak French so the french error message is a computer-generated translation and probably very poor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-725.
--
changing status to closed as 3.0 has been released
use initialized static final arrays, instead of initializing it in
constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
Fix For: 3.0
Original Estimate: 1h
Remaining Estimate: 1h
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-571) make FieldVector generic
[
https://issues.apache.org/jira/browse/MATH-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-571.
--
changing status to closed as 3.0 has been released
make FieldVector generic
Key: MATH-571
URL: https://issues.apache.org/jira/browse/MATH-571
Project: Commons Math
Issue Type: Improvement
Reporter: Arne Plöse
Priority: Minor
Fix For: 3.0
make FieldVector generic, so one can extend i.e. ArrayVieldVectorComplex to
ArrayComplexVector an introduce new methoids (getReal())...
if one has an equation complexvector.copy the original type
ArrayComplexVector is lost thus access to getReal() is not possible.
solution:
public class InheritationTest {
public static interface FieldVectorT extends FieldElementT, R extends
FieldVector {
R copy();
}
public abstract static class ArrayFieldVectorExtendableT extends
FieldElementT, R extends FieldVector implements FieldVectorT, R,
Serializable {
protected T[] data;
@Override
public R copy() {
return createVector(data);
}
abstract protected R createVector(T[] data);
}
public static class ArrayFieldVectorT extends FieldElementT extends
ArrayFieldVectorExtendableT, ArrayFieldVector {
@Override
protected ArrayFieldVectorT createVector(T[] data) {
ArrayFieldVectorT result = new ArrayFieldVectorT();
result.data = data;
return result;
}
}
public static class ArrayComplexVector extends
ArrayFieldVectorExtendableComplex, ArrayComplexVector {
@Override
protected ArrayComplexVector createVector(Complex[] data) {
ArrayComplexVector result = new ArrayComplexVector();
result.data = data;
return result;
}
public double[] getReal() {
return null;
}
public double[] getImaginary() {
return null;
}
}
public void test() {
ArrayComplexVector v = new ArrayComplexVector();
ArrayComplexVector v1 = v.copy(); // FiledVector type survives ...
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-747) Several Constructors for PoissonDistributionImpl are broken
[ https://issues.apache.org/jira/browse/MATH-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-747. -- changing status to closed as 3.0 has been released Several Constructors for PoissonDistributionImpl are broken --- Key: MATH-747 URL: https://issues.apache.org/jira/browse/MATH-747 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Steve Appling Priority: Critical Fix For: 3.0 Only the constructor PoissonDistributionImpl(double) seems to actually work. All of the others cause a NullPointerException. The working one creates a default NormalDistribution, but all of the others just leave the member normal set to null and cause an NPE in the constructor. I can't even find a work around to construct a PoissonDistributionImpl with both a specified mean and an epsilon, since there is no way to set epsilon after creation and the constructor PoissonDistributionImpl(double p, double epsilon) does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
