[jira] [Created] (COMPRESS-191) Too relaxed tar detection in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)
Jukka Zitting created COMPRESS-191:
--

 Summary: Too relaxed tar detection in ArchiveStreamFactory
 Key: COMPRESS-191
 URL: https://issues.apache.org/jira/browse/COMPRESS-191
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Affects Versions: 1.4.1, 1.4, 1.3, 1.2
Reporter: Jukka Zitting
Priority: Minor


The relaxed tar detection logic added in COMPRESS-177 unfortunately matches
also some non-tar files like a [test AIFF 
file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
 that Apache Tika uses. It would be good to improve the detection heuristics to 
still match files like the one in COMPRESS-177 but avoid false positives like 
the AIFF file in Tika.

--
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] (COMPRESS-191) Too relaxed tar detection in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)

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

Jukka Zitting updated COMPRESS-191:
---

Attachment: 0001-COMPRESS-191-Too-relaxed-tar-detection-in-ArchiveStr.patch

The attached patch adds heuristics for verifying the tar header checksum, and 
uses that mechanism to better avoid false positives in ArchiveStreamFactory.

> Too relaxed tar detection in ArchiveStreamFactory
> -
>
> Key: COMPRESS-191
> URL: https://issues.apache.org/jira/browse/COMPRESS-191
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.2, 1.3, 1.4, 1.4.1
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tar
> Attachments: 
> 0001-COMPRESS-191-Too-relaxed-tar-detection-in-ArchiveStr.patch
>
>
> The relaxed tar detection logic added in COMPRESS-177 unfortunately matches
> also some non-tar files like a [test AIFF 
> file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
>  that Apache Tika uses. It would be good to improve the detection heuristics 
> to still match files like the one in COMPRESS-177 but avoid false positives 
> like the AIFF file in Tika.

--
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] (COMPRESS-191) Too relaxed tar detection in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)

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

Jukka Zitting updated COMPRESS-191:
---

Description: The relaxed tar detection logic added in COMPRESS-177 
unfortunately matches also some non-tar files like a [test AIFF 
file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
 that Apache Tika uses. It would be good to improve the detection heuristics to 
still match files like the one in COMPRESS-177 but avoid false positives like 
the AIFF file in Tika.  (was: The relaxed tar detection logic added in 
COMPRESS-177 unfortunately matches
also some non-tar files like a [test AIFF 
file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
 that Apache Tika uses. It would be good to improve the detection heuristics to 
still match files like the one in COMPRESS-177 but avoid false positives like 
the AIFF file in Tika.)
 Issue Type: Bug  (was: Improvement)

> Too relaxed tar detection in ArchiveStreamFactory
> -
>
> Key: COMPRESS-191
> URL: https://issues.apache.org/jira/browse/COMPRESS-191
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.2, 1.3, 1.4, 1.4.1
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tar
> Attachments: 
> 0001-COMPRESS-191-Too-relaxed-tar-detection-in-ArchiveStr.patch
>
>
> The relaxed tar detection logic added in COMPRESS-177 unfortunately matches 
> also some non-tar files like a [test AIFF 
> file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
>  that Apache Tika uses. It would be good to improve the detection heuristics 
> to still match files like the one in COMPRESS-177 but avoid false positives 
> like the AIFF file in Tika.

--
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] (COMPRESS-191) Too relaxed tar detection in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)

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

Jukka Zitting updated COMPRESS-191:
---

Description: The relaxed tar detection logic added in COMPRESS-117 
unfortunately matches also some non-tar files like a [test AIFF 
file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
 that Apache Tika uses. It would be good to improve the detection heuristics to 
still match files like the one in COMPRESS-117 but avoid false positives like 
the AIFF file in Tika.  (was: The relaxed tar detection logic added in 
COMPRESS-177 unfortunately matches also some non-tar files like a [test AIFF 
file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
 that Apache Tika uses. It would be good to improve the detection heuristics to 
still match files like the one in COMPRESS-177 but avoid false positives like 
the AIFF file in Tika.)

> Too relaxed tar detection in ArchiveStreamFactory
> -
>
> Key: COMPRESS-191
> URL: https://issues.apache.org/jira/browse/COMPRESS-191
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.2, 1.3, 1.4, 1.4.1
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: tar
> Attachments: 
> 0001-COMPRESS-191-Too-relaxed-tar-detection-in-ArchiveStr.patch
>
>
> The relaxed tar detection logic added in COMPRESS-117 unfortunately matches 
> also some non-tar files like a [test AIFF 
> file|https://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/test/resources/test-documents/testAIFF.aif]
>  that Apache Tika uses. It would be good to improve the detection heuristics 
> to still match files like the one in COMPRESS-117 but avoid false positives 
> like the AIFF file in Tika.

--
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] (COMPRESS-192) Allow setting of the zip encoding in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)
Jukka Zitting created COMPRESS-192:
--

 Summary: Allow setting of the zip encoding in ArchiveStreamFactory
 Key: COMPRESS-192
 URL: https://issues.apache.org/jira/browse/COMPRESS-192
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Reporter: Jukka Zitting
Priority: Minor


When using the ArchiveStreamFactory it's currently not possible to control the 
encoding used by zip archive streams. Having that feature available in 
ArchiveStreamFactory would be useful for TIKA-936.

--
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] (COMPRESS-192) Allow setting of the zip encoding in ArchiveStreamFactory

2012-06-30 Thread Jukka Zitting (JIRA)

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

Jukka Zitting updated COMPRESS-192:
---

Attachment: 0001-COMPRESS-192-Allow-setting-of-the-zip-encoding-in-Ar.patch

The attached patch adds get/setZipEncoding methods to ArchiveStreamFactory and 
uses them to control the encoding used in zip streams.

> Allow setting of the zip encoding in ArchiveStreamFactory
> -
>
> Key: COMPRESS-192
> URL: https://issues.apache.org/jira/browse/COMPRESS-192
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: encoding, zip
> Attachments: 
> 0001-COMPRESS-192-Allow-setting-of-the-zip-encoding-in-Ar.patch
>
>
> When using the ArchiveStreamFactory it's currently not possible to control 
> the encoding used by zip archive streams. Having that feature available in 
> ArchiveStreamFactory would be useful for TIKA-936.

--
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-808) SimplexSolver returns values out of constraints bounds

