date:20110815

[jira] [Commented] (COMPRESS-132) Add support for unix dump files

2011-08-15 Thread Stefan Bodewig (JIRA)

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

Stefan Bodewig commented on COMPRESS-132:
-

svn revision 1157769 contains a repackaged version of the main tree of your
code.

Things I've changed:

* repackaged to live in org.apache.commons land

* removed all @author tags and instead added you to the POM as contributor,
hope this is OK with you (we don't do @author tags). Should this is a problem
for you then I'll simply remove the code again.

* merged POSIXArchiveEntry into DumpArchiveEntry for now

* renamed getModTime to getLastModifiedDate as your class didn't implement that
method (it was added in Compress 1.1)

Missing for me in order to close this are tests - will add some once I have
access to a machine that has dump installed - and initial documentation for the
site. I'll take care of that as well.

Add support for unix dump files
---

Key: COMPRESS-132
URL: https://issues.apache.org/jira/browse/COMPRESS-132
Project: Commons Compress
Issue Type: New Feature
Components: Archivers
Reporter: Bear Giles
Priority: Minor
Fix For: 1.3

Attachments: dump-20110722.zip, dump.zip, test-z.dump, test.dump

I'm submitting a series of patches to the ext2/3/4 dump utility and noticed
that the commons-compress library doesn't have an archiver for it. It's as
old as tar and fills a similar niche but the later has become much more
widely used. Dump includes support for sparse files, extended attributes, mac
os finder, SELinux labels (I think), and more. Incremental dumps can capture
that files have been deleted.
I should have initial support for a decoder this weekend. I can read the
directory entries and inode information (file permissions, etc.) but need a
bit more work on extracting the content as an InputStream.

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

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

2011-08-15 Thread Dr. Dietmar Wolz (JIRA)


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

Dr. Dietmar Wolz updated MATH-621:
--

Attachment: BOBYQAOptimizer0.4.zip

No changes from the perl generated code 
beside the ones necessary to get INDEX_OFFSET=0 working. Introduced 
INDEX_OFFSET where possible but there were
many other adaptions necessary (just compare the perl generated code with the 
attachment). Version 0.3 had some useful 
additional minor changes/refactorings missing here (see remarks below),
but the main work for 0.3 was the index change, and this we have here again. 
Remarks:

1) The perl script has damaged the for loop intendation

2) n, npt and nptm should be global variables and not set separately
in each method

3) System generated locals: Declare variables in the scope they are needed and
not method-globally if not necessary

4) testDiagonalRosen() is a copy/paste leftover from CMAES, should be removed

5) We should shink about removing rescue as proposed by Mike Powell. 



 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, 
 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-15 Thread Gilles (JIRA)

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

Gilles commented on MATH-621:
-

Thanks for the work.
However, if I change the INDEX_OFFSET constant (setting it back to 1), the
tests fail.
I see that you hard-coded the offset in most places instead of using
INDEX_OFFSET. I still think that this place-holder would be useful to keep
track of places where the index variables might have been set to fit with the
Fortran 1-based counting... Don't you?

{quote}
The perl script has damaged the for loop intendation
{quote}
Sorry, I didn't see that. But that's easy to fix. I'll do it after the issue
with INDEX_OFFSET is settled.

{quote}
n, npt and nptm should be global variables and not set separately
in each method
{quote}
Yes, I agree. But there are probably many other variables for which this is
true (zmat, bmat, etc).

{quote}
System generated locals: Declare variables in the scope they are needed [...]
{quote}
Agreed, of course. I had started to do that mainly with d__1; then there are
many cases where the same variable was reused whereas we would prefer to create
yet another one with a more explicit name.

{quote}
testDiagonalRosen() is a copy/paste leftover from CMAES, should be removed
{quote}
OK, I'll do it in the next commit.

{quote}
We should shink about removing rescue as proposed by Mike Powell.
{quote}
I'm all for anything that leads to removing unnecessary lines of code :)
If you are indeed confident that, in most cases, the added complexity is not
worth it, I'll just delete 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,
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-15 Thread Dr. Dietmar Wolz (JIRA)

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

Dr. Dietmar Wolz commented on MATH-621:
---

{quote}
I see that you hard-coded the offset in most places instead of using
INDEX_OFFSET. I still think that this place-holder would be useful to keep
track of places where the index variables might have been set to fit with the
Fortran 1-based counting... Don't you?

