[jira] [Created] (LANG-743) JavaDoc bug in static inner class DateIterator

2011-08-19 Thread Patrick Arnoldy (JIRA) 
JavaDoc bug in static inner class DateIterator
--

 Key: LANG-743
 URL: https://issues.apache.org/jira/browse/LANG-743
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 2.6
Reporter: Patrick Arnoldy
Priority: Minor


Possibly there is a bug in the JavaDoc comment of the DateIterator constructor. 
It says, that the parameter endFinal is not included in the date range that 
will be iterated, but when I look at the source code I see that the end date 
will be delivered as a result of the next()-method.

Source code:
/**
 * Constructs a DateIterator that ranges from one date to another. 
 *
 * @param startFinal start date (inclusive)
 * @param endFinal end date (not inclusive)
 */
DateIterator(Calendar startFinal, Calendar endFinal) {
super();
this.endFinal = endFinal;
spot = startFinal;
spot.add(Calendar.DATE, -1);
}

/**
 * Has the iterator not reached the end date yet?
 *
 * @return codetrue/code if the iterator has yet to reach the end date
 */
public boolean hasNext() {
return spot.before(endFinal);
}

/**
 * Return the next calendar in the iteration
 *
 * @return Object calendar for the next date
 */
public Object next() {
if (spot.equals(endFinal)) {
throw new NoSuchElementException();
}
spot.add(Calendar.DATE, 1);
return spot.clone();
}


Example:
Value of variable endFinal: 2011-08-20
Current value of variable spot: 2011-08-19

- hasNext returns true because spot is before endFinal
- the if-statement fails because spot is not equal to endFinal
- one day is added to spot
- next returns the 20th of august = endFinal


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

[jira] [Updated] (COMPRESS-153) close() in several OutputStream implementations doesn't close the underlying stream if the archive would be corrupt

