[jira] [Updated] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard updated MATH-581: --- Attachment: MATH-581-04.zip > Support for iterative linear solvers > > > Key: MATH-581 > URL: https://issues.apache.org/jira/browse/MATH-581 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0, Nightly Builds >Reporter: Sébastien Brisard > Labels: iterative, linear, solver > Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, > MATH-581-04.zip, linearoperator.zip > > > Dear all, > this issue has already been discussed on the forum. The idea is to implement > the most popular linear iterative solvers (CG, SYMMLQ, etc...) in > commons-math. The beauty of these solvers is that they do not need direct > access to the coefficients of the matrix, only matrix-vector products are > necessary. This is goof, as sometimes it is inetficient to store the > coefficients of the matrix. > So basically, before implementing the iterative solvers, we need to define an > interface slightly more general than a matrix, namely LinearOperator, with > only one basic operation: matrix-vector product. > Here are a few interfaces and abstract classes that do that. Nothing fancy > yet, I just wanted to have you advice on the implementation before I commit > some solvers. > I thought these classes could go in a package > org.apache.commons.math.linearoperator, but really, I haven't got a clue... > Best regards, > Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063695#comment-13063695
]
Sébastien Brisard commented on MATH-581:
I've had afterthoughts. I think ultimately, we will have {{AbstractRealMatrix}}
inherit from {{RealLinearOperator}}, right?
Initially, I wanted to mark the difference between a _linear operator_ and a
_matrix_, so I named {{getDomainDimension}} and {{getCodomainDimension}} the
methods returning respectively the number of columns and the number of rows of
the underlying matrix. I think if we want {{AbstractRealMatrix}} and
{{RealLinearOperator}} to blend nicely, I should rename these methods according
to the naming convention of the existing {{AbstractRealMatrix}}. Otherwise, the
constructors would have different signatures!
{noformat}RealLinearOperator(dimDomain, dimCodomain){noformat}
(It would be unlogical to have the codomain appear before the domain). Since
{{dimDomain == columnDimension}} and {{dimCodomain == rowDimension}}, this
would translate into
{noformat}RealLinearOperator(columnDimension, rowDimension){noformat}
as opposed to
{noformat}AbstractRealMatrix(rowDimension, columnDimension){noformat}
which is a very dangerous inconsistency. MATH-581-04.zip corrects this.
> Support for iterative linear solvers
>
>
> Key: MATH-581
> URL: https://issues.apache.org/jira/browse/MATH-581
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0, Nightly Builds
>Reporter: Sébastien Brisard
> Labels: iterative, linear, solver
> Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
> linearoperator.zip
>
>
> Dear all,
> this issue has already been discussed on the forum. The idea is to implement
> the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
> commons-math. The beauty of these solvers is that they do not need direct
> access to the coefficients of the matrix, only matrix-vector products are
> necessary. This is goof, as sometimes it is inetficient to store the
> coefficients of the matrix.
> So basically, before implementing the iterative solvers, we need to define an
> interface slightly more general than a matrix, namely LinearOperator, with
> only one basic operation: matrix-vector product.
> Here are a few interfaces and abstract classes that do that. Nothing fancy
> yet, I just wanted to have you advice on the implementation before I commit
> some solvers.
> I thought these classes could go in a package
> org.apache.commons.math.linearoperator, but really, I haven't got a clue...
> Best regards,
> Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-613) Equivalent of Blas DAXPY
[
https://issues.apache.org/jira/browse/MATH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063456#comment-13063456
]
Sébastien Brisard edited comment on MATH-613 at 7/12/11 3:25 AM:
-
I have no experience whatsoever with Colt, but taking the element by element
max of two vectors might be an example of use of the more general case (maybe).
As for me, I'm happy with the linear case. And I like combine/combineToSelf.
was (Author: celestin):
I have no experience whatsoever with Colt, but I taking the element by
element max of two vectors might be an example of use (maybe). As for me, I'm
happy with the linear case. And I like combine/combineToSelf.
> Equivalent of Blas DAXPY
>
>
> Key: MATH-613
> URL: https://issues.apache.org/jira/browse/MATH-613
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, vector
>
> In Blas, the method {{DAXPY}} computes an in-place linear combination of two
> vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}}
> with the value of {{a * x + y}}. This can lead to very compact code, which I
> feel the need for in Commons-Math. However, DAXPY also has its limitations.
> For example, it cannot perform the other combination {{y <- x + a * y}}.
> I think it would be useful that {{RealVector}} had a method for computing {{a
> * this + b * y}}, and storing the result in {{this}}. In the spirit of the
> {{mapToSelf}} method, I propose to create two new methods in {{Interface
> RealVector}}
> {noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
> and
> {noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector
> y){noformat}
> The former would return a new vector {{v}} such that
> {noformat}v[i] <- f(this[i], y[i])}}{noformat}
> and the latter would update {{this}},
> {noformat}this[i] <- f(this[i], y[i]){noformat}
> Emulating {{DAXPY}} would then simply be a matter of implementing the
> appropriate bivariate function.
> While we are at it, how about
> {noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
> z){noformat}
> {noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
> RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-607) Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets.
[ https://issues.apache.org/jira/browse/MATH-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] greg sterijevski updated MATH-607: -- Attachment: regres_change1 Mea culpa, I made a mistake in retrieving the standard errors. Two lines are defective. > Current Multiple Regression Object does calculations with all data incore. > There are non incore techniques which would be useful with large datasets. > - > > Key: MATH-607 > URL: https://issues.apache.org/jira/browse/MATH-607 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 > Environment: Java >Reporter: greg sterijevski > Labels: Gentleman's, QR, Regression, Updating, decomposition, > lemma > Fix For: 3.0 > > Attachments: regres_change1, updating_reg_cut2, updating_reg_ifaces > > Original Estimate: 840h > Remaining Estimate: 840h > > The current multiple regression class does a QR decomposition on the complete > data set. This necessitates the loading incore of the complete dataset. For > large datasets, or large datasets and a requirement to do datamining or > stepwise regression this is not practical. There are techniques which form > the normal equations on the fly, as well as ones which form the QR > decomposition on an update basis. I am proposing, first, the specification of > an "UpdatingLinearRegression" interface which defines basic functionality all > such techniques must fulfill. > Related to this 'updating' regression, the results of running a regression on > some subset of the data should be encapsulated in an immutable object. This > is to ensure that subsequent additions of observations do not corrupt or > render inconsistent parameter estimates. I am calling this interface > "RegressionResults". > Once the community has reached a consensus on the interface, work on the > concrete implementation of these techniques will take place. > Thanks, > -Greg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-611) A fast and stable SVD implementation from JAMA
[ https://issues.apache.org/jira/browse/MATH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Nix updated MATH-611: - Attachment: SingularValueDecompositionImpl.patch I have attached a patch file for the JAMA implementation, together with unit tests for MATH-327, MATH-465 and MATH-583. Additionally, I have removed the unit test testMatricesValues1 that tested an implementation specific return value of getU() and getV(). > A fast and stable SVD implementation from JAMA > -- > > Key: MATH-611 > URL: https://issues.apache.org/jira/browse/MATH-611 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0, Nightly Builds >Reporter: Christopher Nix > Labels: patch > Fix For: 3.0, Nightly Builds > > Attachments: SingularValueDecompositionImpl.java, > SingularValueDecompositionImpl.patch > > > Common numerical stability issues with the current SVD implementation, ie > MATH-327, MATH-383, MATH-465, MATH-583 can all be solved by co-opting JAMA > code that is within the public domain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-113) Need a function to extract which variables are used to evaluate a script (was: Dot notation behaves unexpectedly with null values)
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063545#comment-13063545 ] Henri Biestro commented on JEXL-113: Hi Max, I've added JexlEngine.getVariables() to the trunk (revision 1145359). Let me know if this is what you expected. Cheers Henrib > Need a function to extract which variables are used to evaluate a script > (was: Dot notation behaves unexpectedly with null values) > -- > > Key: JEXL-113 > URL: https://issues.apache.org/jira/browse/JEXL-113 > Project: Commons JEXL > Issue Type: Sub-task >Affects Versions: 2.0.1 > Environment: JDK 1.6 >Reporter: Max Tardiveau >Assignee: Henri Biestro > > When a variable of the form a.b is evaluated, the context is asked first for > the value of a. That value is then asked for the value of b. > So far, so good: this is exactly what you'd expect from the dot operator. > But if the value of b is null, the context is then asked for the value of > a.b, in other words the dot operator is ignored and "a.b" is considered to be > a single variable. > This is at best confusing. Granted, this can be avoided with the a['b'] > notation, but that's clumsy. > I assume this is an attempt to support both the dot operator and ant-style > variables. I don't think you can have both and remain sane. > Suggestion: either document this behavior, or make it an option. My vote > would be to just use the value returned, even if it's null. Either dot is an > operator, or it's not. Perhaps make that configurable? > Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-114) Allow scripts to create local variables // Add return keyword
[
https://issues.apache.org/jira/browse/JEXL-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063546#comment-13063546
]
Henri Biestro commented on JEXL-114:
Initial drop in trunk revision 1145359.
> Allow scripts to create local variables // Add return keyword
> -
>
> Key: JEXL-114
> URL: https://issues.apache.org/jira/browse/JEXL-114
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 2.0.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 2.0.2
>
>
> WHY:
> Not having local variables nor return in scripts is inconvenient, especially
> when dealing with loops.
> This also precludes using read-only contexts easily which are really
> convenient when letting end-users enter their own expressions.
> HOW:
> This could (will) be implemented by extending the parameters feature (script
> accept parameters during parsing and thus arguments during evaluation) which
> is itself based on the notion of 'registers' - an array of objects that the
> interpreter allocates and uses based on script information.
> It only requires adding one keyword ("var" seems the obvious choice) in the
> .jjt.
> The "return" keyword is also an easy .jjt addition; obvious implementation is
> to use an internal exception to force traversing the stack up.
> WHAT:
> Add the "var" and "return" keyword.
> Also add methods to extract the variables (global - see JEXL-113), the
> parameters (used during parsing) and the local variables (declared within) a
> script to help pinpoint problems or prepare the evaluation of scripts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-114) Allow scripts to create local variables // Add return keyword
[
https://issues.apache.org/jira/browse/JEXL-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-114:
---
Description:
WHY:
Not having local variables nor return in scripts is inconvenient, especially
when dealing with loops.
This also precludes using read-only contexts easily which are really convenient
when letting end-users enter their own expressions.
HOW:
This could (will) be implemented by extending the parameters feature (script
accept parameters during parsing and thus arguments during evaluation) which is
itself based on the notion of 'registers' - an array of objects that the
interpreter allocates and uses based on script information.
It only requires adding one keyword ("var" seems the obvious choice) in the
.jjt.
The "return" keyword is also an easy .jjt addition; obvious implementation is
to use an internal exception to force traversing the stack up.
WHAT:
Add the "var" and "return" keyword.
Also add methods to extract the variables (global - see JEXL-113), the
parameters (used during parsing) and the local variables (declared within) a
script to help pinpoint problems or prepare the evaluation of scripts.
was:
Not having local variables in scripts is inconvenient, especially when dealing
with loops.
This also precludes using read-only contexts easily which are really convenient
when letting end-users enter their own expressions.
This could (will) be implemented by extending the parameters feature (script
accept parameters during parsing and thus arguments during evaluation) which is
itself based on the notion of 'registers' - an array of objects that the
interpreter allocates and uses based on script information.
Summary: Allow scripts to create local variables // Add return keyword
(was: Allow scripts to create local variables)
> Allow scripts to create local variables // Add return keyword
> -
>
> Key: JEXL-114
> URL: https://issues.apache.org/jira/browse/JEXL-114
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 2.0.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 2.0.2
>
>
> WHY:
> Not having local variables nor return in scripts is inconvenient, especially
> when dealing with loops.
> This also precludes using read-only contexts easily which are really
> convenient when letting end-users enter their own expressions.
> HOW:
> This could (will) be implemented by extending the parameters feature (script
> accept parameters during parsing and thus arguments during evaluation) which
> is itself based on the notion of 'registers' - an array of objects that the
> interpreter allocates and uses based on script information.
> It only requires adding one keyword ("var" seems the obvious choice) in the
> .jjt.
> The "return" keyword is also an easy .jjt addition; obvious implementation is
> to use an internal exception to force traversing the stack up.
> WHAT:
> Add the "var" and "return" keyword.
> Also add methods to extract the variables (global - see JEXL-113), the
> parameters (used during parsing) and the local variables (declared within) a
> script to help pinpoint problems or prepare the evaluation of scripts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-113) Need a function to extract which variables are used to evaluate a script (was: Dot notation behaves unexpectedly with null values)
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-113: --- Issue Type: Sub-task (was: New Feature) Parent: JEXL-114 > Need a function to extract which variables are used to evaluate a script > (was: Dot notation behaves unexpectedly with null values) > -- > > Key: JEXL-113 > URL: https://issues.apache.org/jira/browse/JEXL-113 > Project: Commons JEXL > Issue Type: Sub-task >Affects Versions: 2.0.1 > Environment: JDK 1.6 >Reporter: Max Tardiveau >Assignee: Henri Biestro > > When a variable of the form a.b is evaluated, the context is asked first for > the value of a. That value is then asked for the value of b. > So far, so good: this is exactly what you'd expect from the dot operator. > But if the value of b is null, the context is then asked for the value of > a.b, in other words the dot operator is ignored and "a.b" is considered to be > a single variable. > This is at best confusing. Granted, this can be avoided with the a['b'] > notation, but that's clumsy. > I assume this is an attempt to support both the dot operator and ant-style > variables. I don't think you can have both and remain sane. > Suggestion: either document this behavior, or make it an option. My vote > would be to just use the value returned, even if it's null. Either dot is an > operator, or it's not. Perhaps make that configurable? > Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JEXL-114) Allow scripts to create local variables
Allow scripts to create local variables --- Key: JEXL-114 URL: https://issues.apache.org/jira/browse/JEXL-114 Project: Commons JEXL Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 2.0.2 Not having local variables in scripts is inconvenient, especially when dealing with loops. This also precludes using read-only contexts easily which are really convenient when letting end-users enter their own expressions. This could (will) be implemented by extending the parameters feature (script accept parameters during parsing and thus arguments during evaluation) which is itself based on the notion of 'registers' - an array of objects that the interpreter allocates and uses based on script information. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-113) Need a function to extract which variables are used to evaluate a script (was: Dot notation behaves unexpectedly with null values)
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-113: --- Issue Type: New Feature (was: Bug) Summary: Need a function to extract which variables are used to evaluate a script (was: Dot notation behaves unexpectedly with null values) (was: Dot notation behaves unexpectedly with null values) > Need a function to extract which variables are used to evaluate a script > (was: Dot notation behaves unexpectedly with null values) > -- > > Key: JEXL-113 > URL: https://issues.apache.org/jira/browse/JEXL-113 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 2.0.1 > Environment: JDK 1.6 >Reporter: Max Tardiveau >Assignee: Henri Biestro > > When a variable of the form a.b is evaluated, the context is asked first for > the value of a. That value is then asked for the value of b. > So far, so good: this is exactly what you'd expect from the dot operator. > But if the value of b is null, the context is then asked for the value of > a.b, in other words the dot operator is ignored and "a.b" is considered to be > a single variable. > This is at best confusing. Granted, this can be avoided with the a['b'] > notation, but that's clumsy. > I assume this is an attempt to support both the dot operator and ant-style > variables. I don't think you can have both and remain sane. > Suggestion: either document this behavior, or make it an option. My vote > would be to just use the value returned, even if it's null. Either dot is an > operator, or it's not. Perhaps make that configurable? > Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063529#comment-13063529 ] Gary D. Gregory commented on JEXL-113: -- Hi Max, can you ping me at ggreg...@apache.org? I think we've worked together before... > Dot notation behaves unexpectedly with null values > -- > > Key: JEXL-113 > URL: https://issues.apache.org/jira/browse/JEXL-113 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.0.1 > Environment: JDK 1.6 >Reporter: Max Tardiveau >Assignee: Henri Biestro > > When a variable of the form a.b is evaluated, the context is asked first for > the value of a. That value is then asked for the value of b. > So far, so good: this is exactly what you'd expect from the dot operator. > But if the value of b is null, the context is then asked for the value of > a.b, in other words the dot operator is ignored and "a.b" is considered to be > a single variable. > This is at best confusing. Granted, this can be avoided with the a['b'] > notation, but that's clumsy. > I assume this is an attempt to support both the dot operator and ant-style > variables. I don't think you can have both and remain sane. > Suggestion: either document this behavior, or make it an option. My vote > would be to just use the value returned, even if it's null. Either dot is an > operator, or it's not. Perhaps make that configurable? > Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063518#comment-13063518 ] Max Tardiveau commented on JEXL-113: Got it. That makes sense. Thanks, -- Max > Dot notation behaves unexpectedly with null values > -- > > Key: JEXL-113 > URL: https://issues.apache.org/jira/browse/JEXL-113 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.0.1 > Environment: JDK 1.6 >Reporter: Max Tardiveau > > When a variable of the form a.b is evaluated, the context is asked first for > the value of a. That value is then asked for the value of b. > So far, so good: this is exactly what you'd expect from the dot operator. > But if the value of b is null, the context is then asked for the value of > a.b, in other words the dot operator is ignored and "a.b" is considered to be > a single variable. > This is at best confusing. Granted, this can be avoided with the a['b'] > notation, but that's clumsy. > I assume this is an attempt to support both the dot operator and ant-style > variables. I don't think you can have both and remain sane. > Suggestion: either document this behavior, or make it an option. My vote > would be to just use the value returned, even if it's null. Either dot is an > operator, or it's not. Perhaps make that configurable? > Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-613) Equivalent of Blas DAXPY
[
https://issues.apache.org/jira/browse/MATH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063456#comment-13063456
]
Sébastien Brisard commented on MATH-613:
I have no experience whatsoever with Colt, but I taking the element by element
max of two vectors might be an example of use (maybe). As for me, I'm happy
with the linear case. And I like combine/combineToSelf.
> Equivalent of Blas DAXPY
>
>
> Key: MATH-613
> URL: https://issues.apache.org/jira/browse/MATH-613
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, vector
>
> In Blas, the method {{DAXPY}} computes an in-place linear combination of two
> vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}}
> with the value of {{a * x + y}}. This can lead to very compact code, which I
> feel the need for in Commons-Math. However, DAXPY also has its limitations.
> For example, it cannot perform the other combination {{y <- x + a * y}}.
> I think it would be useful that {{RealVector}} had a method for computing {{a
> * this + b * y}}, and storing the result in {{this}}. In the spirit of the
> {{mapToSelf}} method, I propose to create two new methods in {{Interface
> RealVector}}
> {noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
> and
> {noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector
> y){noformat}
> The former would return a new vector {{v}} such that
> {noformat}v[i] <- f(this[i], y[i])}}{noformat}
> and the latter would update {{this}},
> {noformat}this[i] <- f(this[i], y[i]){noformat}
> Emulating {{DAXPY}} would then simply be a matter of implementing the
> appropriate bivariate function.
> While we are at it, how about
> {noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
> z){noformat}
> {noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
> RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-613) Equivalent of Blas DAXPY
[
https://issues.apache.org/jira/browse/MATH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063406#comment-13063406
]
Phil Steitz commented on MATH-613:
--
Sorry, I missed the earlier comment on the name. Regarding whether or not to
implement the general version, I would like to know if others have actual use
cases in mind. Ted mentioned in the earlier thread that Colt had a similar
API. I am curious how it was actually used, beyond the canonical linear
combination example that led to this suggestion. Can anyone think of practical
use cases for the general versions?
Regarding the name, I did mean "combine." I don't personally see a problem
using "combine" here as well as FunctionUtils in the analysis package, as the
objects are different. But if we need to add something, I would add "with" -
i.e. "combineWith" and "combineWithSelf."
Don't allow me to prematurely nix the general case, though. I just want some
indication that the slightly more complex (hence less approachable) API has
enough usefulness to justify it.
> Equivalent of Blas DAXPY
>
>
> Key: MATH-613
> URL: https://issues.apache.org/jira/browse/MATH-613
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, vector
>
> In Blas, the method {{DAXPY}} computes an in-place linear combination of two
> vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}}
> with the value of {{a * x + y}}. This can lead to very compact code, which I
> feel the need for in Commons-Math. However, DAXPY also has its limitations.
> For example, it cannot perform the other combination {{y <- x + a * y}}.
> I think it would be useful that {{RealVector}} had a method for computing {{a
> * this + b * y}}, and storing the result in {{this}}. In the spirit of the
> {{mapToSelf}} method, I propose to create two new methods in {{Interface
> RealVector}}
> {noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
> and
> {noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector
> y){noformat}
> The former would return a new vector {{v}} such that
> {noformat}v[i] <- f(this[i], y[i])}}{noformat}
> and the latter would update {{this}},
> {noformat}this[i] <- f(this[i], y[i]){noformat}
> Emulating {{DAXPY}} would then simply be a matter of implementing the
> appropriate bivariate function.
> While we are at it, how about
> {noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
> z){noformat}
> {noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
> RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-613) Equivalent of Blas DAXPY
[
https://issues.apache.org/jira/browse/MATH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063391#comment-13063391
]
Sébastien Brisard commented on MATH-613:
Granted, trivariate versions are far-fetched, and not really needed (if the
worst comes to the worst, two calls to the bivariate version should be enough,
at least in the linear case).
As for going less general, restricting to a linear combination. I'm all for it,
I just got the feeling that the discussion on the forum was leaning towards a
more general, function-based approach (which is quite elegant).
If we restrict ourselves to linear combination, I'm not sure I understant your
naming suggestion. I guess you speak sed fluently, and are in fact suggesting
{noformat}RealVector combine(double a, double b, RealVector y){noformat}
{noformat}RealVector combineToSelf(double a, double b, RealVector y){noformat}
That was my original suggestion, but someone mentioned that in
{{FunctionUtils}}, "combine" really meant "compose multivariate with several
univariate", so the above naming might be confusing. Actually, that's the
reason why I went for general mapping: for lack of a better name in the linear
case...
What do you think of {{linearlyCombine}} and {{linearlyCombineToSelf}}? I would
personnaly prefer the first (shorter option).
> Equivalent of Blas DAXPY
>
>
> Key: MATH-613
> URL: https://issues.apache.org/jira/browse/MATH-613
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, vector
>
> In Blas, the method {{DAXPY}} computes an in-place linear combination of two
> vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}}
> with the value of {{a * x + y}}. This can lead to very compact code, which I
> feel the need for in Commons-Math. However, DAXPY also has its limitations.
> For example, it cannot perform the other combination {{y <- x + a * y}}.
> I think it would be useful that {{RealVector}} had a method for computing {{a
> * this + b * y}}, and storing the result in {{this}}. In the spirit of the
> {{mapToSelf}} method, I propose to create two new methods in {{Interface
> RealVector}}
> {noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
> and
> {noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector
> y){noformat}
> The former would return a new vector {{v}} such that
> {noformat}v[i] <- f(this[i], y[i])}}{noformat}
> and the latter would update {{this}},
> {noformat}this[i] <- f(this[i], y[i]){noformat}
> Emulating {{DAXPY}} would then simply be a matter of implementing the
> appropriate bivariate function.
> While we are at it, how about
> {noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
> z){noformat}
> {noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
> RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-613) Equivalent of Blas DAXPY
[
https://issues.apache.org/jira/browse/MATH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063376#comment-13063376
]
Phil Steitz commented on MATH-613:
--
I see the value of this based on the linear combination example, so am +0 to
add the first two. It might be better, though to s/map/combine in the names.
It might also be good to explicitly name the linear combination example. Are
there other examples likely to be commonly used that anyone can think of? If
not, we should consider adding only the linear combination, since if that is
all anyone will use, it will simplify the API to just name and add it.
Regarding the trivariate versions, what exactly are the use cases?
> Equivalent of Blas DAXPY
>
>
> Key: MATH-613
> URL: https://issues.apache.org/jira/browse/MATH-613
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, vector
>
> In Blas, the method {{DAXPY}} computes an in-place linear combination of two
> vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}}
> with the value of {{a * x + y}}. This can lead to very compact code, which I
> feel the need for in Commons-Math. However, DAXPY also has its limitations.
> For example, it cannot perform the other combination {{y <- x + a * y}}.
> I think it would be useful that {{RealVector}} had a method for computing {{a
> * this + b * y}}, and storing the result in {{this}}. In the spirit of the
> {{mapToSelf}} method, I propose to create two new methods in {{Interface
> RealVector}}
> {noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
> and
> {noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector
> y){noformat}
> The former would return a new vector {{v}} such that
> {noformat}v[i] <- f(this[i], y[i])}}{noformat}
> and the latter would update {{this}},
> {noformat}this[i] <- f(this[i], y[i]){noformat}
> Emulating {{DAXPY}} would then simply be a matter of implementing the
> appropriate bivariate function.
> While we are at it, how about
> {noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
> z){noformat}
> {noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
> RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[ https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063308#comment-13063308 ] Gilles commented on MATH-605: - No problem. I've taken care of your suggestion for the "solvers" part (revision 1145146). But in the log I've attributed to the MATH-599 issue... > Missing state events due to events between t0 and t0+e being ignored > > > Key: MATH-605 > URL: https://issues.apache.org/jira/browse/MATH-605 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Dennis Hendriks > Attachments: OverlappingEventsTest.java, > overlapping-events-tests-v3.patch, overlapping-events-tests.patch, > overlapping-events-tests.patch > > > The Commons Math page on ODEs > (http://commons.apache.org/math/userguide/ode.html) states in section 13.3 > (Discrete Events Handling), that: "Note that g function signs changes at the > very beginning of the integration (from t0 to t0 + ε where ε is the events > detection convergence threshold) are explicitely ignored. This prevents > having the integration stuck at its initial point when a new integration is > restarted just at the same point a previous one had been stopped by an event." > However, due the following issues: > - MATH-586: Allow using a custom root-finding algorithm to detect state > events > - MATH-599: Re-implementation of Secant-based root finding algorithms > we can now use for instance the PegasusSolver to detect state events. Using > the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the > event. As such, skipping (future) events between t0 and t0+e is not desired. > I attached a Java class to show this issue. It has 2 continuous variables, > each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever > they become larger than 1.0, they are reset. We thus expect resets for event > 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc. > The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the > events however are not detected at the exact same times. After we processed > the first, the 'skip everything between t0 and t0+e' may result in skipping > events, as can be observed from the failing unit test. The second test has a > hack to get around this problem: it is manually checked whether the guard > changes, by evaluating t0 and t0+e. If an event is detected, a step of e is > done, and integration is restarted from t0+e. This solves the issue, and the > unit tests succeeds (we get the events at the expected times, and we don't > miss any events). > From what I understand, event detection is complicated, as discussed in > MATH-484. I propose to make the skipping of events betweeen t0 and t0+e > optional, as that is no longer needed in the cases I described above, and in > fact causes severe problems that can only be solved by hacks. For other > (non-bracketed solution) algorithms, it may still be necessary to skip such > roots. Maybe an option could be introduced to control this behavior? > So, if an event is detected at time t, integration may continue from t0=t, > and if there is a sign change for t0 and t0+e, then the step handler should > be called for t0+e, and the step handler should be called for t0+e as well, > with isLast=true. I'm not sure what the value of e should be. It could be the > absolute accuracy of the root-finding algorithm. if there are multiple ones, > maybe the maximum of all of them. Maybe even the minimal integration step > should be taken into account, taking the maximum of that an dall the absolute > accuracies of the root-finding algorithms? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (JEXL-113) Dot notation behaves unexpectedly with null values
[
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063263#comment-13063263
]
Henri Biestro edited comment on JEXL-113 at 7/11/11 12:28 PM:
--
The reason for the Set> would be to track both 'dot' operators and
'bracketed' expressions since they dont differ in evaluation. Every 'dot' expr
can be rewritten as a 'bracketed' expr (not the opposite because of
restrictions in allowed characters for identifiers).
Anyway, reusing your example:
a + b.c + d["e"]["f"] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} }
However, a + b[func()] would only return { {"a"}, {"b"} }
Cheers,
Henri
was (Author: henrib):
The reason for the Set> would be to track both 'dot' operators
and 'bracketed' expressions since they dont differ in evaluation. Every 'dot'
expr can be rewritten as a 'bracketed' expr (not the opposite because of
restrictions in allowed characters for identifiers).
Anyway, reusing your example:
a + b.c + d['e']['f'] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} }
However, a + b[func()] would only return { {"a"}, {"b"} }
Cheers,
Henri
> Dot notation behaves unexpectedly with null values
> --
>
> Key: JEXL-113
> URL: https://issues.apache.org/jira/browse/JEXL-113
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: JDK 1.6
>Reporter: Max Tardiveau
>
> When a variable of the form a.b is evaluated, the context is asked first for
> the value of a. That value is then asked for the value of b.
> So far, so good: this is exactly what you'd expect from the dot operator.
> But if the value of b is null, the context is then asked for the value of
> a.b, in other words the dot operator is ignored and "a.b" is considered to be
> a single variable.
> This is at best confusing. Granted, this can be avoided with the a['b']
> notation, but that's clumsy.
> I assume this is an attempt to support both the dot operator and ant-style
> variables. I don't think you can have both and remain sane.
> Suggestion: either document this behavior, or make it an option. My vote
> would be to just use the value returned, even if it's null. Either dot is an
> operator, or it's not. Perhaps make that configurable?
> Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (JEXL-113) Dot notation behaves unexpectedly with null values
[
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063263#comment-13063263
]
Henri Biestro edited comment on JEXL-113 at 7/11/11 12:27 PM:
--
The reason for the Set> would be to track both 'dot' operators and
'bracketed' expressions since they dont differ in evaluation. Every 'dot' expr
can be rewritten as a 'bracketed' expr (not the opposite because of
restrictions in allowed characters for identifiers).
Anyway, reusing your example:
a + b.c + d['e']['f'] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} }
However, a + b[func()] would only return { {"a"}, {"b"} }
Cheers,
Henri
was (Author: henrib):
The reason for the Set> would be to track both 'dot' operators
and 'bracketed' expressions since they dont differ in evaluation. Every 'dot'
expr can be rewritten as a 'bracketed' expr (not the opposite because of
restrictions in allowed characters for identifiers).
Anyway, reusing your example:
a + b.c + d[e][f] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} }
However, a + b[func()] would only return { {"a"}, {"b"} }
Cheers,
Henri
> Dot notation behaves unexpectedly with null values
> --
>
> Key: JEXL-113
> URL: https://issues.apache.org/jira/browse/JEXL-113
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: JDK 1.6
>Reporter: Max Tardiveau
>
> When a variable of the form a.b is evaluated, the context is asked first for
> the value of a. That value is then asked for the value of b.
> So far, so good: this is exactly what you'd expect from the dot operator.
> But if the value of b is null, the context is then asked for the value of
> a.b, in other words the dot operator is ignored and "a.b" is considered to be
> a single variable.
> This is at best confusing. Granted, this can be avoided with the a['b']
> notation, but that's clumsy.
> I assume this is an attempt to support both the dot operator and ant-style
> variables. I don't think you can have both and remain sane.
> Suggestion: either document this behavior, or make it an option. My vote
> would be to just use the value returned, even if it's null. Either dot is an
> operator, or it's not. Perhaps make that configurable?
> Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-339) [Dot Export] Adding vertex attribute
[
https://issues.apache.org/jira/browse/SANDBOX-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063301#comment-13063301
]
Simone Tripodi commented on SANDBOX-339:
Sorry if I'm late, I'm a little busy with some non-IT stuff, but as we say in
Italian "later is better than never" ;)
I still don't like the approach because - sorry to be redundant on that topic -
it forces the user learning a language created to be understood and interpreted
by machines and not by humans - as a user, I wouldn't use those APIs.
You can anyway use your hints/ideas as a base for a better engine; if you are
able to generate an interpreter, you can write a compiler as well - create the
CSV and let it be processed by an ingester that generates the Graph preferences
directly in Java classes form - and you can generate beans not only for
vertices, but for the whole set of graph elements.
If/when the DOT language changes, we will deprecate/add fields.
Good work!
> [Dot Export] Adding vertex attribute
>
>
> Key: SANDBOX-339
> URL: https://issues.apache.org/jira/browse/SANDBOX-339
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Marco Speranza
>Priority: Minor
> Attachments: DotExport-AddingVertexAttribute.patch
>
>
> Hi folk, I just made a little improvement to Dot Export. I added the
> possibility to customize the attributes of the vertices through a
> {{Map}}
> Looking forward your comments.
> bye
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[
https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063295#comment-13063295
]
Dennis Hendriks commented on MATH-605:
--
bq. It would be easier if you could provide separate patches for distinct
issues ("solvers" vs "ode").
Unfortunately, I don't have time for that today, and today is my last day at
work before my summer holiday. I'll keep this in mind for the future.
> Missing state events due to events between t0 and t0+e being ignored
>
>
> Key: MATH-605
> URL: https://issues.apache.org/jira/browse/MATH-605
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dennis Hendriks
> Attachments: OverlappingEventsTest.java,
> overlapping-events-tests-v3.patch, overlapping-events-tests.patch,
> overlapping-events-tests.patch
>
>
> The Commons Math page on ODEs
> (http://commons.apache.org/math/userguide/ode.html) states in section 13.3
> (Discrete Events Handling), that: "Note that g function signs changes at the
> very beginning of the integration (from t0 to t0 + ε where ε is the events
> detection convergence threshold) are explicitely ignored. This prevents
> having the integration stuck at its initial point when a new integration is
> restarted just at the same point a previous one had been stopped by an event."
> However, due the following issues:
> - MATH-586: Allow using a custom root-finding algorithm to detect state
> events
> - MATH-599: Re-implementation of Secant-based root finding algorithms
> we can now use for instance the PegasusSolver to detect state events. Using
> the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the
> event. As such, skipping (future) events between t0 and t0+e is not desired.
> I attached a Java class to show this issue. It has 2 continuous variables,
> each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever
> they become larger than 1.0, they are reset. We thus expect resets for event
> 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc.
> The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the
> events however are not detected at the exact same times. After we processed
> the first, the 'skip everything between t0 and t0+e' may result in skipping
> events, as can be observed from the failing unit test. The second test has a
> hack to get around this problem: it is manually checked whether the guard
> changes, by evaluating t0 and t0+e. If an event is detected, a step of e is
> done, and integration is restarted from t0+e. This solves the issue, and the
> unit tests succeeds (we get the events at the expected times, and we don't
> miss any events).
> From what I understand, event detection is complicated, as discussed in
> MATH-484. I propose to make the skipping of events betweeen t0 and t0+e
> optional, as that is no longer needed in the cases I described above, and in
> fact causes severe problems that can only be solved by hacks. For other
> (non-bracketed solution) algorithms, it may still be necessary to skip such
> roots. Maybe an option could be introduced to control this behavior?
> So, if an event is detected at time t, integration may continue from t0=t,
> and if there is a sign change for t0 and t0+e, then the step handler should
> be called for t0+e, and the step handler should be called for t0+e as well,
> with isLast=true. I'm not sure what the value of e should be. It could be the
> absolute accuracy of the root-finding algorithm. if there are multiple ones,
> maybe the maximum of all of them. Maybe even the minimal integration step
> should be taken into account, taking the maximum of that an dall the absolute
> accuracies of the root-finding algorithms?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[
https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063292#comment-13063292
]
Gilles commented on MATH-605:
-
It would be easier if you could provide separate patches for distinct issues
("solvers" vs "ode").
> Missing state events due to events between t0 and t0+e being ignored
>
>
> Key: MATH-605
> URL: https://issues.apache.org/jira/browse/MATH-605
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dennis Hendriks
> Attachments: OverlappingEventsTest.java,
> overlapping-events-tests-v3.patch, overlapping-events-tests.patch,
> overlapping-events-tests.patch
>
>
> The Commons Math page on ODEs
> (http://commons.apache.org/math/userguide/ode.html) states in section 13.3
> (Discrete Events Handling), that: "Note that g function signs changes at the
> very beginning of the integration (from t0 to t0 + ε where ε is the events
> detection convergence threshold) are explicitely ignored. This prevents
> having the integration stuck at its initial point when a new integration is
> restarted just at the same point a previous one had been stopped by an event."
> However, due the following issues:
> - MATH-586: Allow using a custom root-finding algorithm to detect state
> events
> - MATH-599: Re-implementation of Secant-based root finding algorithms
> we can now use for instance the PegasusSolver to detect state events. Using
> the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the
> event. As such, skipping (future) events between t0 and t0+e is not desired.
> I attached a Java class to show this issue. It has 2 continuous variables,
> each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever
> they become larger than 1.0, they are reset. We thus expect resets for event
> 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc.
> The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the
> events however are not detected at the exact same times. After we processed
> the first, the 'skip everything between t0 and t0+e' may result in skipping
> events, as can be observed from the failing unit test. The second test has a
> hack to get around this problem: it is manually checked whether the guard
> changes, by evaluating t0 and t0+e. If an event is detected, a step of e is
> done, and integration is restarted from t0+e. This solves the issue, and the
> unit tests succeeds (we get the events at the expected times, and we don't
> miss any events).
> From what I understand, event detection is complicated, as discussed in
> MATH-484. I propose to make the skipping of events betweeen t0 and t0+e
> optional, as that is no longer needed in the cases I described above, and in
> fact causes severe problems that can only be solved by hacks. For other
> (non-bracketed solution) algorithms, it may still be necessary to skip such
> roots. Maybe an option could be introduced to control this behavior?
> So, if an event is detected at time t, integration may continue from t0=t,
> and if there is a sign change for t0 and t0+e, then the step handler should
> be called for t0+e, and the step handler should be called for t0+e as well,
> with isLast=true. I'm not sure what the value of e should be. It could be the
> absolute accuracy of the root-finding algorithm. if there are multiple ones,
> maybe the maximum of all of them. Maybe even the minimal integration step
> should be taken into account, taking the maximum of that an dall the absolute
> accuracies of the root-finding algorithms?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-613) Equivalent of Blas DAXPY
Equivalent of Blas DAXPY
Key: MATH-613
URL: https://issues.apache.org/jira/browse/MATH-613
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
In Blas, the method {{DAXPY}} computes an in-place linear combination of two
vectors. More precisely, a call to {{DAXPY(a, x, y)}} updates vector {{y}} with
the value of {{a * x + y}}. This can lead to very compact code, which I feel
the need for in Commons-Math. However, DAXPY also has its limitations. For
example, it cannot perform the other combination {{y <- x + a * y}}.
I think it would be useful that {{RealVector}} had a method for computing {{a *
this + b * y}}, and storing the result in {{this}}. In the spirit of the
{{mapToSelf}} method, I propose to create two new methods in {{Interface
RealVector}}
{noformat}RealVector map(BivariateRealFunction f, RealVector y){noformat}
and
{noformat}RealVector mapToSelf(BivariateRealFunction f, RealVector y){noformat}
The former would return a new vector {{v}} such that
{noformat}v[i] <- f(this[i], y[i])}}{noformat}
and the latter would update {{this}},
{noformat}this[i] <- f(this[i], y[i]){noformat}
Emulating {{DAXPY}} would then simply be a matter of implementing the
appropriate bivariate function.
While we are at it, how about
{noformat}RealVector map(TrivariateRealFunction f, RealVector y, RealVector
z){noformat}
{noformat}RealVector mapToSelf(TrivariateRealFunction f, RealVector y,
RealVector z){noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[ https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Hendriks updated MATH-605: - Attachment: overlapping-events-tests.patch Fixed patch for consistency. > Missing state events due to events between t0 and t0+e being ignored > > > Key: MATH-605 > URL: https://issues.apache.org/jira/browse/MATH-605 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Dennis Hendriks > Attachments: OverlappingEventsTest.java, > overlapping-events-tests-v3.patch, overlapping-events-tests.patch, > overlapping-events-tests.patch > > > The Commons Math page on ODEs > (http://commons.apache.org/math/userguide/ode.html) states in section 13.3 > (Discrete Events Handling), that: "Note that g function signs changes at the > very beginning of the integration (from t0 to t0 + ε where ε is the events > detection convergence threshold) are explicitely ignored. This prevents > having the integration stuck at its initial point when a new integration is > restarted just at the same point a previous one had been stopped by an event." > However, due the following issues: > - MATH-586: Allow using a custom root-finding algorithm to detect state > events > - MATH-599: Re-implementation of Secant-based root finding algorithms > we can now use for instance the PegasusSolver to detect state events. Using > the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the > event. As such, skipping (future) events between t0 and t0+e is not desired. > I attached a Java class to show this issue. It has 2 continuous variables, > each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever > they become larger than 1.0, they are reset. We thus expect resets for event > 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc. > The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the > events however are not detected at the exact same times. After we processed > the first, the 'skip everything between t0 and t0+e' may result in skipping > events, as can be observed from the failing unit test. The second test has a > hack to get around this problem: it is manually checked whether the guard > changes, by evaluating t0 and t0+e. If an event is detected, a step of e is > done, and integration is restarted from t0+e. This solves the issue, and the > unit tests succeeds (we get the events at the expected times, and we don't > miss any events). > From what I understand, event detection is complicated, as discussed in > MATH-484. I propose to make the skipping of events betweeen t0 and t0+e > optional, as that is no longer needed in the cases I described above, and in > fact causes severe problems that can only be solved by hacks. For other > (non-bracketed solution) algorithms, it may still be necessary to skip such > roots. Maybe an option could be introduced to control this behavior? > So, if an event is detected at time t, integration may continue from t0=t, > and if there is a sign change for t0 and t0+e, then the step handler should > be called for t0+e, and the step handler should be called for t0+e as well, > with isLast=true. I'm not sure what the value of e should be. It could be the > absolute accuracy of the root-finding algorithm. if there are multiple ones, > maybe the maximum of all of them. Maybe even the minimal integration step > should be taken into account, taking the maximum of that an dall the absolute > accuracies of the root-finding algorithms? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[ https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Hendriks updated MATH-605: - Attachment: overlapping-events-tests-v3.patch Forgot to add a file. So, third version of the patch... > Missing state events due to events between t0 and t0+e being ignored > > > Key: MATH-605 > URL: https://issues.apache.org/jira/browse/MATH-605 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Dennis Hendriks > Attachments: OverlappingEventsTest.java, > overlapping-events-tests-v3.patch, overlapping-events-tests.patch, > overlapping-events-tests.patch > > > The Commons Math page on ODEs > (http://commons.apache.org/math/userguide/ode.html) states in section 13.3 > (Discrete Events Handling), that: "Note that g function signs changes at the > very beginning of the integration (from t0 to t0 + ε where ε is the events > detection convergence threshold) are explicitely ignored. This prevents > having the integration stuck at its initial point when a new integration is > restarted just at the same point a previous one had been stopped by an event." > However, due the following issues: > - MATH-586: Allow using a custom root-finding algorithm to detect state > events > - MATH-599: Re-implementation of Secant-based root finding algorithms > we can now use for instance the PegasusSolver to detect state events. Using > the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the > event. As such, skipping (future) events between t0 and t0+e is not desired. > I attached a Java class to show this issue. It has 2 continuous variables, > each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever > they become larger than 1.0, they are reset. We thus expect resets for event > 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc. > The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the > events however are not detected at the exact same times. After we processed > the first, the 'skip everything between t0 and t0+e' may result in skipping > events, as can be observed from the failing unit test. The second test has a > hack to get around this problem: it is manually checked whether the guard > changes, by evaluating t0 and t0+e. If an event is detected, a step of e is > done, and integration is restarted from t0+e. This solves the issue, and the > unit tests succeeds (we get the events at the expected times, and we don't > miss any events). > From what I understand, event detection is complicated, as discussed in > MATH-484. I propose to make the skipping of events betweeen t0 and t0+e > optional, as that is no longer needed in the cases I described above, and in > fact causes severe problems that can only be solved by hacks. For other > (non-bracketed solution) algorithms, it may still be necessary to skip such > roots. Maybe an option could be introduced to control this behavior? > So, if an event is detected at time t, integration may continue from t0=t, > and if there is a sign change for t0 and t0+e, then the step handler should > be called for t0+e, and the step handler should be called for t0+e as well, > with isLast=true. I'm not sure what the value of e should be. It could be the > absolute accuracy of the root-finding algorithm. if there are multiple ones, > maybe the maximum of all of them. Maybe even the minimal integration step > should be taken into account, taking the maximum of that an dall the absolute > accuracies of the root-finding algorithms? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063263#comment-13063263
]
Henri Biestro commented on JEXL-113:
The reason for the Set> would be to track both 'dot' operators and
'bracketed' expressions since they dont differ in evaluation. Every 'dot' expr
can be rewritten as a 'bracketed' expr (not the opposite because of
restrictions in allowed characters for identifiers).
Anyway, reusing your example:
a + b.c + d[e][f] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} }
However, a + b[func()] would only return { {"a"}, {"b"} }
Cheers,
Henri
> Dot notation behaves unexpectedly with null values
> --
>
> Key: JEXL-113
> URL: https://issues.apache.org/jira/browse/JEXL-113
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: JDK 1.6
>Reporter: Max Tardiveau
>
> When a variable of the form a.b is evaluated, the context is asked first for
> the value of a. That value is then asked for the value of b.
> So far, so good: this is exactly what you'd expect from the dot operator.
> But if the value of b is null, the context is then asked for the value of
> a.b, in other words the dot operator is ignored and "a.b" is considered to be
> a single variable.
> This is at best confusing. Granted, this can be avoided with the a['b']
> notation, but that's clumsy.
> I assume this is an attempt to support both the dot operator and ant-style
> variables. I don't think you can have both and remain sane.
> Suggestion: either document this behavior, or make it an option. My vote
> would be to just use the value returned, even if it's null. Either dot is an
> operator, or it's not. Perhaps make that configurable?
> Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
[ https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Hendriks updated MATH-605: - Attachment: overlapping-events-tests.patch Nice work Luc! I tested it on my application, and I no longer need the hack that I previously used. I added a new patch (overlapping-events-tests.patch) that provides a few test cases to test this new functionality. It is a modified unit test from the original file I attached to this issue, when I reported this issue, etc. Also, I checked all your commits. The patch fixes some comments here and there. Finally, I fixed the verifyBracketing/isBracketing methods in the UnivariateRealSolverUtils class, to also except intervals that have a zero function value at one of the end points. Thanks for you efforts. > Missing state events due to events between t0 and t0+e being ignored > > > Key: MATH-605 > URL: https://issues.apache.org/jira/browse/MATH-605 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Dennis Hendriks > Attachments: OverlappingEventsTest.java, > overlapping-events-tests.patch > > > The Commons Math page on ODEs > (http://commons.apache.org/math/userguide/ode.html) states in section 13.3 > (Discrete Events Handling), that: "Note that g function signs changes at the > very beginning of the integration (from t0 to t0 + ε where ε is the events > detection convergence threshold) are explicitely ignored. This prevents > having the integration stuck at its initial point when a new integration is > restarted just at the same point a previous one had been stopped by an event." > However, due the following issues: > - MATH-586: Allow using a custom root-finding algorithm to detect state > events > - MATH-599: Re-implementation of Secant-based root finding algorithms > we can now use for instance the PegasusSolver to detect state events. Using > the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the > event. As such, skipping (future) events between t0 and t0+e is not desired. > I attached a Java class to show this issue. It has 2 continuous variables, > each starts at 0.0. The first has derivative 1.0, the second 2.0. Whenever > they become larger than 1.0, they are reset. We thus expect resets for event > 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5, etc. > The events overlap (at 1.0, 2.0, etc). Due to numerical differences, the > events however are not detected at the exact same times. After we processed > the first, the 'skip everything between t0 and t0+e' may result in skipping > events, as can be observed from the failing unit test. The second test has a > hack to get around this problem: it is manually checked whether the guard > changes, by evaluating t0 and t0+e. If an event is detected, a step of e is > done, and integration is restarted from t0+e. This solves the issue, and the > unit tests succeeds (we get the events at the expected times, and we don't > miss any events). > From what I understand, event detection is complicated, as discussed in > MATH-484. I propose to make the skipping of events betweeen t0 and t0+e > optional, as that is no longer needed in the cases I described above, and in > fact causes severe problems that can only be solved by hacks. For other > (non-bracketed solution) algorithms, it may still be necessary to skip such > roots. Maybe an option could be introduced to control this behavior? > So, if an event is detected at time t, integration may continue from t0=t, > and if there is a sign change for t0 and t0+e, then the step handler should > be called for t0+e, and the step handler should be called for t0+e as well, > with isLast=true. I'm not sure what the value of e should be. It could be the > absolute accuracy of the root-finding algorithm. if there are multiple ones, > maybe the maximum of all of them. Maybe even the minimal integration step > should be taken into account, taking the maximum of that an dall the absolute > accuracies of the root-finding algorithms? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-599) Re-implementation of Secant-based root finding algorithms
[ https://issues.apache.org/jira/browse/MATH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063222#comment-13063222 ] Dennis Hendriks commented on MATH-599: -- bq. If everyone agrees, we could resolve this issue. Nice work Luc. As far as I'm concerned, the issue is resolved. > Re-implementation of Secant-based root finding algorithms > - > > Key: MATH-599 > URL: https://issues.apache.org/jira/browse/MATH-599 > Project: Commons Math > Issue Type: Improvement >Reporter: Dennis Hendriks > Labels: documentation, patch > Fix For: 3.0 > > Attachments: secant-based-root-finding-algos.patch, > secant-based-root-finding-algos2.patch, secant-based-root-finding-algos2.zip > > > Apache Commons Math currently has a SecantSolver. It is unclear exactly what > algorithm this solver implements. It states: "The algorithm is modified to > maintain bracketing of a root by successive approximations. Because of forced > bracketing, convergence may be slower than the unrestricted Secant algorithm. > However, this implementation should in general outperform the Regula Falsi > method." The Regula Falsi method is exactly the Secant method modified to > maintain a bracketed solution. It is therefore unclear what other > modifications were done to make it 'better' than the Regula Falsi method. > Besides the Secant and Regula Falsi methods, several other Secant-based > root-finding algorithms exist, such as the the Illinois method, and the > Pegasus method. All 4 are well-known, publisched algorithms. > I created a patch, which changes the following: > - Removed SecantSolver root-finding algorithm. > - Implemented new Secant-based root-finding algorithms: SecantSolver, > RegulaFalsiSolver, IllinoisSolver, and PegasusSolver. > - Introduced BracketedSolution interface and AllowedSolutions enumeration, > to control allowed solutions (under-approximations and over-approximations) > for bracketed root-finding algorithms. Implemented for RegulaFalsiSolver, > IllinoisSolver, and PegasusSolver. > - Fixed documentation of BaseUnivariateRealSolver.solve methods, such that > documentation order of arguments matches the order of the actual arguments. > Note that the original SecantSolver was removed, and replaced by a > root-finding algorithm that actually implements the Secant root-finding > algorithm. As such, existing code using the SecantSolver is not backwards > compatible. That is, even though the new SecantSolver does implement the same > interfaces, the root-finding solutions may differ. In particular, the new > SecantSolver does not maintain a bracketed solution, and does not guarantee > convergence. > I added unit tests, and I did a build, including checkstyle checking. I did > not fix all checkstyle warnings though, as I consider some of them false > positives. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-707) Add methods to avoid Sun JVM synchronisation overhead in new String(byte[] b, String enc)
[ https://issues.apache.org/jira/browse/LANG-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-707: --- Component/s: General > Add methods to avoid Sun JVM synchronisation overhead in new String(byte[] b, > String enc) > - > > Key: LANG-707 > URL: https://issues.apache.org/jira/browse/LANG-707 > Project: Commons Lang > Issue Type: Improvement > Components: General > Environment: https://issues.apache.org/bugzilla/show_bug.cgi?id=51400 >Reporter: Sebb > Fix For: 3.x > > > According to Tomcat bug 51400, the use of new String(byte[] b, String enc) > can fall foul of a Sun Java synchronisation bottleneck. > Might be useful to add the code workround to Commons Lang. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-708) StringEscapeUtils.escapeEcmaScript from lang3 cuts off long unicode string
[
https://issues.apache.org/jira/browse/LANG-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-708:
---
Component/s: lang.text.translate.*
> StringEscapeUtils.escapeEcmaScript from lang3 cuts off long unicode string
> --
>
> Key: LANG-708
> URL: https://issues.apache.org/jira/browse/LANG-708
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.translate.*
>Reporter: anton
> Fix For: 3.x
>
> Attachments: Test.java, input.txt
>
>
> Hello, I have a really big JSON string (generated from db) with unicode chars
> and I need to pass it though StringEscapeUtils.escapeEcmaScript(value). This
> string is generated and in most cases it works ok, but I have met a specific
> string (attached below) which is not correctly converted - few symbols (about
> 10) at the end of the string are cut-off (and actually they are not already
> unicode chars).
> the original string ends with:
> "geonameId":6544329,"valueCode":""}]
> and the produced string ends with:
> \"geonameId\":6544329,\"value
> So Code":""}] part is missing and this does not allow to parse the result as
> JSON on the client side.
> I have tried to debug a bit with StringEscapeUtils.escapeEcmaScript source
> code and is seems that the problem is somewhere around here:
> CharSequenceTranslator.translate(...){
> ...
> int sz = Character.codePointCount(input, 0, input.length());
> for (int i = 0; i < sz; i++) {
> // consumed is the number of codepoints consumed
> int consumed = translate(input, i, out);
> if(consumed == 0) {
> out.write( Character.toChars( Character.codePointAt(input, i)
> ) );
> }
> ...
> }
> If I put breakpoint condition to stop in the loop when i==(sz-5), I can see
> that the last chars of "valueCode" literal are being added to the end of
> "out" stream, but the counter condition ends too early to reach the end of
> original input String.
> So, it seems that somehow with the provided string either the sz value is
> calculated incorrectly or the processing loop did wrong counter adjustmes at
> some point.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-717) Specify source encoding for build
[ https://issues.apache.org/jira/browse/LANG-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062877#comment-13062877 ] Joerg Schaible commented on LANG-717: - In Maven we already define ISO-8859-1. > Specify source encoding for build > - > > Key: LANG-717 > URL: https://issues.apache.org/jira/browse/LANG-717 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 3.0 > Environment: Linux, UTF-8 >Reporter: Ville Skyttä >Priority: Minor > Labels: patch > Fix For: 3.x > > Attachments: encoding.patch > > > The build does not specify a source encoding, which ends up causing lots of > (harmless) warnings from javac and javadoc in UTF-8 setups due to some > ISO-8859-1 comments in EntityArrays.java. > Fix attached, however I have only tested the Ant part, not the Maven one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