2012-06-30 Thread Alexey Slepov (JIRA)
Alexey Slepov created MATH-808:
--

 Summary: SimplexSolver returns values out of constraints bounds
 Key: MATH-808
 URL: https://issues.apache.org/jira/browse/MATH-808
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
 Environment: win7 64, eclipse 3.7, Apache Math 3.0
Reporter: Alexey Slepov
Priority: Blocker
 Fix For: 3.0
 Attachments: InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt

SimplexSolver gives back result that doesn't match constraints

--
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-808) SimplexSolver returns values out of constraints bounds

2012-06-30 Thread Alexey Slepov (JIRA)

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

Alexey Slepov updated MATH-808:
---

Attachment: InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt

Test report file. Keep attention to 'EXCEPTION: Wrong equation' lines

> SimplexSolver returns values out of constraints bounds
> --
>
> Key: MATH-808
> URL: https://issues.apache.org/jira/browse/MATH-808
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: win7 64, eclipse 3.7, Apache Math 3.0
>Reporter: Alexey Slepov
>Priority: Blocker
>  Labels: SimplexSolver, constraints, math, unexpected
> Fix For: 3.0
>
> Attachments: InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt
>
>
> SimplexSolver gives back result that doesn't match constraints

--
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-808) SimplexSolver returns values out of constraints bounds

2012-06-30 Thread Alexey Slepov (JIRA)

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

Alexey Slepov updated MATH-808:
---

Attachment: InputOrientedDEAAlgorithm.java

Source code file. Take a look into 
public PointValuePair findEntityOptimum(EntityArgument entity, GoalType 
goalType) throws Exception
method

> SimplexSolver returns values out of constraints bounds
> --
>
> Key: MATH-808
> URL: https://issues.apache.org/jira/browse/MATH-808
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: win7 64, eclipse 3.7, Apache Math 3.0
>Reporter: Alexey Slepov
>Priority: Blocker
>  Labels: SimplexSolver, constraints, math, unexpected
> Fix For: 3.0
>
> Attachments: InputOrientedDEAAlgorithm.java, 
> InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt
>
>
> SimplexSolver gives back result that doesn't match constraints

