[jira] [Created] (MATH-743) Use enums in package transform
Use enums in package transform
--
Key: MATH-743
URL: https://issues.apache.org/jira/browse/MATH-743
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
As discussed on the mailing-list, enums could be used in the package
{{transform}}
# An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
inverse transform is to be computed. This will replace the pair
{{transform}}/{{inverseTransform}}
# An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
in each transform class, in order to specify the normalization that should be
used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205155#comment-13205155 ] Christian Hammers commented on CODEC-133: - I've clean up the files, wrote a lot of unit tests and added wrapper that accept "byte[] plaintext" so that legacy password hashes that were generated by other sources using ISO-8859-1 strings can somehow be verified. The following files would be added: M src/main/java/org/apache/commons/codec/digest/DigestUtils.java A src/main/java/org/apache/commons/codec/digest/Md5Crypt.java A src/main/java/org/apache/commons/codec/digest/README.WORK A src/main/java/org/apache/commons/codec/digest/Sha256Crypt.java A src/main/java/org/apache/commons/codec/digest/Sha512Crypt.java A src/main/java/org/apache/commons/codec/digest/UnixCrypt.java M src/test/java/org/apache/commons/codec/digest M src/test/java/org/apache/commons/codec/digest/DigestUtilsTest.java A src/test/java/org/apache/commons/codec/digest/Md5CryptTest.java A src/test/java/org/apache/commons/codec/digest/Sha256CryptTest.java A src/test/java/org/apache/commons/codec/digest/Sha512CryptTest.java A src/test/java/org/apache/commons/codec/digest/UnixCryptTest.java Before I upload them here, I wonder what exactly has to be done regarding the licenses. If I remember correctly only source files with the Apache licence header are accepted, right? Was it enough that Jonathan Abbey, author of the Java ports, statet his consent in the issue tracker or do he also have to submit this ICLA fax? (I already did so a while ago for another Apache project.) > Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash > variants > > > Key: CODEC-133 > URL: https://issues.apache.org/jira/browse/CODEC-133 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Christian Hammers > Labels: MD5, SHA-512, crypt(3), crypto, hash > > The Linux libc6 crypt(3) function, which is used to generate e.g. the > password hashes in /etc/shadow, is available in nearly all other programming > languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and > offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt > and several iterations to make rainbow table attacks harder. Thus they are > widely used to store user passwords. > Java, though, has due it's platform independence, no direct access to the > libc functions and still lacks an proper port of the crypt(3) function. > I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES > based crypt(3) method but would also like to see the much stronger algorithms. > There are other bug reports like DIRSTUDIO-738 that demand those crypt > variants for some specific applications so there it would benefit other > Apache projects as well. > Java ports of most of the specific crypt variants are already existing, but > they would have to be cleaned up, properly tested and license checked: > ftp://ftp.arlut.utexas.edu/pub/java_hashes/ > I would be willing to help here by cleaning the source code and writing unit > tests etc. but I'd like to generally know if you are interested and if > there's someone who can do a code review (it's security relevant after all > and I'm no crypto guy) > bye, > -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-100) Possibiblity to define eviction policies
[ https://issues.apache.org/jira/browse/POOL-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-100. -- Resolution: Fixed Now fully implemented. There is probably scope to extend / modify the interfaces added for this. Any sy=uch requests should be raised as a new enhancement request. > Possibiblity to define eviction policies > > > Key: POOL-100 > URL: https://issues.apache.org/jira/browse/POOL-100 > Project: Commons Pool > Issue Type: New Feature > Environment: N/A >Reporter: David J. M. Karlsen > Fix For: 2.0 > > > It would be nice to be able to define eviction policies, including specifying > a maximum age (since creation / instanciation) for objects. > By doing this KeyedObjectPool could supply fresh objects from makeObject( > Object key ) if data has changed in back-end. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-400) Add a FileSelector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-400:
Summary: Add a FileSelector based on regular expressions (was: Selector
based on regular expressions)
> Add a FileSelector based on regular expressions
> ---
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-400) Add a FileSelector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204970#comment-13204970
]
Gary D. Gregory commented on VFS-400:
-
I committed a first cut called {{PatternFileSelector}} with the unit test
{{PatternFileSelectorTest}}
> Add a FileSelector based on regular expressions
> ---
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-742) Please make PolynomialSplineFunction Serializable
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leandro Ariel Pezzente updated MATH-741: Attachment: TestHypergeometric.java Hypergeometric.java UnivariateFunctionFactory.java UnivariateFuncionFactory.java is the main abstract class. Hypergeometric.java is an Hypergeometric function implementation constructed using this abstract superclass. TestHypergeometric.java is a Junit test that check the assertion between the Hypergeometric and 2 very well know equialities. > Univariate Function Series Abstract Factory Implementation > -- > > Key: MATH-741 > URL: https://issues.apache.org/jira/browse/MATH-741 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Leandro Ariel Pezzente >Priority: Minor > Attachments: Hypergeometric.java, TestHypergeometric.java, > UnivariateFunctionFactory.java > > > To Implement an abstract class for witch Univariate functions constructed > using functional series. This abstract class must resolve all terms sums > using recursive iterative methods. Classes subclassed by this abstract > function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-207) GenericKeyedObjectPool.clear() has unnecessary null check of objectDequeue
[
https://issues.apache.org/jira/browse/POOL-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-207.
--
Resolution: Fixed
Thanks for the analysis.
> GenericKeyedObjectPool.clear() has unnecessary null check of objectDequeue
> --
>
> Key: POOL-207
> URL: https://issues.apache.org/jira/browse/POOL-207
> Project: Commons Pool
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> GenericKeyedObjectPool.clear() registers the key, and then checks if the
> objectDeque obtained by using the key is null.
> Since register creates the key entry in poolMap, the retrieved value should
> never be null.
> If it is nullm then AFAICT that is a code bug, which should be reported
> rather than ignored.
> [If it were possible for the key to be null, then the same null check should
> be added to the private destroy method.]
> Also, register returns the ObjectDeque, so the clear() code could be
> simplified; rather than
> {code}
> register(key);
> try {
> ObjectDeque objectDeque = poolMap.get(key);
> if (objectDeque == null) {
> return;
> }
> ...
> {code}
> the method could use:
> {code}
> ObjectDeque objectDeque = register(key);
> try {
> ...
> {code}
> Similarly for the private destroy method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-741) Univariate Function Series Abstract Factory Implementation
Univariate Function Series Abstract Factory Implementation -- Key: MATH-741 URL: https://issues.apache.org/jira/browse/MATH-741 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Reporter: Leandro Ariel Pezzente Priority: Minor To Implement an abstract class for witch Univariate functions constructed using functional series. This abstract class must resolve all terms sums using recursive iterative methods. Classes subclassed by this abstract function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204625#comment-13204625 ] Luc Maisonobe commented on MATH-650: On the Android platform I get this for the total time (i.e using the "time" unix command to launch the dalvik virtual machine): * literal arrays: between 0.09 and 0.12 s * resources: between 0.13 and 0.15 s * recompute: almost constant 0.25 s > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204621#comment-13204621 ] Gilles commented on MATH-650: - I'd be interested to also see the total time... :-) > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204607#comment-13204607 ] Gilles commented on MATH-740: - I should note that the above numbers seem to vary wildly from run to run (my machine is fairly loaded at the moment) but the trend is there: Always too slow. Looking at the code, it seems that there are potential source of inefficiencies (like the missing "final" keywords which I've added, in a recent commit for "atan") or accessing array locations (instead of storing the value in a local variable), but each of those changes is likely to not demonstrate a significant improvement. :( > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.1 > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204602#comment-13204602 ] Luc Maisonobe commented on MATH-650: @Sebb, OK, but we need to document this in case users want to extend the tables by themselves. @Gilles, I used System.nanotime at test start and at test end. So this does not include JVM start up which adds up to the results. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204599#comment-13204599 ] Gilles commented on MATH-650: - Did you time the whole application (including the JVM startup time) or only the test? > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204593#comment-13204593 ] Sebb commented on MATH-650: --- I agree that (re)computing the tables at build time is unnecessary. Seems to me there is going to be little or no maintenance needed, now the tables have been built. So why don't we just move the calculations to a test case which compares the results with the fixed data? If we do ever need to extend the tables, we update the test case, and then fix the data so the test passes. i.e. we treat the data the same way we treat the code. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-740) Some "FastMath" functions are slow
Some "FastMath" functions are slow -- Key: MATH-740 URL: https://issues.apache.org/jira/browse/MATH-740 Project: Commons Math Issue Type: Wish Reporter: Gilles Priority: Minor Fix For: 3.1 >From the two benchmarks we currently have in "FastMathTestPerfomance", we have >that the following functions are much slower in "FastMath" than in either >"Math" or "StrictMath" (the performance *loss*, for each of the benchmarks, is >given in parentheses): * log10 (46%, 36%) * log1p (68%, 112%) * tan (11%, 61%) * atan (26%, 125%) * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204559#comment-13204559 ] Luc Maisonobe commented on MATH-650: I finally succeeded in running on my tablet a slightly modified version of Gilles test (thanks for putting this together Gilles). The test involves computing 1abs, 10 floor, 30 sin, 30 cos, 50 sqrt, 5 exp, 2 log which is representative of the small application we developed. The results shown represent the time for all computation, using only FastMath methods. The tests were run 10 times, with a fresh start each time. Android tablet, Nvidia Tegra2 chipset at 1GHz, 1Gb memory, running Android 3.0.1: * literal arrays:mean 35.1 ms, standard deviation 0.658 ms * resources loading: mean 55.2 ms, standard deviation 0.651 ms * table computation: mean 155.4 ms, standard deviation 0.850 ms Desktop computer, quadcore AMD phenom 9550 quadcore 64 bits at 2.2 GHz, 6 Gb memore, running Debian Linux wheezy with OpenJDK 6 20.0b12: * literal arrays:mean 71.4 ms, standard deviation 0.449 ms * resources loading: mean 70.3 ms, standard deviation 1.731 ms * table computation: mean 132.9 ms, standard deviation 1.661 ms These results show that on the Android platform, the gain from precomputed tables is much larger than on the desktop. In fact, the test runs at least twice faster on Android than on the desktop for precomputed table, and 17% slower when tables are computed at startup. The difference between literal arrays and resources slightly favors literal arrays on the Android platforms, but on desktop the difference is below standard deviation. In any case, it is quite small (20 ms) and therefore not significant as it is a one time startup cost only. So I would conclude that precomputing the tables is a worthwhile improvement. Now considering how pre-computed tables should be set up, I have no clear cut opinion. I would like to not have the tables in the source distribution and have them generated automatically at build time. It seems to me maven does have both generate-source and generate-resource goals in its lifecycle, but these goals are triggered only by specific plugins (antlr, build-helper, ...). These plugins are not suitable for our case which merely consist in compiling a first standalone class, then run it to build either the java file or the resource file. Any ideas about that ? > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204416#comment-13204416
]
Luc Maisonobe commented on MATH-707:
OK then, sorry for the misunderstanding.
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-175) GNU Tar sometimes uses binary encoding for UID and GID
[ https://issues.apache.org/jira/browse/COMPRESS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204411#comment-13204411 ] Thomas Hallgren commented on COMPRESS-175: -- Here's a link to a file that fails to unpack without the patch: http://forge.puppetlabs.com/system/releases/c/cparedes/cparedes-puppet_opsview-0.2.tar.gz > GNU Tar sometimes uses binary encoding for UID and GID > -- > > Key: COMPRESS-175 > URL: https://issues.apache.org/jira/browse/COMPRESS-175 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.3 >Reporter: Thomas Hallgren > Attachments: TarArchiveEntry.patch > > > Some tar files have UID and GID fields that start with the binary marker > 0x80. The TarArchiveEntry is unable to cope with that since it assumes that > UID and GID are always ASCII. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204401#comment-13204401
]
Rikard Oxenstrand commented on VFS-400:
---
My thought was to use this to filter out files based on some naming standard
(Prefixed/suffixed file names) and didn't want to involve directories since the
directory/server names could include the filter criteria if you change location
of the files. But I guess that it could be useful to filter out certain
sub-directories in some scenarios.
How about using getPath instead (fileInfo.getFile().getName().getPath())? Then
you can filter on both directories and files while still being able to move the
files to a different location without any need to change the filter expression.
The part of the URI that is before the path is already filtered when you
resolve the file.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
