To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
On Mon, May 9, 2011 at 11:16 AM, Yevgen Kogan wrote:
>
> Dear all,
>
> the line 90 of the
> /commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator
> looks like this:
>
> State s = (State) iter.next();
>
> The cast to State causes an cast exception
Le 09/05/11 17:31, Phil Steitz a écrit :
On 5/9/11 4:27 AM, Gilles Sadowski wrote:
Hi.
I'm currently trying to integrate my implementation of iterative linear
solvers in the commons-math architecture.
Thanks for contributing.
Among other things, I want to reuse
as many existing exceptions a
Le 09/05/11 19:52, Luc Maisonobe a écrit :
Le 09/05/2011 09:15, Arne Plöse a écrit :
Hi,
here are some proposals for enhancing FieldElement:
add some shorthand "operators" for double i.e. add(double rhs) ... and
so on.
add:
T negate();
T sqrt();
T pow(T x);
T pow(double x);
This is possible
Le 09/05/2011 09:15, Arne Plöse a écrit :
Hi,
here are some proposals for enhancing FieldElement:
add some shorthand "operators" for double i.e. add(double rhs) ... and
so on.
add:
T negate();
T sqrt();
T pow(T x);
T pow(double x);
This is possible only for negate() in the FieldElement. Not
Dear all,
the line 90 of the
/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator
looks like this:
State s = (State) iter.next();
The cast to State causes an cast exception for my state machine, because some
of my states are derived from
On 5/9/11 4:27 AM, Gilles Sadowski wrote:
> Hi.
>
>> I'm currently trying to integrate my implementation of iterative linear
>> solvers in the commons-math architecture.
> Thanks for contributing.
>
>> Among other things, I want to reuse
>> as many existing exceptions as possible. I've come accross
Hi.
> I'm currently trying to integrate my implementation of iterative linear
> solvers in the commons-math architecture.
Thanks for contributing.
> Among other things, I want to reuse
> as many existing exceptions as possible. I've come accross the following
> points
> 1. naming the parameters
On 9 May 2011 08:15, Arne Plöse wrote:
> Hi,
>
> here are some proposals for enhancing FieldElement:
Please could you create a JIRA enhancement request for this?
It's much easier to keep track of JIRA issues than an e-mail.
> add some shorthand "operators" for double i.e. add(double rhs) ... an
Dear all,
I'm currently trying to integrate my implementation of iterative linear
solvers in the commons-math architecture. Among other things, I want to reuse
as many existing exceptions as possible. I've come accross the following
points
1. naming the parameters in the constructor of NonSquareMat
Hi,
here are some proposals for enhancing FieldElement:
add some shorthand "operators" for double i.e. add(double rhs) ... and
so on.
add:
T negate();
T sqrt();
T pow(T x);
T pow(double x);
the FieldVector interface should be enhanced with this methods as well.
Yes, I know this has an impact o
12 matches
Mail list logo