2011-08-19 Thread Stefan Bodewig (JIRA) 

 [ 
https://issues.apache.org/jira/browse/COMPRESS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated COMPRESS-153:


Fix Version/s: 2.0
 Assignee: (was: Stefan Bodewig)

 close() in several OutputStream implementations doesn't close the underlying 
 stream if the archive would be corrupt
 ---

 Key: COMPRESS-153
 URL: https://issues.apache.org/jira/browse/COMPRESS-153
 Project: Commons Compress
  Issue Type: Bug
Reporter: Stefan Bodewig
 Fix For: 2.0


 In some cases like when ZiparchiveOutputStream's File-arg constructor is 
 used, the user code doesn't even have any chance to close the underlying 
 stream, even if it would catch the exception from close() and then close the 
 wrapped stream by itself.

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

[jira] [Commented] (COMPRESS-153) close() in several OutputStream implementations doesn't close the underlying stream if the archive would be corrupt

2011-08-19 Thread Stefan Bodewig (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087624#comment-13087624
 ] 

Stefan Bodewig commented on COMPRESS-153:
-

It turns out ArchiveOutputStreamTest#testCallSequence*() explicitly checks one 
can call closeArchiveEntry after a failed call to close (line 176 in svn 
revision 1157880), i.e. one can recover from a failed close.

I find this dubious at best but since it obviously break the current contract 
as stated in the tests I've pushed it to the rethink for 2.0 list of issues.

 close() in several OutputStream implementations doesn't close the underlying 
 stream if the archive would be corrupt
 ---

 Key: COMPRESS-153
 URL: https://issues.apache.org/jira/browse/COMPRESS-153
 Project: Commons Compress
  Issue Type: Bug
Reporter: Stefan Bodewig
 Fix For: 2.0


 In some cases like when ZiparchiveOutputStream's File-arg constructor is 
 used, the user code doesn't even have any chance to close the underlying 
 stream, even if it would catch the exception from close() and then close the 
 wrapped stream by itself.

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

[jira] [Issue Comment Edited] (COMPRESS-153) close() in several OutputStream implementations doesn't close the underlying stream if the archive would be corrupt

2011-08-19 Thread Stefan Bodewig (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087624#comment-13087624
 ] 

Stefan Bodewig edited comment on COMPRESS-153 at 8/19/11 9:48 AM:
--

It turns out ArchiveOutputStreamTest#testCallSequence*() explicitly checks one 
can call closeArchiveEntry after a failed call to close (line 176 in svn 
revision 1157880), i.e. one can recover from a failed close.

I find this dubious at best but since it obviously breaks the current contract 
as stated in the tests I've pushed this issue to the rethink for 2.0 list of 
issues.

  was (Author: bodewig):
It turns out ArchiveOutputStreamTest#testCallSequence*() explicitly checks 
one can call closeArchiveEntry after a failed call to close (line 176 in svn 
revision 1157880), i.e. one can recover from a failed close.

I find this dubious at best but since it obviously break the current contract 
as stated in the tests I've pushed it to the rethink for 2.0 list of issues.
  
 close() in several OutputStream implementations doesn't close the underlying 
 stream if the archive would be corrupt
 ---

 Key: COMPRESS-153
 URL: https://issues.apache.org/jira/browse/COMPRESS-153
 Project: Commons Compress
  Issue Type: Bug
Reporter: Stefan Bodewig
 Fix For: 2.0


 In some cases like when ZiparchiveOutputStream's File-arg constructor is 
 used, the user code doesn't even have any chance to close the underlying 
 stream, even if it would catch the exception from close() and then close the 
 wrapped stream by itself.

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

[jira] [Commented] (MATH-641) Implement distance methods on 2D and 3D Lines as well as Line Segments.

2011-08-19 Thread Curtis Jensen (JIRA) 

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

Curtis Jensen commented on MATH-641:


I am looking for the shortest distance to a segment including the end points.  
I think it can be done by finding the the point on the line perpendicular the 
the specified distance point.  If the perpendicular point is on the line 
segment, then return the distance between the perpendicular point and the 
specified point, otherwise return the min distance to the end points:
See:
http://www.codeguru.com/forum/printthread.php?s=37e72c81efe767865815ecdb4a943d87t=194400pp=15

Also, some smarty pants figured out a simpler way to to it here:
http://www.codeguru.com/forum/printthread.php?s=cc8cf0596231f9a7dba4da6e77c29db3t=194400pp=15page=2

If the line segment distance function is not added to the API (or even if it 
is), it would be very useful to have a line method that calculates the point 
one a line that is perpendicular to another point.

The getOffset method is still useful to me for other calculations.  Though it 
is inconsistent with the interface of the 3D line.  The 3D line class has a 
distance method while the 2D line has the getOffset method.  It may be more 
intuitive if the 3D and 2D line classes used the same nomenclature.  getOffset 
provides more information as it is signed, but distance is a more intuitive 
name.

Thanks for all the help and consideration.


 Implement distance methods on 2D and 3D Lines as well as Line Segments.
 ---

 Key: MATH-641
 URL: https://issues.apache.org/jira/browse/MATH-641
 Project: Commons Math
  Issue Type: New Feature
Reporter: Curtis Jensen
Priority: Minor
 Fix For: 3.1

   Original Estimate: 4h
  Remaining Estimate: 4h

 Implement a method that calculates the distance from a point to 3D and 2D 
 lines and line segements (similar to what already exists in the 3D Line 
 class).

--
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-08-19 Thread Gilles (JIRA) 

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

Gilles commented on MATH-621:
-

prelim cleaned up in revision 1159792.

Another occurrence of a supposedly innocuous change (dividing by a number vs 
multiplying by the inverse of that number) induces the same two unit tests to 
fail.


 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-08-19 Thread Gilles (JIRA) 

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

Gilles commented on MATH-621:
-

Many code branches in prelim unexplored by the current set of unit tests.
The unused code paths are marked by throwing an exception as their last 
statement.


 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