I am not convinced yet. I thought INDEX_OFFSET as a tool to support the
conversion. If you don't use
INDEX_OFFSET in the for loops (for int i = INDEX_OFFSET ...) I don't see why to
introduce it artificially
in other places. The final aim should be to get rid of the
Fortran-Arrays/Matrices and have 0-based access. I don't see
it essential to maintain INDEX_OFFSET as a kind of back reference to the old
Fortran code in the future.
We have the unit tests as regression test.

Just try to convert one method - lets say prelim - the way you want to have it.
The working 0-based version 0.4 should make this easy. Then lets have a look at
it.
I suspect it to become rather ugly using INDEX_OFFSET in all places. But then we
also should convert the for loops as (for int i = INDEX_OFFSET ...) so that
the code runs
again with INDEX_OFFSET=1. If you then really think it is better this way, I
will help to
convert the other methods.

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,
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] [Commented] (CODEC-127) Non-ascii characters in source files

2011-08-15 Thread Gary D. Gregory (JIRA)


[ 
https://issues.apache.org/jira/browse/CODEC-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085104#comment-13085104
 ] 

Gary D. Gregory commented on CODEC-127:
---

Sebb:

I get errors when I try your perl script on Windows with the latest perl (64 
bit) from ActiveState. Rather than use this space to figure out why, can you 
please run it again and check if we are done with this ticket? 

Thank you,
Gary

 Non-ascii characters in source files
 

 Key: CODEC-127
 URL: https://issues.apache.org/jira/browse/CODEC-127
 Project: Commons Codec
  Issue Type: Bug
Reporter: Sebb

 Some of the test cases include characters in a native encoding (possibly 
 UTF-8), rather than using Unicode escapes.
 This can cause a problem for IDEs if they don't know the encoding (e.g. cause 
 compilation errors, which is how I found the issue), and possibly some 
 transformations may corrupt the contents, e.g. fixing EOL.
 I think we should have a rule of using Unicode escapes for all such non-ascii 
 characters.
 It's particularly important for non-ISO-8859-1 characters.
 Some example classes with non-ascii characters:
 {code}
 binary\Base64Test.java:96 byte[] decode = 
 b64.decode(SGVsbG{´┐¢´┐¢´┐¢´┐¢´┐¢´┐¢}8gV29ybGQ=);
 language\ColognePhoneticTest.java:110 {m├Ânchengladbach, 
 664645214},
 language\ColognePhoneticTest.java:130 String[][] data = 
 {{bergisch-gladbach, 174845214}, {M├╝ller-L├╝denscheidt, 65752682}};
 language\ColognePhoneticTest.java:137 {Meyer, M├╝ller},
 language\ColognePhoneticTest.java:143 {ganz, G├ñnse},
 language\DoubleMetaphoneTest.java:1222 
 this.getDoubleMetaphone().isDoubleMetaphoneEqual(´┐¢, S);
 language\DoubleMetaphoneTest.java:1227 
 this.getDoubleMetaphone().isDoubleMetaphoneEqual(´┐¢, N);
 language\SoundexTest.java:367 if (Character.isLetter('´┐¢')) {
 language\SoundexTest.java:369 Assert.assertEquals(´┐¢000, 
 this.getSoundexEncoder().encode(´┐¢));
 language\SoundexTest.java:375 Assert.assertEquals(, 
 this.getSoundexEncoder().encode(´┐¢));
 language\SoundexTest.java:387 if (Character.isLetter('´┐¢')) {
 language\SoundexTest.java:389 Assert.assertEquals(´┐¢000, 
 this.getSoundexEncoder().encode(´┐¢));
 language\SoundexTest.java:395 Assert.assertEquals(, 
 this.getSoundexEncoder().encode(´┐¢));
 {code}
 The characters are probably not correct above, because I used a crude perl 
 script to find them:
 {code}
 perl ne $.=1 if $s ne $ARGV;print qq($ARGV:$. $_) if m/\P{ASCII}/;$s=$ARGV; 
 */*.java
 {code}
 language\SoundexTest.java:367 in particular is incorrect, because it's 
 supposed to be a single character.
 Now one might think that native2ascii -encoding UTF-8 would fix that, but it 
 gives:
 if (Character.isLetter('\ufffd'))
 which is an unknown character.
 Similarly for binary\Base64Test.java:96.
 It's not all that clear what the Unicode escapes should be in these cases, 
 but probably not the unknown character.
 [Possibly the characters got mangled at some point, or maybe they have always 
 been wrong]
 The ColognePhoneticTest.java cases are less serious, as the characters are 
 valid ISO-8859-1 (accented German), but given that the rest of the file uses 
 unicode escaps, I think they should be changed too (but add comments to say 
 what they are, e.g. o-umlaut, u-umlaut)

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

59 matches

Mail list logo