[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097791#comment-13097791
]
Olivier Lamy commented on OGNL-20:
--
good idea ! I will try a patch or a branch with that.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097795#comment-13097795
]
Maurizio Cucchiara edited comment on OGNL-20 at 9/6/11 8:21 AM:
Hi Olivier,
be aware that there is already:
# a [patch|WW-3580] which sensibly reduces the synchronized code using
something like the double check idiom.
# an old [opensymphony patch|http://jira.opensymphony.com/browse/OGNL-101]
which, if I recall correctly, uses concurrent version of the map implementation.
It would be very interesting to compare this 3 different approaches. Before
that, I think we would need a performance test bench.
was (Author: maurizio.cucchiara):
Hi Olivier,
be aware that there is already:
# a [patch|WW-3580] which sensibly reduces the synchronized code using
something like the double check idiom.
# an old [opensymphony patch|http://jira.opensymphony.com/browse/OGNL-101]
which, if I recall correctly, uses concurrent version of the map implementation.
It would be very interesting to compare this 3 different approaches. Before
that, I think we would need a performance test bench.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097795#comment-13097795
]
Maurizio Cucchiara commented on OGNL-20:
Hi Olivier,
be aware that there is already:
# a [patch|WW-3580] which sensibly reduces the synchronized code using
something like the double check idiom.
# an old [opensymphony patch|http://jira.opensymphony.com/browse/OGNL-101]
which, if I recall correctly, uses concurrent version of the map implementation.
It would be very interesting to compare this 3 different approaches. Before
that, I think we would need a performance test bench.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097809#comment-13097809
]
Julien Aymé commented on OGNL-20:
-
Note that you also could use ConcurrentHashMap instead of HashMap. Also, since
in many place it is not harmful if the cached object is evaluated twice, you
can remove the whole synchronized block:
cache = new ConcurrentHashMap();
Object cachedObject = cache.get(key);
if (null == cachedObject) {
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097809#comment-13097809
]
Julien Aymé edited comment on OGNL-20 at 9/6/11 8:50 AM:
-
Note that you also could use ConcurrentHashMap instead of HashMap. Also, since
in many place it is not harmful if the cached object is evaluated twice, you
can remove the whole synchronized block:
{code}
// When initializing the cache:
cache = new ConcurrentHashMap();
// Looking up into the cache
Object cachedObject = cache.get(key);
if (null == cachedObject) {
// No need to use a synchronized block here if we don't care that the
getRealObject method is invoked more than once.
Object realObject = getRealObject(key);
cache.put(key, realObject);
cachedObject = realObject;
}
return cachedObject;
{code}
As shown above, the use of a ConcurrentHashMap allows to discard any
synchronized block, and any custom lock use.
HTH,
Regards,
Julien
was (Author: julien.a...@gmail.com):
Note that you also could use ConcurrentHashMap instead of HashMap. Also,
since in many place it is not harmful if the cached object is evaluated twice,
you can remove the whole synchronized block:
cache = new ConcurrentHashMap();
Object cachedObject = cache.get(key);
if (null == cachedObject) {
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-55) split the huge project in submodules
[ https://issues.apache.org/jira/browse/CHAIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097812#comment-13097812 ] Simone Tripodi commented on CHAIN-55: - I tend to agree, those parts have too much in common that extracting the core, then including it in each other, would be an overkill. Moreover, as you wrote in the ML, probably there are no users on upgrading the web part except Struts1.X community - and it is known Struts1.X is no more active. As you wrote in the ML: it's maybe time to speak about totally dropping the web module in v2.0? what someone else thinks about it? Keeping it just because 'it exists' shouldn't be enough to justify its existence if no users community is interested anymore... > split the huge project in submodules > > > Key: CHAIN-55 > URL: https://issues.apache.org/jira/browse/CHAIN-55 > Project: Commons Chain > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.0 > > > As discussed in the [dev ML|http://markmail.org/message/pnyin5xzmxt2up5q], > there is a general agreement between people interested on chain, on splitting > the huge component in small submodules, in order to have a lightweight, > dependencies-less (unless the logging library, if required) and > self-contained core module, and users interested on core APIs only don't need > to bring unused code in their applications. SUggested modules are: > * core APIs; > * XML configuration APIs (depends from Digester); > * servlet (depends from Servlet APIs); > * portlet (depends from Portlet APIs); > * faces (depends from Faces APIs). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097814#comment-13097814
]
Maurizio Cucchiara commented on OGNL-20:
Hi Julien,
that was my original thought, furthermore we could use putIfAbsent method of
CHM.
What do you think, guys?
Anyway we should discuss about it in just one issue.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-658) Dead code in FastMath.pow(double, double) and some improvement in test coverage
Dead code in FastMath.pow(double, double) and some improvement in test coverage
---
Key: MATH-658
URL: https://issues.apache.org/jira/browse/MATH-658
Project: Commons Math
Issue Type: Improvement
Reporter: Yannick TANGUY
Priority: Minor
Fix For: 3.0
This issue concerns the FastMath class and its test class.
I don't know how to attach source code to an issue : sorry if it's not easy to
read...
(1) In the double pow(double, double) function, there are 2 identical "if"
blocks. The second one can be suppressed.
if (y < 0 && y == yi && (yi & 1) == 1) {
return Double.NEGATIVE_INFINITY;
}
// this block is never used -> to be suppressed
if (y < 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
if (y > 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
(2) To obtain better code coverage, we added some tests case in
FastMathTest.java :
/**
* Added test for log1p
*/
@Test
public void testLog1pSpecialCases() {
double x;
x = FastMath.log1p(-1.0);
if (x != Double.NEGATIVE_INFINITY)
throw new RuntimeException("Log1p of -1 should be -infinity");
}
public void testPowSpecialCases() {
// [ ... ]
// Added tests for a 100% coverage
x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(+Inf, NaN) should be NaN");
x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(+Inf, NaN) should be NaN");
x = FastMath.pow(1.0, Double.POSITIVE_INFINITY);
if (x == x)
throw new RuntimeException("pow(1.0, +Inf) should be NaN");
x = FastMath.pow(Double.NEGATIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(-Inf, NaN) should be NaN");
x = FastMath.pow(Double.NEGATIVE_INFINITY, -1.0);
if (x != -0.0)
throw new RuntimeException("pow(-Inf, -1.0) should be 0.0");
x = FastMath.pow(Double.NEGATIVE_INFINITY, -2.0);
if (x != 0.0)
throw new RuntimeException("pow(-Inf, -2.0) should be 0.0");
x = FastMath.pow(Double.NEGATIVE_INFINITY, 1.0);
if (x != Double.NEGATIVE_INFINITY)
throw new RuntimeException("pow(-Inf, 1.0) should be -Inf");
x = FastMath.pow(Double.NEGATIVE_INFINITY, 2.0);
if (x != Double.POSITIVE_INFINITY)
throw new RuntimeException("pow(-Inf, 2.0) should be +Inf");
x = FastMath.pow(1.0, Double.NEGATIVE_INFINITY);
if (x == x)
throw new RuntimeException("pow(1.0, -Inf) should be NaN");
}
/**
* Added tests for a 100% coverage of acos().
*/
@Test
public void testAcosSpecialCases() {
double x;
x = FastMath.acos(Double.NaN);
if (x == x)
throw new RuntimeException("acos(NaN) should NaN");
x = FastMath.acos(-1.1);
if (x == x)
throw new RuntimeException("acos(-1.1) should NaN");
x = FastMath.acos(1.1);
if (x == x)
throw new RuntimeException("acos(-1.1) should NaN");
assertEquals(FastMath.acos(-1.0), FastMath.PI, Double.MIN_VALUE);
assertEquals(FastMath.acos(1.0), 0.0, Double.MIN_VALUE);
assertEquals(FastMath.acos(0.0), FastMath.PI / 2.0, Double.MIN_VALUE);
}
/**
* Added tests for a 100% coverage of asin().
*/
@Test
public void testAsinSpecialCases() {
double x;
x = FastMath.asin(Double.NaN);
if (x == x)
throw new RuntimeException("asin(NaN) should NaN");
x = FastMath.asin(-1.1);
if (x == x)
throw new RuntimeException("asin(-1.1) should NaN");
x = FastMath.asin(1.1);
if (x == x)
throw new RuntimeException("asin(-1.1) should NaN");
assertEquals(FastMath.asin(1.0), FastMath.PI / 2.0, Double.MIN_VALUE);
assertEquals(FastMath.asin(-1.0), -FastMath.PI / 2.0, Double.MIN_VALUE);
assertEquals(FastMath.asin(0.0), 0.0, Double.MIN_VALUE);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-658) Dead code in FastMath.pow(double, double) and some improvement in test coverage
[
https://issues.apache.org/jira/browse/MATH-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yannick TANGUY updated MATH-658:
Attachment: FastMathTest.java
This class contains some new tests to improve test coverage
> Dead code in FastMath.pow(double, double) and some improvement in test
> coverage
> ---
>
> Key: MATH-658
> URL: https://issues.apache.org/jira/browse/MATH-658
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Yannick TANGUY
>Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathTest.java
>
>
> This issue concerns the FastMath class and its test class.
> I don't know how to attach source code to an issue : sorry if it's not easy
> to read...
> (1) In the double pow(double, double) function, there are 2 identical "if"
> blocks. The second one can be suppressed.
> if (y < 0 && y == yi && (yi & 1) == 1) {
> return Double.NEGATIVE_INFINITY;
> }
> // this block is never used -> to be suppressed
> if (y < 0 && y == yi && (yi & 1) == 1) {
> return -0.0;
> }
> if (y > 0 && y == yi && (yi & 1) == 1) {
> return -0.0;
> }
> (2) To obtain better code coverage, we added some tests case in
> FastMathTest.java :
> /**
> * Added test for log1p
> */
> @Test
> public void testLog1pSpecialCases() {
> double x;
>
> x = FastMath.log1p(-1.0);
> if (x != Double.NEGATIVE_INFINITY)
> throw new RuntimeException("Log1p of -1 should be -infinity");
> }
> public void testPowSpecialCases() {
>
> // [ ... ]
>// Added tests for a 100% coverage
>
> x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
> if (x == x)
> throw new RuntimeException("pow(+Inf, NaN) should be NaN");
>
> x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
> if (x == x)
> throw new RuntimeException("pow(+Inf, NaN) should be NaN");
>
> x = FastMath.pow(1.0, Double.POSITIVE_INFINITY);
> if (x == x)
> throw new RuntimeException("pow(1.0, +Inf) should be NaN");
>
> x = FastMath.pow(Double.NEGATIVE_INFINITY, Double.NaN);
> if (x == x)
> throw new RuntimeException("pow(-Inf, NaN) should be NaN");
>
> x = FastMath.pow(Double.NEGATIVE_INFINITY, -1.0);
> if (x != -0.0)
> throw new RuntimeException("pow(-Inf, -1.0) should be 0.0");
>
> x = FastMath.pow(Double.NEGATIVE_INFINITY, -2.0);
> if (x != 0.0)
> throw new RuntimeException("pow(-Inf, -2.0) should be 0.0");
>
> x = FastMath.pow(Double.NEGATIVE_INFINITY, 1.0);
> if (x != Double.NEGATIVE_INFINITY)
> throw new RuntimeException("pow(-Inf, 1.0) should be -Inf");
>
> x = FastMath.pow(Double.NEGATIVE_INFINITY, 2.0);
> if (x != Double.POSITIVE_INFINITY)
> throw new RuntimeException("pow(-Inf, 2.0) should be +Inf");
> x = FastMath.pow(1.0, Double.NEGATIVE_INFINITY);
> if (x == x)
>throw new RuntimeException("pow(1.0, -Inf) should be NaN");
>}
>
> /**
> * Added tests for a 100% coverage of acos().
> */
> @Test
> public void testAcosSpecialCases() {
> double x;
> x = FastMath.acos(Double.NaN);
> if (x == x)
> throw new RuntimeException("acos(NaN) should NaN");
> x = FastMath.acos(-1.1);
> if (x == x)
> throw new RuntimeException("acos(-1.1) should NaN");
>
> x = FastMath.acos(1.1);
> if (x == x)
> throw new RuntimeException("acos(-1.1) should NaN");
>
> assertEquals(FastMath.acos(-1.0), FastMath.PI, Double.MIN_VALUE);
> assertEquals(FastMath.acos(1.0), 0.0, Double.MIN_VALUE);
> assertEquals(FastMath.acos(0.0), FastMath.PI / 2.0, Double.MIN_VALUE);
> }
>
> /**
> * Added tests for a 100% coverage of asin().
> */
> @Test
> public void testAsinSpecialCases() {
> double x;
> x = FastMath.asin(Double.NaN);
> if (x == x)
> throw new RuntimeException("asin(NaN) should NaN");
> x = FastMath.asin(-1.1);
> if (x == x)
> throw new RuntimeException("asin(-1.1) should NaN");
>
> x = FastMath.asin(1.1);
> if (x == x)
> throw new RuntimeException("asin(-1.1) should NaN");
>
> assertEquals(FastMath.asin(1.0), FastMath.PI / 2.0, Double.MIN_VALUE);
> assertEquals(FastMath.asin(-1.0), -FastMath.PI / 2.0, Double.MIN_VALUE);
>
[jira] [Updated] (MATH-658) Dead code in FastMath.pow(double, double) and some improvement in test coverage
[
https://issues.apache.org/jira/browse/MATH-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yannick TANGUY updated MATH-658:
Description:
This issue concerns the FastMath class and its test class.
(1) In the double pow(double, double) function, there are 2 identical "if"
blocks. The second one can be suppressed.
if (y < 0 && y == yi && (yi & 1) == 1) {
return Double.NEGATIVE_INFINITY;
}
// this block is never used -> to be suppressed
if (y < 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
if (y > 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
(2) To obtain better code coverage, we added some tests case in
FastMathTest.java (see attached file)
- Added test for log1p
- Added tests in testPowSpecialCases()
- Added tests for a 100% coverage of acos().
- Added tests for a 100% coverage of asin().
was:
This issue concerns the FastMath class and its test class.
I don't know how to attach source code to an issue : sorry if it's not easy to
read...
(1) In the double pow(double, double) function, there are 2 identical "if"
blocks. The second one can be suppressed.
if (y < 0 && y == yi && (yi & 1) == 1) {
return Double.NEGATIVE_INFINITY;
}
// this block is never used -> to be suppressed
if (y < 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
if (y > 0 && y == yi && (yi & 1) == 1) {
return -0.0;
}
(2) To obtain better code coverage, we added some tests case in
FastMathTest.java :
/**
* Added test for log1p
*/
@Test
public void testLog1pSpecialCases() {
double x;
x = FastMath.log1p(-1.0);
if (x != Double.NEGATIVE_INFINITY)
throw new RuntimeException("Log1p of -1 should be -infinity");
}
public void testPowSpecialCases() {
// [ ... ]
// Added tests for a 100% coverage
x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(+Inf, NaN) should be NaN");
x = FastMath.pow(Double.POSITIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(+Inf, NaN) should be NaN");
x = FastMath.pow(1.0, Double.POSITIVE_INFINITY);
if (x == x)
throw new RuntimeException("pow(1.0, +Inf) should be NaN");
x = FastMath.pow(Double.NEGATIVE_INFINITY, Double.NaN);
if (x == x)
throw new RuntimeException("pow(-Inf, NaN) should be NaN");
x = FastMath.pow(Double.NEGATIVE_INFINITY, -1.0);
if (x != -0.0)
throw new RuntimeException("pow(-Inf, -1.0) should be 0.0");
x = FastMath.pow(Double.NEGATIVE_INFINITY, -2.0);
if (x != 0.0)
throw new RuntimeException("pow(-Inf, -2.0) should be 0.0");
x = FastMath.pow(Double.NEGATIVE_INFINITY, 1.0);
if (x != Double.NEGATIVE_INFINITY)
throw new RuntimeException("pow(-Inf, 1.0) should be -Inf");
x = FastMath.pow(Double.NEGATIVE_INFINITY, 2.0);
if (x != Double.POSITIVE_INFINITY)
throw new RuntimeException("pow(-Inf, 2.0) should be +Inf");
x = FastMath.pow(1.0, Double.NEGATIVE_INFINITY);
if (x == x)
throw new RuntimeException("pow(1.0, -Inf) should be NaN");
}
/**
* Added tests for a 100% coverage of acos().
*/
@Test
public void testAcosSpecialCases() {
double x;
x = FastMath.acos(Double.NaN);
if (x == x)
throw new RuntimeException("acos(NaN) should NaN");
x = FastMath.acos(-1.1);
if (x == x)
throw new RuntimeException("acos(-1.1) should NaN");
x = FastMath.acos(1.1);
if (x == x)
throw new RuntimeException("acos(-1.1) should NaN");
assertEquals(FastMath.acos(-1.0), FastMath.PI, Double.MIN_VALUE);
assertEquals(FastMath.acos(1.0), 0.0, Double.MIN_VALUE);
assertEquals(FastMath.acos(0.0), FastMath.PI / 2.0, Double.MIN_VALUE);
}
/**
* Added tests for a 100% coverage of asin().
*/
@Test
public void testAsinSpecialCases() {
double x;
x = FastMath.asin(Double.NaN);
if (x == x)
throw new RuntimeException("asin(NaN) should NaN");
x = FastMath.asin(-1.1);
if (x == x)
throw new RuntimeException("asin(-1.1) should NaN");
x = FastMath.asin(1.1);
if (x == x)
throw new RuntimeException("asin(-1.1) should NaN");
asser
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097868#comment-13097868
]
Adrian Crum commented on OGNL-20:
-
I highly recommend reading Java Concurrency In Practice
(http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=sr_1_1?ie=UTF8&qid=1315303458&sr=8-1)
and Concurrent Programming In Java
(http://www.amazon.com/Concurrent-Programming-Java-Principles-Pattern/dp/0201310090/ref=sr_1_1?s=books&ie=UTF8&qid=1315303737&sr=1-1)
- a book written by the author of ConcurrentHashMap.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
cli's with last option as list type values and have argument are not parsed
correctly
-
Key: CLI-221
URL: https://issues.apache.org/jira/browse/CLI-221
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.2
Reporter: Gagan Jain
I have set the value separator for an option to be comma (',').
Consider the following cli:
cli definition : cmd1 -o1 a1
command name: 'cmd1'
options: 'o1' accpets list of values separated by ','
arguments: 'a1' single valued argument
cmd1 -o1 o1v1,o1v2,o1v3 a1v1
GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
instead of {o1v1,o1v2,o1v3}
Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
public void processArgs(Option opt, ListIterator iter) throws ParseException
{
// loop until an option is found
while (iter.hasNext())
{
String str = (String) iter.next();
// found an Option, not an argument
if (getOptions().hasOption(str) && str.startsWith("-"))
{
iter.previous();
break;
}
// found a value
try
{
opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
}
catch (RuntimeException exp)
{
iter.previous();
break;
}
}
if (opt.getValues() == null && !opt.hasOptionalArg())
{
throw new MissingArgumentException(opt);
}
}
In my opinion, if a value separator is defined for option, and is other than
space (' '), loop should break immediately after one iteration.
Correct me, if I am wrong in my understanding.
--
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-tabpanel&focusedCommentId=13097913#comment-13097913 ] Nigel Goodwin commented on MATH-621: I've found what i think is a bug, no doubt arising from the change to zero based indexing. Line 541 should read: curv = hq.getEntry((j + 1 + (j +1) * (j+ 1)) / 2 - 1); It is clear that, when this loop is encountered with j=0, the original code: curv = hq.getEntry((j + j * j) / 2 - 1); will cause an array out of bounds exception. As far as i can make out, it is indexing the diagonal elements of the second derivative matrix. There may be a similar bug in line 1777, but I think I wexercise this code and have not had an exception. Worth checking. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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] [Updated] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gagan Jain updated CLI-221:
---
Component/s: CLI-2.x
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-2.x, Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
> Labels: bug, cli2, list, parser
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> cmd1 -o1 o1v1,o1v2,o1v3 a1v1
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> public void processArgs(Option opt, ListIterator iter) throws ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
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-tabpanel&focusedCommentId=13097966#comment-13097966
]
Gilles commented on MATH-621:
-
You are right that there is a bug, but comparing with the original Fortran, I
think that the line should rather read:
{code}
curv = hq.getEntry((j + j * j) / 2);
{code}
Unfortunately, this statement is in a code path that is not explored by the
current unit tests.
By the way, when writing code excerpts here, don't forget to enclose them
within the appropriate tag:
{noformat}
{code}
// Code goes here
{code}
{noformat}
Otherwise it can get scrambled...
For the other line, I have no idea.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097973#comment-13097973 ] Gilles commented on MATH-621: - Fixed first reported bug in revision 1165656. Thanks. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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] [Issue Comment Edited] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097998#comment-13097998
]
Simone Tripodi edited comment on OGNL-20 at 9/6/11 1:30 PM:
+1 to {{ReentrantReadWriteLocks}}.
IMHO
{code}
Map _methodParameterTypesCache = new HashMap();
synchronized (_methodParameterTypesCache)
{
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
}
{code}
and
{code}
Map _methodParameterTypesCache = new ConcurrentHashMap();
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get(m) ) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
{code}
have totally different semantics. In one case, you synchronized the whole block
- including the checks - in the second one, just limited the map accesses.
Am I wrong? If yes, why?
was (Author: simone.tripodi):
+1 to {{ReentrantReadWriteLocks}}.
IMHO
{code}
Map _methodParameterTypesCache = new HashMap();
synchronized (_methodParameterTypesCache)
{
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
}
{code}
and
{code}
Map _methodParameterTypesCache = new HashMap();
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get(m) ) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
{code}
have totally different semantics. In one case, you synchronized the whole block
- including the checks - in the second one, just limited the map accesses.
Am I wrong? If yes, why?
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097998#comment-13097998
]
Simone Tripodi commented on OGNL-20:
+1 to {{ReentrantReadWriteLocks}}.
IMHO
{code}
Map _methodParameterTypesCache = new HashMap();
synchronized (_methodParameterTypesCache)
{
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
}
{code}
and
{code}
Map _methodParameterTypesCache = new HashMap();
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get(m) ) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
{code}
have totally different semantics. In one case, you synchronized the whole block
- including the checks - in the second one, just limited the map accesses.
Am I wrong? If yes, why?
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098009#comment-13098009
]
Julien Aymé commented on OGNL-20:
-
@Maurizio:
Yes, putIfAbsent is a good idea !
@Simone,
you are not wrong, the two cases do have different semantics.
The thing is, we don't really care if some threads do the same computation at
the same time.
What we really want is to speed up every thread in the long run (hence the
caching) :
- 1. avoid computation twice for the same thread
- 2. ensure that any computed object is available for other threads : the use
of ConcurrentHashMap allows exactly that
- 3. avoid blocking another thread which may not require the same object (if
distinct key) : to do so, if we can avoid using any synchronized block or any
lock it is better !
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Plöse updated MATH-620:
Attachment: ComplexOctaveTest.java
Here is the comparision between commons math and octave.
I hope this what you want Gilles ;-).
> multiplication of infinity
> --
>
> Key: MATH-620
> URL: https://issues.apache.org/jira/browse/MATH-620
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Arne Plöse
>Priority: Minor
> Attachments: ComplexOctaveTest.java
>
>
> Take the following testcase
> {code}
> Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // <--Passes
> ordinary double
> Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
> Complex(neginf, 0)));// <-- Fail only real parts no imaginary parts
> {code}
> The outcome of multiply is Complex.INF if one part is infinity.
> why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098029#comment-13098029
]
Simone Tripodi commented on OGNL-20:
Salut Julien!
of course I understand the reasons - especially #3 is crucial - and yes
{{puIfAbsent}} would fix the concurrency issue.
Anyway, getting/setting to/from Maps always has complexity O(1), comparing null
objects has complexity O(1) - are we sure, in that specific case, that avoid
the use of a lock improves the performances so much? Moreover, reading from
{{puIfAbsent}} javadoc:
{quote}
If the specified key is not already associated with a value, associate it with
the given value. This is equivalent to
if (!map.containsKey(key))
return map.put(key, value);
else
return map.get(key);
except that the action is performed atomically.
{quote}
that doesn't look so different from the {{synchronized}} code above - unless
you tell me that {{puIfAbsent}} atomicity is implemented using
super-internal-APIs that I don't know - and avoid the lock, that's the critical
point - and for wich I apologize in advance for my ignorance.
Concluding: agreed on replacing data structures to increase code
maintainability and readability - patches are welcome and I invite you to
submit! - not sure to see performances increased in that specific case.
Good catch!
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098040#comment-13098040
]
Julien Aymé commented on OGNL-20:
-
Hi Simone !
You got it right for the main part, except that the most costly operation in
the algorithm is the computation (or it is assumed to be so): The cost of
accessing / comparing / puting in the map is nothing compared to the
computation itself. That's why, the point to remove any synchronized block at
all is to avoid the cost of the computation itself (in other threads of course,
not in the thread which does the computation), not the cost of locking the map.
In the example you gave, the computation is:
{code}
m.getParameterTypes()
{code}
which may not be very costly... But in general, you get the idea.
Plus, ConcurrentHashMap behaves way better than using a read/write lock with an
HashMap (due to the fact that the CHM locks only small part of itself, not the
whole map data. Viva ultra-specialized ultra-fast concurrent collection ! :-) )
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
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-tabpanel&focusedCommentId=13098060#comment-13098060
]
Nigel Goodwin commented on MATH-621:
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2 -1){code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098064#comment-13098064
]
Nigel Goodwin commented on MATH-621:
forgot to close the {code} tag, can't see where to edit my comment...
What I meant was
{code}
h((j + j*j)/2 -1)
{/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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098073#comment-13098073
]
Simone Tripodi commented on OGNL-20:
Julien,
Which complexity has lock/unlock objects? I'm asking because I don't know.
Can you point me please to {{ConcurrentHashMap}} doc wich explain how locks
only small part of itself and not the whole data?
Of course, Viva ultra-specialized ultra-fast concurrent collection, I just want
to make sure that, before one of us starts doing the leg-work of moving to the
new implementation, it would really add benefits to OGNL performances.
ATM I don't see much difference from
{code}
Map _methodParameterTypesCache = new HashMap();
...
synchronized (_methodParameterTypesCache)
{
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.put( m, result = m.getParameterTypes() );
}
return result;
}
{code}
and
{code}
Map _methodParameterTypesCache = new ConcurrentHashMap();
...
Class[] result = _methodParameterTypesCache.puIfAbsent( m,
m.getParameterTypes() );
return result;
{code}
except that, for what I can see, the {{m.getParameterTypes()}} that worries
you, in the first implementation is invoked only when the key is not found, in
the second is always invoked.
Please provide me the info I miss, merci en avant!
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098076#comment-13098076
]
Sebb commented on LANG-744:
---
Reworked static init in r1165701.
> StringUtils throws java.security.AccessControlException on Google App Engine
>
>
> Key: LANG-744
> URL: https://issues.apache.org/jira/browse/LANG-744
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.0.1
> Environment: Google App Engine
>Reporter: Clément Denis
> Fix For: 3.0.2
>
>
> In the static initializer of org.apache.commons.lang3.StringUtils, there is
> an attempt to load the class sun.text.Normalizer.
> Such a class is prohibited on Google App Engine, and the static intializer
> throws a java.security.AccessControlException.
> {code}
> Caused by: java.security.AccessControlException: access denied
> (java.lang.RuntimePermission accessClassInPackage.sun.text)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
> at
> java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
> at
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
> at java.lang.Class.checkMemberAccess(Class.java:2164)
> at java.lang.Class.getMethod(Class.java:1602)
> at org.apache.commons.lang3.StringUtils.(StringUtils.java:739)
> {code}
> The exception should be caught in the catch clauses around
> loadClass("sun.text.Normalizer").
> Commons lang 2 worked fine on GAE.
--
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-tabpanel&focusedCommentId=13098079#comment-13098079 ] Sebb commented on MATH-621: --- Hover over the comment you want to edit; there will be an edit icon in the top rhs of the grey 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098108#comment-13098108
]
Maurizio Cucchiara commented on OGNL-20:
Hi Simone,
to answer your questions...
{quote}
Which complexity has lock/unlock objects? I'm asking because I don't know.
{quote}
I am not sure I understood your question, I guess that lock and unlock are
atomic.
{quote}
Can you point me please to ConcurrentHashMap doc wich explain how locks only
small part of itself and not the whole data?
{quote}
Please, take a look at the
[implementation|http://www.google.it/codesearch#-WpwJU0UKqQ/src/share/classes/java/util/concurrent/ConcurrentHashMap.java&q=ConcurrentHashMap&type=cs&l=242],
you will see that, internally, CHM uses (and hence locks) a segment as a unit
of work (where segment is a small subset of the whole map).
{quote}
except that, for what I can see, the m.getParameterTypes() that worries you, in
the first implementation is invoked only when the key is not found, in the
second is always invoked.
{quote}
you are right, we should clarify how much cost the computation of the final
object value.
Anyway I would not unwrap the {{putIfAbsent}} invocation from the existence
check:
{code}
Map _methodParameterTypesCache = new ConcurrentHashMap();
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.puIfAbsent( m, result =
m.getParameterTypes() );
}
return result;
{code}
There are many other aspect to take into account: for example CHM doesn't
support null value.
from the javadoc:
{quote}
Like Hashtable but unlike HashMap, this class does not allow null to be used as
a key or value.
{quote}
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098110#comment-13098110
]
Julien Aymé commented on OGNL-20:
-
Simone,
The complexity of lock/unlock operation is O(1) I think. But there is a cost
nonetheless.
The
[ConcurrentHashMap|http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html]
class javadoc explains the mechanism of its behavior, including:
{quote}
Retrieval operations (including get) generally do not block, so may overlap
with update operations (including put and remove).
...
The table is internally partitioned to try to permit the indicated number of
concurrent updates without contention.
{quote}
Also, the proposed code is rather:
{code}
Map _methodParameterTypesCache = new ConcurrentHashMap();
...
Class[] result;
if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
{
_methodParameterTypesCache.putIfAbsent( m, result = m.getParameterTypes()
);
}
return result;
{code}
in which the {{m.getParameterTypes()}} is invoked only once per thread and only
as many times as there is concurrent threads trying to get the same value not
already computed (for the same key).
The whole point is that in a really ultra heavy environment (hundreds of
concurrent threads) the cache still behaves efficiently (a value computed in
one thread will be shared to others) without becoming a huge bottleneck (which
will happen when using either lock or synchronized block)
HTH,
De rien !!
Julien
P.S.: In french, we usually say "merci d'avance" for "thanks in advance" ;-)
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098134#comment-13098134
]
Maurizio Cucchiara commented on OGNL-20:
Julien,
it looks like one of us is able to read people's mind :)
Anyway, what about if we start, as I said before, from a test bench.
We could code a new cache interface (or reutilize the existing [ClassCache
one|https://svn.apache.org/viewvc/commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/internal/ClassCache.java?view=markup])
and provide different implementations and see what happens.
What do you thing, guys?
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-419) Not possible to call FTPClient.abort() method correctly
[ https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098138#comment-13098138 ] Bogdan Drozdowski commented on NET-419: --- Checking if the abort command was issued could be implemented the same way as the current NOOP sending, but it has a flow (just ilke the NOOP sending) - the listener classes that are registered on the transfers are called when bytes are transferred. This means that if we wait with sending the ABOR command until some bytes are received, we're defeating the purpose of the ABOR command itself. And if we send it immediately, we have synchronization problems. If we receive data often, then the ABOR will be sent not very long after calling the abort() method. If not (including slow or already disconnected servers), the method won't do nothing. So, sure, we may try it, but this fix won't be perfect. Maybe we could stop waiting for additional replies, so that each method that sends a command could have a synchronized block within which the command would be sent and one reply read. This way the BufferredReaders/Writers would be synchronized and other threads could send commands. This won't make the whole FTPClient thread-safe, but perhaps this would be enough for both the NOOP and ABOR to work properly during transfers. The drawback is that we're changing the behavious of some methods in an incompatible way. I'd look for synchronized line-wise readers and writers (probably outside of the Java core classes, perhaps even somewhere in Apache) and make command sending and reply parsing synchronized methods, this could fix our problems. Finding such classes is one thing. The FTP, FTPClient, FTPSClient and maybe other classes would have to be changed. Unfortunately, currently I don't have the time to look at this closer, but I'll look into the problem later. If you have any other ideas, share them! > Not possible to call FTPClient.abort() method correctly > --- > > Key: NET-419 > URL: https://issues.apache.org/jira/browse/NET-419 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0 > Environment: java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) > Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Tomas Mysik > > Unfortunately, it seems that there are difficulties of using FTPClient.abort() > method [1][2]. Also, it is really not clear how the abort() method should be > called/used at all - if from another thread (as I would expect) then there is > a problem with > thread-safety: FTPClient itself is not thread-safe so it means that some > custom lock/monitor must be used; but this lock will prevent calling abort() > on > the FTPClient while it is downloading/uploading file since file > upload/download > itself is blocking... > If I'm wrong and the abort() method works then an example in Javadoc would be > more than welcome. > Thanks a lot. > [1] > http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html > [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098161#comment-13098161
]
Simone Tripodi commented on OGNL-20:
OK for that case you convinced me, thanks :)
Looking forward the whole code modification...
@Izio: new interfaces are not needed, just new implementations that replace
existing behaviors.
@Julien: there was an era when my French was good, unfortunately didn't have so
much chances to use it, so started to forget :(
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-55) split the huge project in submodules
[ https://issues.apache.org/jira/browse/CHAIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098162#comment-13098162 ] Elijah Zupancic commented on CHAIN-55: -- I agree regarding splitting the project as well. I always wondered if anyone was actually using the faces or portlets modules. With regards to the servlet module, I don't think we should drop it. It is clunky and could be refactored. Moreover, I remember the WebServletContext being functionally read-only and confusing to use, so I ended up extending it so that I could make it work the way that I expected. > split the huge project in submodules > > > Key: CHAIN-55 > URL: https://issues.apache.org/jira/browse/CHAIN-55 > Project: Commons Chain > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.0 > > > As discussed in the [dev ML|http://markmail.org/message/pnyin5xzmxt2up5q], > there is a general agreement between people interested on chain, on splitting > the huge component in small submodules, in order to have a lightweight, > dependencies-less (unless the logging library, if required) and > self-contained core module, and users interested on core APIs only don't need > to bring unused code in their applications. SUggested modules are: > * core APIs; > * XML configuration APIs (depends from Digester); > * servlet (depends from Servlet APIs); > * portlet (depends from Portlet APIs); > * faces (depends from Faces APIs). -- 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-tabpanel&focusedCommentId=13098196#comment-13098196 ] Nigel Goodwin commented on MATH-621: I've checked line 1777 carefully and compared the logic with the Fortran, and it looks OK. I haven't checked line 1812. Note - it is well known that correcting a bug is likely to create a new bug, and if there is a bug in one area of code, there is likely to be a bug in similar areas. Also, incorrect indexing of the second derivative matrix may not cause an exception, but may simply make the algorithm perform less well. So it's worth a few more eyes to look at indexing of hq and check it. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098064#comment-13098064
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:44 PM:
forgot to close the cod tag, can't see where to edit my comment...
What I meant was
{code}
h((j + j*j)/2 -1)
{code}
was (Author: essence):
forgot to close the {code} tag, can't see where to edit my comment...
What I meant was
{code}
h((j + j*j)/2 -1)
{/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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098060#comment-13098060
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:48 PM:
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2){code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
was (Author: essence):
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2 -1){code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098060#comment-13098060
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:50 PM:
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]
h((j + j*j)/2)
{code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
was (Author: essence):
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2){/code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098060#comment-13098060
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:50 PM:
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code}
h((j + j*j)/2)
{code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
was (Author: essence):
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]
h((j + j*j)/2)
{code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098060#comment-13098060
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:49 PM:
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2){/code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
was (Author: essence):
let me think.
Assume hq is a lower triangular matrix, stored in order of columns.
So, using a 1-index, we have
hq(1) is mat(1,1)
hq(3) is mat(2,2)
hq(6) is mat(3,3) etc.
So in 1-index, the diagonal element of the j'th row is
{code]h((j + j*j)/2){code}
as in the Fortran
So in 0-index, we have
hq(0) is mat(0,0)
hq(2) is mat(1,1)
hq(5) is mat(2,2)
So the diagonal element is given by
((j+1) + (j + 1) * ( j+ 1))/2 - 1
and I think
(j + j*j)/2
is incorrect.
I'm pretty sure about this - I do a lot of work with triangular matrices.
Try another test - look at the last diagonal element - when j is n - 1, then
the index is (n + n*n)/2 -1 which is n*(n+1)/2 - 1, which is compatible with
the dimension when declared, n*np/2.
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098064#comment-13098064
]
Nigel Goodwin edited comment on MATH-621 at 9/6/11 5:51 PM:
forgot to close the cod tag, can't see where to edit my comment...
What I meant was
{code}
h((j + j*j)/2)
{code}
was (Author: essence):
forgot to close the cod tag, can't see where to edit my comment...
What I meant was
{code}
h((j + j*j)/2 -1)
{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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098220#comment-13098220 ] Nigel Goodwin commented on MATH-621: Let me be clear - revision 1165656 is incorrect, IMHO. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098247#comment-13098247
]
Gilles commented on MATH-621:
-
OK, I trust you :)
There were many other cases of matrices disguised as vectors. This is the last
one, I think, which I left for the end because of the tricky indexing.
So, instead of the current line 236:
{code}
final ArrayRealVector hq = new ArrayRealVector(n * np / 2);
{code}
I'd like to have:
{code}
final Array2DRowRealMatrix hq = new Array2DRowRealMatrix(n, n);
{code}
Would you like to provide the patch with the necessary changes (1d to 2d
indexing)?
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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] [Created] (DAEMON-216) Add command line switch to hide console window when switch "--type interactive" is used.
Add command line switch to hide console window when switch "--type interactive" is used. Key: DAEMON-216 URL: https://issues.apache.org/jira/browse/DAEMON-216 Project: Commons Daemon Issue Type: New Feature Components: Procrun Environment: windows family Reporter: Kurt Järmann Priority: Minor I have a Java Service and it is creating a tasktray. This only works with the switch "--type interactive" but its creating a not needed console window to fetch user input. I wish a switch to hide the unwanted window. Thank you for your efforts. Kurt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-658) Dead code in FastMath.pow(double, double) and some improvement in test coverage
[
https://issues.apache.org/jira/browse/MATH-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098316#comment-13098316
]
Luc Maisonobe commented on MATH-658:
Could you provide the patch as a unified diff file with respect to current
development tree so we can review it ?
Thanks
> Dead code in FastMath.pow(double, double) and some improvement in test
> coverage
> ---
>
> Key: MATH-658
> URL: https://issues.apache.org/jira/browse/MATH-658
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Yannick TANGUY
>Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathTest.java
>
>
> This issue concerns the FastMath class and its test class.
> (1) In the double pow(double, double) function, there are 2 identical "if"
> blocks. The second one can be suppressed.
> if (y < 0 && y == yi && (yi & 1) == 1) {
> return Double.NEGATIVE_INFINITY;
> }
> // this block is never used -> to be suppressed
> if (y < 0 && y == yi && (yi & 1) == 1) {
> return -0.0;
> }
> if (y > 0 && y == yi && (yi & 1) == 1) {
> return -0.0;
> }
> (2) To obtain better code coverage, we added some tests case in
> FastMathTest.java (see attached file)
> - Added test for log1p
> - Added tests in testPowSpecialCases()
> - Added tests for a 100% coverage of acos().
> - Added tests for a 100% coverage of asin().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-106) STARTTLS is only enabled if an authenticator is used
[
https://issues.apache.org/jira/browse/EMAIL-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl resolved EMAIL-106.
-
Resolution: Fixed
Fix Version/s: 1.3
Thanks to Albrecht Görge and the first Vienna Hackergarden
> STARTTLS is only enabled if an authenticator is used
>
>
> Key: EMAIL-106
> URL: https://issues.apache.org/jira/browse/EMAIL-106
> Project: Commons Email
> Issue Type: Bug
>Reporter: Bruno Harbulot
>Assignee: Siegfried Goeschl
> Fix For: 1.3
>
>
> The STARTTLS parameter is only set if an authenticator is used, whereas the
> two features are independent: it would also make sense to use STARTTLS
> without authentication, so as to protect eavesdropping of the e-mail content,
> for example.
> Here is a patch for {{src/java/org/apache/commons/mail/Email.java}} (rev.
> 1088801):
> {code}
> @@ -481,9 +481,9 @@ public abstract class Email implements EmailConstants
> properties.setProperty(MAIL_HOST, this.hostName);
> properties.setProperty(MAIL_DEBUG, String.valueOf(this.debug));
>
> +properties.setProperty(MAIL_TRANSPORT_TLS, tls ? "true" :
> "false");
> if (this.authenticator != null)
> {
> -properties.setProperty(MAIL_TRANSPORT_TLS, tls ? "true" :
> "false");
> properties.setProperty(MAIL_SMTP_AUTH, "true");
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-102) HtmlEmail embed toLowerCase bug
[ https://issues.apache.org/jira/browse/EMAIL-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EMAIL-102. - Resolution: Fixed > HtmlEmail embed toLowerCase bug > --- > > Key: EMAIL-102 > URL: https://issues.apache.org/jira/browse/EMAIL-102 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows XP, Solaris and Turkish Regional Environment >Reporter: Okan Özeren >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.3 > > > When I embed an image to my html email object, if randomAlphabetic (on this > line HtmlEmail.java:325) method brought uppercase 'I' character, at the this > time toLowerCase method convert it to lowercase Turkish 'ı' character. I > think, toLowerCase brougt lowercase 'ı' character when regional settings up > to Turkish. In that case, this header variable expose to mime encoding > process and set as like "cid:=C4=B1glhuooecb" (=C4=B1 is lowercase 'ı' > character) and the mail clients does not show this embedded image. > Maybe, toLowerCase method use by passing English Locale parameters then this > must work correctly like this "toLowerCase(Locale.ENGLISH);". > Best regards, > Okan Özeren. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-105) Clarify names for SSL and TLS
[
https://issues.apache.org/jira/browse/EMAIL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl resolved EMAIL-105.
-
Resolution: Fixed
Fix Version/s: 1.3
Thanks to Albrecht Görge and the first Vienna Hackergarden
> Clarify names for SSL and TLS
> -
>
> Key: EMAIL-105
> URL: https://issues.apache.org/jira/browse/EMAIL-105
> Project: Commons Email
> Issue Type: Improvement
>Reporter: Bruno Harbulot
>Assignee: Siegfried Goeschl
> Fix For: 1.3
>
> Attachments: ssl-starttls.patch
>
>
> The API offers two categories of settings for the configuration of SSL/TLS:
> {{setSSL}} and {{setTLS}} (and respective associated methods).
> The names are quite misleading, as this doesn't really oppose SSL and TLS. A
> number of e-mail applications make this mistake, but "TLS" is used here to
> mean "using STARTTLS" and "SSL" is used here to mean "SSL or TLS, upon
> connection".
> The difference is that:
> - With "SSL" (as incorrectly named here), the SMTP client connects to the
> SMTP server on a dedicated port and starts the SSL/TLS handshake upon
> connection. This is then followed by "normal" SMTP traffic on this SSL/TLS
> layer.
> - With "TLS" (as incorrectly named here), the SMTP client connects to the
> SMTP server on the same port as it would do for plain-text SMTP, exchanges a
> few SMTP commands, including [STARTTLS (RFC
> 3207)|http://tools.ietf.org/html/rfc3207 ], and then starts an SSL/TLS
> handshake to upgrade to a secure channel.
> This is not so much a difference between SSL and TLS, but rather a difference
> regarding when the connection is turned into a secure one.
> The difference between SSLv3 and TLS 1.0 is mostly a version difference,
> where SSLv3 is the predecessor of TLS 1.0.
> You can have an TLS 1.0+ upon connection, using the "SSL" setting, without
> using {{STARTTLS}} (it's a version configuration up to the {{SSLEngine}} or
> {{SSLSocketFactory}}).
> Similarly, although it's not written in the specification, some servers seem
> to accept an SSLv3 handshake (instead of its successor version: TLS 1.0)
> after {{STARTTLS}}.
> I'd suggest deprecating {{setSSL}} and {{setTLS}} and replacing them with
> {{setOnConnectSSL}} and {{setStartTLS}} (or similar), respectively.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EMAIL-107) wrong content-type for embedded PNG images
[ https://issues.apache.org/jira/browse/EMAIL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jakl updated EMAIL-107: --- Attachment: Added_PNG_mime_type,_fixes_#EMAIL-107_.patch Patch by Claus Polanka Michael Jakl > wrong content-type for embedded PNG images > -- > > Key: EMAIL-107 > URL: https://issues.apache.org/jira/browse/EMAIL-107 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Jay >Assignee: Siegfried Goeschl > Labels: embed, images, png > Attachments: Added_PNG_mime_type,_fixes_#EMAIL-107_.patch > > > when embedding a PNG image the content type is: Content-Type: > application/octet-stream; > which makes some clients not show the image. > by contrast, when embedding a GIF image the content type is correctly shown > as: Content-Type: image/gif; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-19) Ability to programatically "step" through an Ognl execution.
[ https://issues.apache.org/jira/browse/OGNL-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pitts updated OGNL-19: - Issue Type: New Feature (was: Wish) > Ability to programatically "step" through an Ognl execution. > > > Key: OGNL-19 > URL: https://issues.apache.org/jira/browse/OGNL-19 > Project: OGNL > Issue Type: New Feature > Environment: All. >Reporter: Daniel Pitts > Labels: feature, runtime > > First, let me describe in abstract terms my use case: > I have several "resources" which I need to retrieve (by URI). I'm using Ognl > to describe the URI of these resources. > Some of the resource URI's might be dependent on content in other resources. > I'd like to be able to set up my own queuing mechanism which will put on hold > any such dependent URI until the resource is retrieved. > Right now, the Ognl expression is evaluated using the Java stack, which makes > it extremely difficult to "pause" an expression. > It would be nice if the expression state could be externalized and run > iteratively instead of recursively. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EMAIL-107) wrong content-type for embedded PNG images
[ https://issues.apache.org/jira/browse/EMAIL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jakl updated EMAIL-107: --- Attachment: images.zip Images for the test (src/test/images) > wrong content-type for embedded PNG images > -- > > Key: EMAIL-107 > URL: https://issues.apache.org/jira/browse/EMAIL-107 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Jay >Assignee: Siegfried Goeschl > Labels: embed, images, png > Attachments: Added_PNG_mime_type,_fixes_#EMAIL-107_.patch, images.zip > > > when embedding a PNG image the content type is: Content-Type: > application/octet-stream; > which makes some clients not show the image. > by contrast, when embedding a GIF image the content type is correctly shown > as: Content-Type: image/gif; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098362#comment-13098362
]
Daniel Pitts commented on OGNL-20:
--
Do keep in mind that the ConcurrentHashMap is new in Java 1.5. If you are
targetting older JDK/JVM, you'll need to have other strategies that can work
for those too (with perhaps degraded concurrency performance). Relatedly, if
you *are* targeting 1.5+, then you should be using generics here, and not raw
types, eg:
"Map cache = new ConcurrentHashMap();"
I do like the idea of using ConcurrentHashMap though.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-107) wrong content-type for embedded PNG images
[ https://issues.apache.org/jira/browse/EMAIL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EMAIL-107. - Resolution: Fixed Fix Version/s: 1.3 > wrong content-type for embedded PNG images > -- > > Key: EMAIL-107 > URL: https://issues.apache.org/jira/browse/EMAIL-107 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Jay >Assignee: Siegfried Goeschl > Labels: embed, images, png > Fix For: 1.3 > > Attachments: Added_PNG_mime_type,_fixes_#EMAIL-107_.patch, images.zip > > > when embedding a PNG image the content type is: Content-Type: > application/octet-stream; > which makes some clients not show the image. > by contrast, when embedding a GIF image the content type is correctly shown > as: Content-Type: image/gif; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-104) The system property "mail.mime.charset" is not applied to contents.
[ https://issues.apache.org/jira/browse/EMAIL-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098383#comment-13098383 ] Siegfried Goeschl commented on EMAIL-104: - I'm not sure if I understand the problem correctly +) setTextMsg() and setHtmlMsg() take the plain string +) that plain strings are afterwards encoded when the MimeMessage is built (HTMLEmail.build()) Can you please clarify? > The system property "mail.mime.charset" is not applied to contents. > --- > > Key: EMAIL-104 > URL: https://issues.apache.org/jira/browse/EMAIL-104 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Hiroshi Ikeda >Assignee: Siegfried Goeschl >Priority: Minor > Labels: charset > > Both of JavaMail and Commons Email encode subjects and personal names with > the system property "mail.mime.charset" when no charsets are specified via > methods. Also they encode attached filenames with the property when the other > system property "mail.mime.encodefilename" is set (regardless of RFC). On the > other hand, JavaMail encodes text contents with the property via setText > methods when no charsets specified, but Commons Email doesn't encode the > contents via setMsg/setTextMsg/setHtmlMsg methods. The partial difference of > the behaviors makes confusion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
[ https://issues.apache.org/jira/browse/EMAIL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl updated EMAIL-101: Priority: Minor (was: Major) > Specified Content-ID is not used when embedding a File object in an HtmlEmail > - > > Key: EMAIL-101 > URL: https://issues.apache.org/jira/browse/EMAIL-101 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Andrew Starodub >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.3 > > Attachments: HtmlEmail.patch, HtmlEmailTest.patch > > > When calling the .embed(File file, String cid) method on HtmlEmail, the cid > argument is never used within the method. > Consequently, even when the user specifies a Content-ID for the embedded > File, a new randomly generated Content-ID is generated every time. > I believe this is as simple as changing the last line of .embed(File file, > String cid) from: > return embed(new FileDataSource(file), file.getName()); > To: > return embed(new FileDataSource(file), file.getName(), cid); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-104) The system property "mail.mime.charset" is not applied to contents.
[ https://issues.apache.org/jira/browse/EMAIL-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098387#comment-13098387 ] Siegfried Goeschl commented on EMAIL-104: - Well - I need to read up on the Mail API ... :-) > The system property "mail.mime.charset" is not applied to contents. > --- > > Key: EMAIL-104 > URL: https://issues.apache.org/jira/browse/EMAIL-104 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Hiroshi Ikeda >Assignee: Siegfried Goeschl >Priority: Minor > Labels: charset > > Both of JavaMail and Commons Email encode subjects and personal names with > the system property "mail.mime.charset" when no charsets are specified via > methods. Also they encode attached filenames with the property when the other > system property "mail.mime.encodefilename" is set (regardless of RFC). On the > other hand, JavaMail encodes text contents with the property via setText > methods when no charsets specified, but Commons Email doesn't encode the > contents via setMsg/setTextMsg/setHtmlMsg methods. The partial difference of > the behaviors makes confusion. -- 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-tabpanel&focusedCommentId=13098448#comment-13098448 ] Nigel Goodwin commented on MATH-621: No I would not! I do a lot of work with positive definite symmetric matrices, and I ALWAYS store and manipulate them as upper (or lower) triangular matrices stored as a vector or 1D array. This is the best way to do it, and nothing would motivate me to make a retrograde step and store symmetric matrices as a matrix or 2D array (unless maybe underlying storages was a 1 D array, and even then I would have grave misgivings). I have written a lot of symmetric matrix code, and it ALWAYS outperforms any Java library I can find, simply because I use the proper 1D array form of storage. Plus i do a bit of loop unrolling etc etc but that is another story. I first looked at code provided by Prof Powell back in the early 1980's, his rank one (or was it rank two) cholesky factor update, and no doubt this has influenced my tendency to always store upper (or lower) triangular matrices as 1D arrays. I even hate it when there is a special class for symmetric matrices, and it has a last step which puts the lower triangular elements equal to the upper triangular elements. No, don't do it, do it properly! In most of my application code, cholesky factorisation and back substitution are the bottlenecks. I do tens of thousands of back substitutions. Now, if there was a symmetric matrix class with an underlying storage of a 1D array, and some suitable get and set functions, you might persuade me, so long as the get and set were just utilities to be used in non critical parts of the code. Store a symmetric matrix as a 2d array? No, never, no! ps soory about the capitals. But you may note I feel strongly. It is why all Java libraries I have looked at suck for symmetric matrices, and i had to write my own. It is late, and I may be wrong, but I think LAPACK symmetric code (or is it BLAS?) stores symmetric matrics as 1D triangular arrays. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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] [Issue Comment Edited] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098448#comment-13098448 ] Nigel Goodwin edited comment on MATH-621 at 9/6/11 11:11 PM: - No I would not! I do a lot of work with positive definite symmetric matrices, and I ALWAYS store and manipulate them as upper (or lower) triangular matrices stored as a vector or 1D array. This is the best way to do it, and nothing would motivate me to make a retrograde step and store symmetric matrices as a matrix or 2D array (unless maybe underlying storages was a 1 D array, and even then I would have grave misgivings). I have written a lot of symmetric matrix code, and it ALWAYS outperforms any Java library I can find, simply because I use the proper 1D array form of storage. Plus i do a bit of loop unrolling etc etc but that is another story. I first looked at code provided by Prof Powell back in the early 1980's, his rank one (or was it rank two) cholesky factor update, and no doubt this has influenced my tendency to always store upper (or lower) triangular matrices as 1D arrays. I even hate it when there is a special class for symmetric matrices, and it has a last step which puts the lower triangular elements equal to the upper triangular elements. No, don't do it, do it properly! In most of my application code, cholesky factorisation and back substitution are the bottlenecks. I do tens of thousands of back substitutions. Now, if there was a symmetric matrix class with an underlying storage of a 1D array, and some suitable get and set functions, you might persuade me, so long as the get and set were just utilities to be used in non critical parts of the code. Store a symmetric matrix as a 2d array? No, never, no! ps soory about the capitals. But you may note I feel strongly. It is why all Java libraries I have looked at (including apache commons maths) suck for symmetric matrices, and i had to write my own. It is late, and I may be wrong, but I think LAPACK symmetric code (or is it BLAS?) stores symmetric matrics as 1D triangular arrays. was (Author: essence): No I would not! I do a lot of work with positive definite symmetric matrices, and I ALWAYS store and manipulate them as upper (or lower) triangular matrices stored as a vector or 1D array. This is the best way to do it, and nothing would motivate me to make a retrograde step and store symmetric matrices as a matrix or 2D array (unless maybe underlying storages was a 1 D array, and even then I would have grave misgivings). I have written a lot of symmetric matrix code, and it ALWAYS outperforms any Java library I can find, simply because I use the proper 1D array form of storage. Plus i do a bit of loop unrolling etc etc but that is another story. I first looked at code provided by Prof Powell back in the early 1980's, his rank one (or was it rank two) cholesky factor update, and no doubt this has influenced my tendency to always store upper (or lower) triangular matrices as 1D arrays. I even hate it when there is a special class for symmetric matrices, and it has a last step which puts the lower triangular elements equal to the upper triangular elements. No, don't do it, do it properly! In most of my application code, cholesky factorisation and back substitution are the bottlenecks. I do tens of thousands of back substitutions. Now, if there was a symmetric matrix class with an underlying storage of a 1D array, and some suitable get and set functions, you might persuade me, so long as the get and set were just utilities to be used in non critical parts of the code. Store a symmetric matrix as a 2d array? No, never, no! ps soory about the capitals. But you may note I feel strongly. It is why all Java libraries I have looked at suck for symmetric matrices, and i had to write my own. It is late, and I may be wrong, but I think LAPACK symmetric code (or is it BLAS?) stores symmetric matrics as 1D triangular arrays. > 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, > BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, > bobyqa_convert.pl, 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 s
[jira] [Commented] (OGNL-8) use javacc to generate AST* and OGNLParser Java sources
[ https://issues.apache.org/jira/browse/OGNL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098455#comment-13098455 ] Daniel Pitts commented on OGNL-8: - I'm kind of new to this scene, so excuse me if my comments are misplaced. It seems to me that the AST code is too tightly coupled to the workings of the actual running engine. I wonder if there can be a way to fix that with performance and maintenance in mind, and perhaps (related to my other open feature request OGNL-19) extensibility. > use javacc to generate AST* and OGNLParser Java sources > --- > > Key: OGNL-8 > URL: https://issues.apache.org/jira/browse/OGNL-8 > Project: OGNL > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Attachments: OGNL-8.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-655:
---
Attachment: iteration-manager.zip
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iteration-manager.zip, iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098520#comment-13098520
]
Sébastien Brisard commented on MATH-655:
In the attached file {{iteration-manager.zip}} is a new version which follows
Phil's suggestion to use composition instead of inheritance. We now have three
classes
* {{IterationManager}}: besides the methods to add/remove listeners, fire
events and manage the iteration count, I've added {{shouldStop()}}, which
returns {{true}} if the iterations should be stopped. This method should be
called by the iterative algorithm at the end of each iteration; it allows the
implementation of a custom stopping criterion. What do you think of this option
(?)
* {{IterationListener}}
* {{IterationEvent}}
I should also add that I took Greg's suggestion into account, and replaced
{{ArrayList}} by {{CopyOnWriteArrayList}}. Finally, you will see that
{{TooManyEvaluationsException}} is potentially thrown. In the final version of
these classes, I'll define a proper {{TooManyIterationsException}}, with
localized message and so on.
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iteration-manager.zip, iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-659) Remove solve(double[][]) from DecompositionSolver
Remove solve(double[][]) from DecompositionSolver
-
Key: MATH-659
URL: https://issues.apache.org/jira/browse/MATH-659
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Trivial
Following MATH-653, where {{double[]}} were removed from {{RealVector}}, and
{{double[] solve(double[])}} was removed from {{DecompositionSolver}}, the
method {{double[][] solve(double[][])}} should be removed from
{{DecompositionSolver}}. {{RealMatrix solve(RealMatrix)}} should be called
instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-660) Simplify interface FieldVector
Simplify interface FieldVector
--
Key: MATH-660
URL: https://issues.apache.org/jira/browse/MATH-660
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Trivial
Following what has been done on {{RealVector}}, {{FieldVector}} should be
simplified by removing all methods which treat {{T[]}} as vectors
* {{add(T[])}}
* {{append(T[])}}
* {{dotProduct(T[])}}
* {{ebeDivide(T[])}}
* {{ebeMultiply(T[])}}
* {{outerProduct(T[])}}
* {{projection(T[])}}
* {{setSubVector(int, T[])}}
* {{subtract(T[])}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-661) Simplify interface FieldDecompositionSolver
Simplify interface FieldDecompositionSolver
---
Key: MATH-661
URL: https://issues.apache.org/jira/browse/MATH-661
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Trivial
In accordance with MATH-660, {{T[] FieldDecompositionSolver.solve(T[] b)}}
should be removed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-104) The system property "mail.mime.charset" is not applied to contents.
[ https://issues.apache.org/jira/browse/EMAIL-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098546#comment-13098546 ] Hiroshi Ikeda commented on EMAIL-104: - I forget many things about several months ago, and I find my memo which says: If you call MimeMessage/MimeBody.setContent directly, instead of setText, then the system property "mail.mime.charset" is not used. HtmlEmail and SimpleEmail in Commons Email call the setContent methods. > The system property "mail.mime.charset" is not applied to contents. > --- > > Key: EMAIL-104 > URL: https://issues.apache.org/jira/browse/EMAIL-104 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Hiroshi Ikeda >Assignee: Siegfried Goeschl >Priority: Minor > Labels: charset > > Both of JavaMail and Commons Email encode subjects and personal names with > the system property "mail.mime.charset" when no charsets are specified via > methods. Also they encode attached filenames with the property when the other > system property "mail.mime.encodefilename" is set (regardless of RFC). On the > other hand, JavaMail encodes text contents with the property via setText > methods when no charsets specified, but Commons Email doesn't encode the > contents via setMsg/setTextMsg/setHtmlMsg methods. The partial difference of > the behaviors makes confusion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-662) DecompositionSolver: merging unique "...Impl" classes with their interface
DecompositionSolver: merging unique "...Impl" classes with their interface
--
Key: MATH-662
URL: https://issues.apache.org/jira/browse/MATH-662
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Trivial
>From the ML
{quote}
Hi.
The "...Decomposition" interfaces in package "linear" have a unique
implementation. Should the "...Impl" classes be renamed (removing the
interfaces)?
Regards,
Gilles
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-107) wrong content-type for embedded PNG images
[ https://issues.apache.org/jira/browse/EMAIL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098566#comment-13098566 ] Jay commented on EMAIL-107: --- thanks guys :) > wrong content-type for embedded PNG images > -- > > Key: EMAIL-107 > URL: https://issues.apache.org/jira/browse/EMAIL-107 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Jay >Assignee: Siegfried Goeschl > Labels: embed, images, png > Fix For: 1.3 > > Attachments: Added_PNG_mime_type,_fixes_#EMAIL-107_.patch, images.zip > > > when embedding a PNG image the content type is: Content-Type: > application/octet-stream; > which makes some clients not show the image. > by contrast, when embedding a GIF image the content type is correctly shown > as: Content-Type: image/gif; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-655:
---
Attachment: iterative-algorithm.zip
Some minor changes (was too quick declaring some methods final).
> General framework for iterative algorithms
> --
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: algorithm, events
> Attachments: iteration-manager.zip, iterative-algorithm.zip,
> iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
