date:20110906


[ 
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097760#comment-13097760
 ] 

Sébastien Brisard commented on MATH-653:


* {{EigenDecompositionImpl}} done with in rev. 1165505
* {{LUDecompositionImpl}} in rev. 1165506
* {{QRDecompositionSolver}} in rev. 1165507
* {{SingularValueDecompositionSolver}} in rev. 1165508


 Rename AbstractRealVector to RealVector
 ---

 Key: MATH-653
 URL: https://issues.apache.org/jira/browse/MATH-653
 Project: Commons Math
  Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
 Fix For: 3.0


 AbstractRealVector is the only implementation of the RealVector interface.

--
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

2011-09-06 Thread Olivier Lamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2011-09-06 Thread Maurizio Cucchiara (JIRA)

[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2011-09-06 Thread Maurizio Cucchiara (JIRA)

[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097795#comment-13097795
]

Maurizio Cucchiara commented on OGNL-20:

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

--
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-tabpanelfocusedCommentId=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:
code
cache = new ConcurrentHashMap();

Object cachedObject = cache.get(key);
if (null == cachedObject) {

code


 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-tabpanelfocusedCommentId=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:
code
cache = new ConcurrentHashMap();

Object cachedObject = cache.get(key);
if (null == cachedObject) {

code

  
 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-tabpanelfocusedCommentId=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] [Updated] (MATH-658) Dead code in FastMath.pow(double, double) and some improvement in test coverage

2011-09-06 Thread Yannick TANGUY (JIRA)


 [ 
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);
   
assertEquals(FastMath.asin(1.0), FastMath.PI / 2.0, Double.MIN_VALUE);

[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock

2011-09-06 Thread Adrian Crum (JIRA)

[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=UTF8qid=1315303458sr=8-1)
and Concurrent Programming In Java
(http://www.amazon.com/Concurrent-Programming-Java-Principles-Pattern/dp/0201310090/ref=sr_1_1?s=booksie=UTF8qid=1315303737sr=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

--
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

2011-09-06 Thread Gagan Jain (JIRA)

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 comma separated values 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-tabpanelfocusedCommentId=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] [Commented] (MATH-621) BOBYQA is missing in optimization

2011-09-06 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2011-09-06 Thread Gilles (JIRA)

[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

--
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-621) BOBYQA is missing in optimization


[ 
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

2011-09-06 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(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

2011-09-06 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2011-09-06 Thread Maurizio Cucchiara (JIRA)


[ 
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.javaq=ConcurrentHashMaptype=csl=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-tabpanelfocusedCommentId=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

2011-09-06 Thread Elijah Zupancic (JIRA)


[ 
https://issues.apache.org/jira/browse/CHAIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

--
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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

2011-09-06 Thread Luc Maisonobe (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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

2011-09-06 Thread Michael Jakl (JIRA)


 [ 
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

2011-09-06 Thread Daniel Pitts (JIRA)

[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
MapMethod, Class[] cache = new ConcurrentHashMapMethod, Class[]();

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

--
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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

--
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-tabpanelfocusedCommentId=13098448#comment-13098448
]

Nigel Goodwin edited comment on MATH-621 at 9/6/11 11:11 PM:
-

No I would not!

In most of my application code, cholesky factorisation and back substitution
are the bottlenecks. I do tens of thousands of back substitutions.

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!

In most of my application code, cholesky factorisation and back substitution
are the bottlenecks. I do tens of thousands of back substitutions.

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

[jira] [Commented] (OGNL-8) use javacc to generate AST* and OGNLParser Java sources

2011-09-06 Thread Daniel Pitts (JIRA)


[ 
https://issues.apache.org/jira/browse/OGNL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [Commented] (EMAIL-107) wrong content-type for embedded PNG images

2011-09-06 Thread Jay (JIRA)


[ 
https://issues.apache.org/jira/browse/EMAIL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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