[jira] [Updated] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[ https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl D. Gierach updated MATH-1373: -- Attachment: MATH-1373.patch this patch includes a revision to unit test which calcuates all expected shape and scale parameters based on the mean and variance of the unscaled data. > In LogNormalDistribution.java, it appears shape & scale are > reversed/mis-labelled. > -- > > Key: MATH-1373 > URL: https://issues.apache.org/jira/browse/MATH-1373 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Karl D. Gierach >Priority: Minor > Attachments: MATH-1373.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I compute the logshape and log scale based on the formulas on > wikipedia's lognormal distribution page that use empirical mean and variance, > I found that the getNumericalMean() method was not returning the empirical > mean. > However, upon just trying to reverse the shape and scale parameters in the > constructor proved to fix the problem, and the object then returns the > correct empirical mean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[ https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336901#comment-15336901 ] Karl D. Gierach commented on MATH-1373: --- I will come up with a patch based on github: http://git-wip-us.apache.org/repos/asf/commons-math.git Also, it appears the parameters are reversed in getNumericalVariance() as well. Sound OK? Thanks, Karl > In LogNormalDistribution.java, it appears shape & scale are > reversed/mis-labelled. > -- > > Key: MATH-1373 > URL: https://issues.apache.org/jira/browse/MATH-1373 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Karl D. Gierach >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > When I compute the logshape and log scale based on the formulas on > wikipedia's lognormal distribution page that use empirical mean and variance, > I found that the getNumericalMean() method was not returning the empirical > mean. > However, upon just trying to reverse the shape and scale parameters in the > constructor proved to fix the problem, and the object then returns the > correct empirical mean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JEXL-200) Support for dynamic scripting in jexl scripts
[
https://issues.apache.org/jira/browse/JEXL-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-200:
---
Description:
Allow for dynamically defined functions inside a script where the definition of
the function comes from a string expression, for example:
{code}
var x = function(y) => "return y+2";
{code}
the defined function should be accessible after its definition is successfully
parsed as ordinary function, and can be evaluated in the current context.
{code}
if (x(40) eq 42) {...
{code}
I think the idea of dynamic script evaluation is not unusual, and though to
some extent can be implemented via side-added functions like *eval(expr)* a
dedicated syntax for this will benefit from the simplicity of ordinal functions
and the ability to control mapping of the arguments between a caller and the
defined function.
was:
Allow for dynamically defined functions inside a script where the definition of
the function comes from a string expression, for example:
{code}
def x(y) = "return y+2";
{code}
the defined function should be accessable after its definition is successfully
parsed as ordinary function, and can be evaluated in the current context.
{code}
if (x(40) eq 42) {...
{code}
I think the idea of dynamic script evaluation is not unusual, and though to
some extent can be implemented via side-added functions like *eval(expr)* a
dedicated syntax for this will benefit from the simplicity of ordinal functions
and the ability to control mapping of the arguments between a caller and the
defined function.
> Support for dynamic scripting in jexl scripts
> -
>
> Key: JEXL-200
> URL: https://issues.apache.org/jira/browse/JEXL-200
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Allow for dynamically defined functions inside a script where the definition
> of the function comes from a string expression, for example:
> {code}
> var x = function(y) => "return y+2";
> {code}
> the defined function should be accessible after its definition is
> successfully parsed as ordinary function, and can be evaluated in the current
> context.
> {code}
> if (x(40) eq 42) {...
> {code}
> I think the idea of dynamic script evaluation is not unusual, and though to
> some extent can be implemented via side-added functions like *eval(expr)* a
> dedicated syntax for this will benefit from the simplicity of ordinal
> functions and the ability to control mapping of the arguments between a
> caller and the defined function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[
https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336549#comment-15336549
]
Karl D. Gierach commented on MATH-1373:
---
The problem is that in the method shape & scale are simply reversed:
@Override
public double getNumericalMean() {
double s = shape;
return FastMath.exp(scale + (s * s / 2));
}
It should be:FastMath.exp( shape + (scale * scale / 2 ) );
In any case here is a unit test code snippet that illustrates the problem:
var defaultScale = 1.0; // aka variance
var mean = 12.2;
var meanSquared = mean * mean
// compute sigma (log scale) parameter of the lognormal distribution.
// according to formulas on Wikipedia
var logScale =
Math.sqrt(
Math.log( 1.0 + (defaultScale / meanSquared) )
)
var logShape = Math.log( mean /
Math.sqrt( 1.0 + ( defaultScale / meanSquared
) )
)
println( "verifyLogNormalParms(): initializing with: scale/shape=" +
logScale + ", " + logShape )
// parameter order according to api docs: scale shape/location
// here, parameters are reversed, and produce the correct result
var dist = new LogNormalDistribution( logShape, logScale );
var numMean = dist.getNumericalMean()
if( Math.abs( numMean - mean ) > 0.01 ) {
println( "verifyLogNormalParms(): mean is NOT OK: " + numMean )
assertTrue( false )
}
else {
println( "verifyLogNormalParms(): mean is OK: " + numMean )
}
> In LogNormalDistribution.java, it appears shape & scale are
> reversed/mis-labelled.
> --
>
> Key: MATH-1373
> URL: https://issues.apache.org/jira/browse/MATH-1373
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Karl D. Gierach
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When I compute the logshape and log scale based on the formulas on
> wikipedia's lognormal distribution page that use empirical mean and variance,
> I found that the getNumericalMean() method was not returning the empirical
> mean.
> However, upon just trying to reverse the shape and scale parameters in the
> constructor proved to fix the problem, and the object then returns the
> correct empirical mean.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLI-255) DefaultParser, option with long name and single dash, unlimited arguments
[
https://issues.apache.org/jira/browse/CLI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336407#comment-15336407
]
Benedikt Ritter commented on CLI-255:
-
Patches welcome!
> DefaultParser, option with long name and single dash, unlimited arguments
> -
>
> Key: CLI-255
> URL: https://issues.apache.org/jira/browse/CLI-255
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.3, 1.3.1
>Reporter: Alexander Prishchepov
>Priority: Minor
>
> If I have options with long name and single dash, DefaultParser does not
> recognize them after a list of unlimited arguments.
> Here is the test case:
> {code:java}
> public void testUnlimitedArgs() throws Exception
> {
> String[] args = new String[] {"-unlimitedOne", "one", "two",
> "-unlimitedTwo", "alpha"};
> Options options = new Options();
> options.addOption(Option.builder("unlimitedOne").hasArgs().build());
> options.addOption(Option.builder("unlimitedTwo").hasArgs().build());
> CommandLine cl = parser.parse(options, args);
> assertTrue("Confirm -unlimitedOne is set",
> cl.hasOption("unlimitedOne"));
> assertEquals("number of arg for -unlimitedOne", 2,
> cl.getOptionValues("unlimitedOne").length);
> assertTrue("Confirm -unlimitedTwo is set",
> cl.hasOption("unlimitedTwo"));
> assertEquals("number of arg for -unlimitedTwo", 1,
> cl.getOptionValues("unlimitedTwo").length);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CLI-255) DefaultParser, option with long name and single dash, unlimited arguments
[
https://issues.apache.org/jira/browse/CLI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335882#comment-15335882
]
Benedikt Ritter edited comment on CLI-255 at 6/17/16 4:33 PM:
--
I've a similar issue but basically DefaultParser doesn't work with a single
dash where the option name exceeds one character in length so -a is fine but
-ab doesn't work. I've been exercising this with a JUnit test.
{code:java}
@Test public void CliTest() throws ArgumentException
{
s_clsLogger.info("MainWithWrongNumArgsTest()");
try
{
String strCmk = "xr";
Options s_clsOptions = new Options();
Option clsOptionTstp = Option.builder(strCmk)
.valueSeparator('=')
.type(String.class)
.required()
.hasArg()
.argName("TestCommandPath=value")
.desc("A test path")
.build();
s_clsOptions.addOption(clsOptionTstp);
String[] astrCli = new String[]{String.format("-%s=cd",
strCmk)};
CommandLineParser s_clsClParser = new DefaultParser();
CommandLine clsCommandLine = s_clsClParser.parse(s_clsOptions,
astrCli, true);
if(clsCommandLine.hasOption(strCmk))
{
String strOptionValue =
clsCommandLine.getOptionValue(strCmk);
assertEquals(strOptionValue,"cd");
}
else
{
fail();
}
}
catch (Exception e)
{
s_clsLogger.error(e);
fail(e.toString());
}
finally
{
}
}
{code}
was (Author: jason.new...@nxp.com):
I've a similar issue but basically DefaultParser doesn't work with a single
dash where the option name exceeds one character in length so -a is fine but
-ab doesn't work. I've been exercising this with a JUnit test.
@Test public void CliTest() throws ArgumentException
{
s_clsLogger.info("MainWithWrongNumArgsTest()");
try
{
String strCmk = "xr";
Options s_clsOptions = new Options();
Option clsOptionTstp = Option.builder(strCmk)
.valueSeparator('=')
.type(String.class)
.required()
.hasArg()
.argName("TestCommandPath=value")
.desc("A test path")
.build();
s_clsOptions.addOption(clsOptionTstp);
String[] astrCli = new String[]{String.format("-%s=cd",
strCmk)};
CommandLineParser s_clsClParser = new DefaultParser();
CommandLine clsCommandLine = s_clsClParser.parse(s_clsOptions,
astrCli, true);
if(clsCommandLine.hasOption(strCmk))
{
String strOptionValue =
clsCommandLine.getOptionValue(strCmk);
assertEquals(strOptionValue,"cd");
}
else
{
fail();
}
}
catch (Exception e)
{
s_clsLogger.error(e);
fail(e.toString());
}
finally
{
}
}
> DefaultParser, option with long name and single dash, unlimited arguments
> -
>
> Key: CLI-255
> URL: https://issues.apache.org/jira/browse/CLI-255
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.3, 1.3.1
>Reporter: Alexander
[jira] [Comment Edited] (CLI-255) DefaultParser, option with long name and single dash, unlimited arguments
[
https://issues.apache.org/jira/browse/CLI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14660908#comment-14660908
]
Benedikt Ritter edited comment on CLI-255 at 6/17/16 4:32 PM:
--
I have the same issue. I believe that error caused in handleToken of
DefaultParser method's.
{code:java}
@Test
public void testUnlimitedArgs2() throws Exception
{
String[] args = new String[] {"-unlimitedOne", "one,two",
"-unlimitedTwo", "alpha"};
Options options = new Options();
options.addOption(Option.builder("unlimitedOne").hasArgs().valueSeparator(',').build());
options.addOption(Option.builder("unlimitedTwo").hasArgs().valueSeparator(',').build());
CommandLineParser parser = new DefaultParser();
CommandLine cl = parser.parse(options, args);
assertTrue("Confirm -unlimitedOne is set",
cl.hasOption("unlimitedOne"));
assertEquals("number of arg for -unlimitedOne", 2,
cl.getOptionValues("unlimitedOne").length);
assertTrue("Confirm -unlimitedTwo is set",
cl.hasOption("unlimitedTwo"));
assertEquals("number of arg for -unlimitedTwo", 1,
cl.getOptionValues("unlimitedTwo").length);
}
{code}
was (Author: jonas.lima):
I have the same issue. I believe that error caused in handleToken of
DefaultParser method's.
@Test
public void testUnlimitedArgs2() throws Exception
{
String[] args = new String[] {"-unlimitedOne", "one,two",
"-unlimitedTwo", "alpha"};
Options options = new Options();
options.addOption(Option.builder("unlimitedOne").hasArgs().valueSeparator(',').build());
options.addOption(Option.builder("unlimitedTwo").hasArgs().valueSeparator(',').build());
CommandLineParser parser = new DefaultParser();
CommandLine cl = parser.parse(options, args);
assertTrue("Confirm -unlimitedOne is set",
cl.hasOption("unlimitedOne"));
assertEquals("number of arg for -unlimitedOne", 2,
cl.getOptionValues("unlimitedOne").length);
assertTrue("Confirm -unlimitedTwo is set",
cl.hasOption("unlimitedTwo"));
assertEquals("number of arg for -unlimitedTwo", 1,
cl.getOptionValues("unlimitedTwo").length);
}
> DefaultParser, option with long name and single dash, unlimited arguments
> -
>
> Key: CLI-255
> URL: https://issues.apache.org/jira/browse/CLI-255
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.3, 1.3.1
>Reporter: Alexander Prishchepov
>Priority: Minor
>
> If I have options with long name and single dash, DefaultParser does not
> recognize them after a list of unlimited arguments.
> Here is the test case:
> {code:java}
> public void testUnlimitedArgs() throws Exception
> {
> String[] args = new String[] {"-unlimitedOne", "one", "two",
> "-unlimitedTwo", "alpha"};
> Options options = new Options();
> options.addOption(Option.builder("unlimitedOne").hasArgs().build());
> options.addOption(Option.builder("unlimitedTwo").hasArgs().build());
> CommandLine cl = parser.parse(options, args);
> assertTrue("Confirm -unlimitedOne is set",
> cl.hasOption("unlimitedOne"));
> assertEquals("number of arg for -unlimitedOne", 2,
> cl.getOptionValues("unlimitedOne").length);
> assertTrue("Confirm -unlimitedTwo is set",
> cl.hasOption("unlimitedTwo"));
> assertEquals("number of arg for -unlimitedTwo", 1,
> cl.getOptionValues("unlimitedTwo").length);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-75) ConfigurationKeys#COMMONS_CRYPTO_CIPHER_CLASSES_DEFAULT is not guaranteed constant
[ https://issues.apache.org/jira/browse/CRYPTO-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336393#comment-15336393 ] Benedikt Ritter commented on CRYPTO-75: --- Can you provide an example how that code would look like? We should not over complicate things. We already have that nasty code that handles the sun.nio.Buffer calls. > ConfigurationKeys#COMMONS_CRYPTO_CIPHER_CLASSES_DEFAULT is not guaranteed > constant > -- > > Key: CRYPTO-75 > URL: https://issues.apache.org/jira/browse/CRYPTO-75 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb > > ConfigurationKeys#COMMONS_CRYPTO_CIPHER_CLASSES_DEFAULT contains a > fully-qualified class name. > This is not guaranteed to be constant if the package names ever have to be > changed. > The constant should be changed to an alias that is handled by the runtime > code when creating the class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-84) Utils.getJCEProvider belongs in JceCipher class
Sebb created CRYPTO-84: -- Summary: Utils.getJCEProvider belongs in JceCipher class Key: CRYPTO-84 URL: https://issues.apache.org/jira/browse/CRYPTO-84 Project: Commons Crypto Issue Type: Bug Reporter: Sebb getJCEProvider is only needed by the JceCipher class. It's confusing to have it in a shared class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-200) Support for dynamic scripting in jexl scripts
Dmitri Blinov created JEXL-200:
--
Summary: Support for dynamic scripting in jexl scripts
Key: JEXL-200
URL: https://issues.apache.org/jira/browse/JEXL-200
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dmitri Blinov
Priority: Minor
Allow for dynamically defined functions inside a script where the definition of
the function comes from a string expression, for example:
{code}
def x(y) = "return y+2";
{code}
the defined function should be accessable after its definition is successfully
parsed as ordinary function, and can be evaluated in the current context.
{code}
if (x(40) eq 42) {...
{code}
I think the idea of dynamic script evaluation is not unusual, and though to
some extent can be implemented via side-added functions like *eval(expr)* a
dedicated syntax for this will benefit from the simplicity of ordinal functions
and the ability to control mapping of the arguments between a caller and the
defined function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLI-255) DefaultParser, option with long name and single dash, unlimited arguments
[
https://issues.apache.org/jira/browse/CLI-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335882#comment-15335882
]
Jason Newell commented on CLI-255:
--
I've a similar issue but basically DefaultParser doesn't work with a single
dash where the option name exceeds one character in length so -a is fine but
-ab doesn't work. I've been exercising this with a JUnit test.
@Test public void CliTest() throws ArgumentException
{
s_clsLogger.info("MainWithWrongNumArgsTest()");
try
{
String strCmk = "xr";
Options s_clsOptions = new Options();
Option clsOptionTstp = Option.builder(strCmk)
.valueSeparator('=')
.type(String.class)
.required()
.hasArg()
.argName("TestCommandPath=value")
.desc("A test path")
.build();
s_clsOptions.addOption(clsOptionTstp);
String[] astrCli = new String[]{String.format("-%s=cd",
strCmk)};
CommandLineParser s_clsClParser = new DefaultParser();
CommandLine clsCommandLine = s_clsClParser.parse(s_clsOptions,
astrCli, true);
if(clsCommandLine.hasOption(strCmk))
{
String strOptionValue =
clsCommandLine.getOptionValue(strCmk);
assertEquals(strOptionValue,"cd");
}
else
{
fail();
}
}
catch (Exception e)
{
s_clsLogger.error(e);
fail(e.toString());
}
finally
{
}
}
> DefaultParser, option with long name and single dash, unlimited arguments
> -
>
> Key: CLI-255
> URL: https://issues.apache.org/jira/browse/CLI-255
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.3, 1.3.1
>Reporter: Alexander Prishchepov
>Priority: Minor
>
> If I have options with long name and single dash, DefaultParser does not
> recognize them after a list of unlimited arguments.
> Here is the test case:
> {code:java}
> public void testUnlimitedArgs() throws Exception
> {
> String[] args = new String[] {"-unlimitedOne", "one", "two",
> "-unlimitedTwo", "alpha"};
> Options options = new Options();
> options.addOption(Option.builder("unlimitedOne").hasArgs().build());
> options.addOption(Option.builder("unlimitedTwo").hasArgs().build());
> CommandLine cl = parser.parse(options, args);
> assertTrue("Confirm -unlimitedOne is set",
> cl.hasOption("unlimitedOne"));
> assertEquals("number of arg for -unlimitedOne", 2,
> cl.getOptionValues("unlimitedOne").length);
> assertTrue("Confirm -unlimitedTwo is set",
> cl.hasOption("unlimitedTwo"));
> assertEquals("number of arg for -unlimitedTwo", 1,
> cl.getOptionValues("unlimitedTwo").length);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CRYPTO-82) CipherTransformation is an enum which limits the possible transformations
[ https://issues.apache.org/jira/browse/CRYPTO-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335874#comment-15335874 ] Sebb commented on CRYPTO-82: If this is only intended for use with the native OpenSSL implementation, then it should be defined in an OpenSSL-specific class. > CipherTransformation is an enum which limits the possible transformations > - > > Key: CRYPTO-82 > URL: https://issues.apache.org/jira/browse/CRYPTO-82 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb > > The class CipherTransformation is an enum with only 3 entries currently. > This seems wrong; surely there are many more possible transformations? > An enum should generally only be used to denote a limited and known set of > choices. Otherwise users are limited to whatever was made available when the > code was released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-80) Fix the PMD error.
[ https://issues.apache.org/jira/browse/CRYPTO-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335614#comment-15335614 ] Dapeng Sun commented on CRYPTO-80: -- Committed to master, thank Ke. Repository: commons-crypto Updated Branches: refs/heads/master 11ba975cd -> 18ac95b5e CRYPTO-80: Fix the pmd error Project: http://git-wip-us.apache.org/repos/asf/commons-crypto/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-crypto/commit/18ac95b5 Tree: http://git-wip-us.apache.org/repos/asf/commons-crypto/tree/18ac95b5 Diff: http://git-wip-us.apache.org/repos/asf/commons-crypto/diff/18ac95b5 > Fix the PMD error. > -- > > Key: CRYPTO-80 > URL: https://issues.apache.org/jira/browse/CRYPTO-80 > Project: Commons Crypto > Issue Type: Bug >Reporter: Ke Jia >Assignee: Ke Jia > > Fixe the pmd error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JXPATH-189) UnionContext cannot be a paramter of XPath extension function
Magle created JXPATH-189:
Summary: UnionContext cannot be a paramter of XPath extension
function
Key: JXPATH-189
URL: https://issues.apache.org/jira/browse/JXPATH-189
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Reporter: Magle
Priority: Minor
When getNodeSet() of a UnionContext object is invoked, it's possible that the
"nodeSet" doesn't be prepared from "contexts", a empty nodeSet will be returned.
for example, an extension function test:count(nodeSet) to get the total count
of the nodeSet. it doesn't work for UnionContext, test:count('abc'|'ed'), the
result will be 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
