[jira] [Created] (LANG-733) Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
Key: LANG-733
URL: https://issues.apache.org/jira/browse/LANG-733
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.0
Reporter: Eugen Paraschiv
Fix For: 3.0.1
This method is missing from StringUtils. The corresponding method:
public static boolean containsAny(CharSequence cs, char... searchChars) {
does exist, so this was probably just forgotten.
Also
public static boolean containsIgnoreCase(CharSequence str, CharSequence...
searchStr) {
needs to be added as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-118) Provide an IN operator
Provide an IN operator -- Key: JEXL-118 URL: https://issues.apache.org/jira/browse/JEXL-118 Project: Commons JEXL Issue Type: New Feature Affects Versions: 2.0.1 Reporter: Max Tardiveau It would be very useful to have an IN operator, e.g.: status in ['A', 'B', 'C'] This can currently be done with : status == 'A' or status == 'B' or status == 'C' but (especially for longer lists) the IN operator would be more concise and more elegant. Extra bonus points, of course, if this works with variables, e.g.: status in possibleStatuses where possibleStatuses would be an object of type Collection. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dr. Dietmar Wolz updated MATH-621: -- Attachment: bobyqaoptimizer0.4.zip The attached new version contains three variants of BOBYQA implementing the MultivariateRealOptimizer together with their associated unit tests: BOBYQAOptimizerOld - essentially the previous version 0.3 with minor adaptions in the unit tests added for comparison. BOBYQAOptimizer - the actual version I use myself - all pointers are replaced by Java arrays. This version is much easier to read and faster than the old one. Nevertheless the finite state machine logic realized by the original code using gotos is still there - in Java realized using switch/case statements. BOBYQAOptimizerC - a version showing how MultivariateRealOptimizer can be implemented using the C-port of BOBYQA from the dlib library. The C++-code doing the mapping from Java to C++ to Java via JNI is also included. Some remarks: - all three versions are semantically equivalent - at least from the point of the actual unit test coverage. - the new Java version is about 30% faster than the old one - array access is cheaper than method calls simulating pointer arithmetic. - I observed a significant change of behaviour when statements like a = a+(b...) are replaced by a += (b...). Subtle accuracy differences add up during the optimization process. - The C version was tested both on Mac (Snow Leopard) and Windows7, both for 32 and 64-bit Java. For 64bit the Microsoft C++-compiler produced correct results only if optimization is switched off completely, on the Mac the gnu compiler works correctly using -O3. - On the Mac (a Macbook pro with a new sandy bridge processor) the C-version performs the unit tests three times faster than the (new) Java version. The difference on Win7 is much smaller, since I couldn't use compiler optimization there yet. The performance difference is not significant for my own application of the algo (space flight trajectory optimization) because of the high cost for the eval function. But this is perhaps not true for all other applications. So if we want to include BOBYQA in commons.math in my opinion we shouldn't neglect performance issues generally. Even a direct port of the code has a significant performance disadvantage, any refactoring should try to avoid adding too much additional performance bottlenecks. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more
[jira] [Updated] (JEXL-118) Provide an IN operator
[ https://issues.apache.org/jira/browse/JEXL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Tardiveau updated JEXL-118: --- Description: It would be very useful to have an IN operator, e.g.: status in ['A', 'B', 'C'] that would return a boolean. This can currently be done with : status == 'A' or status == 'B' or status == 'C' but (especially for longer lists) the IN operator would be more concise and more elegant. Extra bonus points, of course, if this works with variables, e.g.: status in possibleStatuses where possibleStatuses would be an object of type Collection. was: It would be very useful to have an IN operator, e.g.: status in ['A', 'B', 'C'] This can currently be done with : status == 'A' or status == 'B' or status == 'C' but (especially for longer lists) the IN operator would be more concise and more elegant. Extra bonus points, of course, if this works with variables, e.g.: status in possibleStatuses where possibleStatuses would be an object of type Collection. Provide an IN operator -- Key: JEXL-118 URL: https://issues.apache.org/jira/browse/JEXL-118 Project: Commons JEXL Issue Type: New Feature Affects Versions: 2.0.1 Reporter: Max Tardiveau Labels: features It would be very useful to have an IN operator, e.g.: status in ['A', 'B', 'C'] that would return a boolean. This can currently be done with : status == 'A' or status == 'B' or status == 'C' but (especially for longer lists) the IN operator would be more concise and more elegant. Extra bonus points, of course, if this works with variables, e.g.: status in possibleStatuses where possibleStatuses would be an object of type Collection. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073351#comment-13073351
]
Gilles commented on MATH-621:
-
{quote}
BOBYQAOptimizer - the actual version I use myself - all pointers are replaced
by Java arrays. This version is much easier to read and faster than the old
one.
{quote}
:( It's a pity that you didn't mention this version earlier; I already spent
quite a few hours replacing the ScopedPtr variables. Only a few of them
remains in my working version: namely, those that are created as offsets in w
before calling trsbox, rescue, altmov and update.
Since I also made a few other changes along the way, I don't feel like starting
all (almost) over again...
Hence, I'll continue with my incremental changes; but, at some point, I could
use some help to convert the state machine code into proper function calls.
IMO, we should first arrive at a clearer code before worrying about performance
(the more so that, as you pointed out, this algorithm will probably be put to
use when function evaluation is expensive, overwhelming the optimizer's code
running time).
The refactoring from efficient Fortran to (very probably less efficient) Java
is a big effort but it's indispensable: If it were not to become understandable
and maintainable, I don't see the point in including it in CM; you could just
provide the straight translation in a JAR file and people would use it as a
black box.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073353#comment-13073353 ] Gilles commented on MATH-637: - Thanks. Applied in revision 1152584. Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Labels: test Fix For: 3.0 Attachments: PerfUtils.patch As per the discussion on the dev ML (with subject: Simple benchmarking utility), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the src/test/java part of the code repository. -- 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 ] Matthew Pocock updated CODEC-125: - Attachment: acz.patch This should fix the problem with acz encoding. The bug was actually to do with language guessing. This very short string couldn't be assigned a language. The PHP code defaults to 'ANY' but in the recent rewrite I'd accidentally knobbled this to 'NONE'. 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: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, 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=13073380#comment-13073380 ] Tamas Kende commented on CODEC-125: --- Matthew: Sorry I forget to write down how did I found the ácz/átz bug. I tried to encode the Hungarian first name: Ignácz (Ignátz) it is in an old spelling (currently it is written as Ignác). So it is not short and could be guessed with language guessing. 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: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, 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-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073381#comment-13073381 ] Phil Steitz commented on MATH-621: -- I agree strongly with Gilles comment on maintainability. At apache, our goal is to develop software that can be maintained by a group of volunteers that changes over time. In [math], that means algorithms need to be documented and it has to be possible for a Java developer with sufficient mathematical knowledge to read the references and javadoc and make sense of the code. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- 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=13073383#comment-13073383 ] Matthew Pocock commented on CODEC-125: -- Tamas, We can add Ignácz, Ignátz and Ignác as test-cases if you'd like. I think the original rules where set up with family names in mind, but I'm happy to see as many names added as we reasonably can. You should be able to add test-cases to PhoneticEngineTest - there's an array where you can put in new example names and the string they should encode to. 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: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, 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-599) Re-implementation of Secant-based root finding algorithms
[ https://issues.apache.org/jira/browse/MATH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073393#comment-13073393 ] Gilles commented on MATH-599: - AllowedSolutions changed toAllowedSolution in revision 1152644. Re-implementation of Secant-based root finding algorithms - Key: MATH-599 URL: https://issues.apache.org/jira/browse/MATH-599 Project: Commons Math Issue Type: Improvement Reporter: Dennis Hendriks Labels: documentation, patch Fix For: 3.0 Attachments: secant-based-root-finding-algos.patch, secant-based-root-finding-algos2.patch, secant-based-root-finding-algos2.zip Apache Commons Math currently has a SecantSolver. It is unclear exactly what algorithm this solver implements. It states: The algorithm is modified to maintain bracketing of a root by successive approximations. Because of forced bracketing, convergence may be slower than the unrestricted Secant algorithm. However, this implementation should in general outperform the Regula Falsi method. The Regula Falsi method is exactly the Secant method modified to maintain a bracketed solution. It is therefore unclear what other modifications were done to make it 'better' than the Regula Falsi method. Besides the Secant and Regula Falsi methods, several other Secant-based root-finding algorithms exist, such as the the Illinois method, and the Pegasus method. All 4 are well-known, publisched algorithms. I created a patch, which changes the following: - Removed SecantSolver root-finding algorithm. - Implemented new Secant-based root-finding algorithms: SecantSolver, RegulaFalsiSolver, IllinoisSolver, and PegasusSolver. - Introduced BracketedSolution interface and AllowedSolutions enumeration, to control allowed solutions (under-approximations and over-approximations) for bracketed root-finding algorithms. Implemented for RegulaFalsiSolver, IllinoisSolver, and PegasusSolver. - Fixed documentation of BaseUnivariateRealSolver.solve methods, such that documentation order of arguments matches the order of the actual arguments. Note that the original SecantSolver was removed, and replaced by a root-finding algorithm that actually implements the Secant root-finding algorithm. As such, existing code using the SecantSolver is not backwards compatible. That is, even though the new SecantSolver does implement the same interfaces, the root-finding solutions may differ. In particular, the new SecantSolver does not maintain a bracketed solution, and does not guarantee convergence. I added unit tests, and I did a build, including checkstyle checking. I did not fix all checkstyle warnings though, as I consider some of them false positives. -- 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=13073397#comment-13073397 ] Gary D. Gregory commented on CODEC-125: --- Patch applied for https://issues.apache.org/jira/browse/CODEC-125?focusedCommentId=13073380page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13073380 Thank you Matthew for coding. Thank you Tamas for testing. Please submit more unit tests. You can also check the new tests I added which may make no sense in the context of this encoder. Please check testAsciiEncodeNotEmpty1Letter. Since we have problems with short strings, I added more tests. 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: acz.patch, bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, majorFix.patch, 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] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073430#comment-13073430 ] Stefan Bodewig commented on COMPRESS-36: The ZIP64 branch has been merged back to trunk. Current status: ZipArchiveInputStream looks good, ZipArchiveOutputStream is almost complete, need to decide how to handle the case of DEFLATED entries with unknown size when we are writing to a stream as I don't see any way to decide without user intervention whether we should enable ZIP64 or not. Add Zip64 Suport Key: COMPRESS-36 URL: https://issues.apache.org/jira/browse/COMPRESS-36 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Christian Grobmeier Assignee: Stefan Bodewig Fix For: 1.3 Attachments: 5GB_of_Zeros.zip, zip64-sample.zip Add Zip64 support. This will make it work to deal with zipfiles 2 GB. Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