--
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-808) SimplexSolver returns values out of constraints bounds

2012-06-30 Thread Alexey Slepov (JIRA)

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

Alexey Slepov updated MATH-808:
---

Attachment: InputOrientedDEAAlgorithmTest.java

Unit test to run to repeat the unexpected SimplexSolver behavior

> SimplexSolver returns values out of constraints bounds
> --
>
> Key: MATH-808
> URL: https://issues.apache.org/jira/browse/MATH-808
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: win7 64, eclipse 3.7, Apache Math 3.0
>Reporter: Alexey Slepov
>Priority: Blocker
>  Labels: SimplexSolver, constraints, math, unexpected
> Fix For: 3.0
>
> Attachments: InputOrientedDEAAlgorithm.java, 
> InputOrientedDEAAlgorithmTest.java, 
> InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt
>
>
> SimplexSolver gives back result that doesn't match constraints

--
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-426) HTTP URL query string not part of cache key

2012-06-30 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/VFS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404493#comment-13404493
 ] 

Gary D. Gregory commented on VFS-426:
-

I added the following test case to illustrate the issue:

org.apache.commons.vfs2.provider.http.test.HttpFilesCacheTestCase

Changing {{org.apache.commons.vfs2.provider.AbstractFileName#getKey(}} to:

{code:java}
private String getKey()
{
if (key == null)
{
key = createURI();
}
return key;
}
{code}


or better:

{code:java}
private String getKey()
{
if (key == null)
{
key = getURI();
}
return key;
}
{code}

does work for the new test case and no other test fails.

Note that this can make the {{key}} and the {{uri}} ivars the same depending on 
the implementation of {{createURI()}}.

*Does anyone see a problem with this?*

*I'll wait a day or so for comments before committing.*



> HTTP URL query string not part of cache key
> ---
>
> Key: VFS-426
> URL: https://issues.apache.org/jira/browse/VFS-426
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Daniel Bergholm
>
> I am using commons-vfs amongst other things to download http files. When 
> resolving different URLs where only the query string differs, the default 
> cache returns the wrong URL sometimes (returning a previously accessed URL 
> where only the query string differs).
> I think this is because the key property of URLFileName does not include the 
> query string. The {code:java}createURI(){code} method of URLFileName does 
> include it, but when constructing the key the {code:java}createURI(boolean 
> useAbsolutePath, boolean usePassword){code} method of AbstractFileName is 
> used. This method only includes the path. 

--
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-808) SimplexSolver returns values out of constraints bounds

2012-06-30 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404497#comment-13404497
 ] 

Gilles commented on MATH-808:
-

Could you please simplify the test case? It should contain the bare minimum of 
code necessary to show the buggy behaviour. The unit test should also contain a 
method from the {{org.junit.Assert}} class in order to indicate which result is 
expected.
Thanks.


> SimplexSolver returns values out of constraints bounds
> --
>
> Key: MATH-808
> URL: https://issues.apache.org/jira/browse/MATH-808
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: win7 64, eclipse 3.7, Apache Math 3.0
>Reporter: Alexey Slepov
>Priority: Blocker
>  Labels: SimplexSolver, constraints, math, unexpected
> Fix For: 3.0
>
> Attachments: InputOrientedDEAAlgorithm.java, 
> InputOrientedDEAAlgorithmTest.java, 
> InputOrientedDEAAlgorithm_12-6-30_15-32-52.test.txt
>
>
> SimplexSolver gives back result that doesn't match constraints

--
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] (CLI-226) createNumber() in TypeHandler cannot work with some Locale

2012-06-30 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/CLI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404503#comment-13404503
 ] 

Gary D. Gregory commented on CLI-226:
-

The nice way to fix this is to rewrite 
{{org.apache.commons.cli.TypeHandler.createNumber(String)}} like this:

{code:java}
public static Number createNumber(String str) throws ParseException
{
try
{
   return NumberFormat.getNumberInstance().parse(str);
}
catch (NumberFormatException e)
{
throw new ParseException(e.getMessage());
} catch (java.text.ParseException e) 
{
throw new ParseException(e.getMessage());
}
}
{code}

But this makes one assert fail in 
{{org.apache.commons.cli.PatternOptionBuilderTest.testNumberPattern()}}

Thoughts?

> createNumber() in TypeHandler cannot work with some Locale
> --
>
> Key: CLI-226
> URL: https://issues.apache.org/jira/browse/CLI-226
> Project: Commons CLI
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Olivier Sechet
>  Labels: i18n
>
> The {{createNumber()}} method in the {{TypeHandler}} class expects the 
> decimal separator to be a dot ({{'.'}}). However the dot is not used in all 
> the languages as a decimal separator. Most of the European countries, Russia 
> and a lot of others countries uses a comma ({{','}}).
> With the corresponding {{Locale}}, the {{createNumber()}} method fails, 
> throwing an exception.
> For example:
> {code:title=Type.java|borderStyle=solid}
> public class Type {
> public static void main(final String[] args) {
> java.util.Locale.setDefault(java.util.Locale.GERMANY);
> String text = 
> java.text.NumberFormat.getNumberInstance().format(12.34);
> Number nb = org.apache.commons.cli.TypeHandler.createNumber(text);
> System.out.println(nb);
> }
> }
> {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-809) Expressions and functions interpreter

2012-06-30 Thread Guillaume Chauvet (JIRA)
Guillaume Chauvet created MATH-809:
--

 Summary: Expressions and functions interpreter
 Key: MATH-809
 URL: https://issues.apache.org/jira/browse/MATH-809
 Project: Commons Math
  Issue Type: New Feature
Affects Versions: 3.1
Reporter: Guillaume Chauvet
Priority: Trivial


Expressions and functions interpreter forked from exp4j library 
(http://projects.congrace.de/exp4j, an Apache 2 project). This implementation 
use Dijkstra's Shunting Yard Algorithm. The patch also allows parsing of E 
notation numbers in expressions.

--
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-809) Expressions and functions interpreter

2012-06-30 Thread Guillaume Chauvet (JIRA)

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

Guillaume Chauvet updated MATH-809:
---

Attachment: interpreter.patch

> Expressions and functions interpreter
> -
>
> Key: MATH-809
> URL: https://issues.apache.org/jira/browse/MATH-809
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Guillaume Chauvet
>Priority: Trivial
> Attachments: interpreter.patch
>
>
> Expressions and functions interpreter forked from exp4j library 
> (http://projects.congrace.de/exp4j, an Apache 2 project). This implementation 
> use Dijkstra's Shunting Yard Algorithm. The patch also allows parsing of E 
> notation numbers in expressions.

--
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-809) Expressions and functions interpreter

2012-06-30 Thread Gilles (JIRA)

[ 
https://issues.apache.org/jira/browse/MATH-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404594#comment-13404594
 ] 

Gilles commented on MATH-809:
-

Thanks for your interest in Commons Math. A new feature such as this one should 
first be discussed in the "dev" ML:
http://commons.apache.org/math/mail-lists.html

However something similar (IIRC) came up some time ago, and the conclusion was 
that it didn't belong in the Commons Math project. The reason was that the 
focus here is on numerical methods, not on input/output (in your case: parsing 
a string that happens to represent a mathematical function).

Your interpreter library could of course _depend_ on the Commons Math library. 
But I cannot see how it would be more useful by being _within_ Commons Math 
itself.

If you are not satified with this explanation, please post a message to the ML 
(using a prefix of "[Math]" in the subject line, as the list is shared with 
other "Commons" projects).

> Expressions and functions interpreter
> -
>
> Key: MATH-809
> URL: https://issues.apache.org/jira/browse/MATH-809
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Guillaume Chauvet
>Priority: Trivial
> Attachments: interpreter.patch
>
>
> Expressions and functions interpreter forked from exp4j library 
> (http://projects.congrace.de/exp4j, an Apache 2 project). This implementation 
> use Dijkstra's Shunting Yard Algorithm. The patch also allows parsing of E 
> notation numbers in expressions.

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