Hello.
> >
> >> >>>
> >> >>> in ConjugateGradient, I get the following error
> >> >>>
> >> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
> >> >>> throws clause in
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> >> >>> RealLinearOperator,
On 9/2/12 7:35 PM, Sébastien Brisard wrote:
> Hi,
> here is another problem. In
> MatrixUtils.createFieldIdentityMatrix(Field, int), the constructor
> Array2DRowFieldMatrix(Field, T[][], boolean) is called. This
> constructor throws a DimensionMismatchException if the data array is
> not rectangula
Hi again,
2012/9/1 Gilles Sadowski :
> Hello.
>
>> >>>
>> >>> in ConjugateGradient, I get the following error
>> >>>
>> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> >>> throws clause in
>> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>>
Hi,
here is another problem. In
MatrixUtils.createFieldIdentityMatrix(Field, int), the constructor
Array2DRowFieldMatrix(Field, T[][], boolean) is called. This
constructor throws a DimensionMismatchException if the data array is
not rectangular. This is never going to occur in
createFieldIdentityMa
Hi,
2012/9/1 Gilles Sadowski :
> Hello.
>
>> >>>
>> >>> in ConjugateGradient, I get the following error
>> >>>
>> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> >>> throws clause in
>> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>> >>> Re
Hello.
> >>>
> >>> in ConjugateGradient, I get the following error
> >>>
> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
> >>> throws clause in
> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> >>> RealLinearOperator, RealVector, RealVector)"
Le 01/09/2012 10:42, Sébastien Brisard a écrit :
> Hi Luc,
>
> 2012/9/1 Luc Maisonobe :
>> Le 01/09/2012 10:03, Sébastien Brisard a écrit :
>>> Hi,
>>>
>>> in ConjugateGradient, I get the following error
>>>
>>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>>> throws clau
Hi Luc,
2012/9/1 Luc Maisonobe :
> Le 01/09/2012 10:03, Sébastien Brisard a écrit :
>> Hi,
>>
>> in ConjugateGradient, I get the following error
>>
>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> throws clause in
>> PreconditionedIterativeLinearSolver.solveInPlace(Real
Le 01/09/2012 10:03, Sébastien Brisard a écrit :
> Hi,
>
> in ConjugateGradient, I get the following error
>
> "Exception NonPositiveDefiniteOperatorException is not compatible with
> throws clause in
> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> RealLinearOperator, Rea
Hi,
in ConjugateGradient, I get the following error
"Exception NonPositiveDefiniteOperatorException is not compatible with
throws clause in
PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
RealLinearOperator, RealVector, RealVector)"
This comes from the fact that general iter
Hello,
2012/8/31 Thomas Neidhart :
> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>> Hello,
>>>
>>> [...]
>>>
>>> Thus, shall I open a JIRA ticket with the tasks of completing the
>>> "throws"
>>> clauses of all CM methods?
On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>> Hello,
>>
>> [...]
>>
>> Thus, shall I open a JIRA ticket with the tasks of completing the
>> "throws"
>> clauses of all CM methods?
>> Does someone absolutely needs this task
Le 31/08/2012 03:22, Sébastien Brisard a écrit :
> Hello,
>
> [...]
>
> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
> clauses of all CM methods?
> Does someone absolutely needs this task tobe completed before releasing
> 3.1?
> [I don't t
Hello,
[...]
Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
clauses of all CM methods?
Does someone absolutely needs this task tobe completed before releasing
3.1?
[I don't think that it's possible without a huge effort from everyone.
On 08/30/2012 12:41 PM, Luc Maisonobe wrote:
> Le 30/08/2012 05:08, Sébastien Brisard a écrit :
>> Hello,
Hi,
sorry, I did not participate much in the discussion.
>> 2012/8/30 Gilles Sadowski :
>>> Hello.
>>>
>>> To summarize:
>>> (1) Does anyone disagree with having all CM exceptions inherit
>
On Aug 30, 2012, at 4:56 AM, Gilles Sadowski
wrote:
>>> [...]
>>>
>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>> clauses of all CM methods?
>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>> [I don't think that it's possi
> > [...]
> >
> > Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
> > clauses of all CM methods?
> > Does someone absolutely needs this task tobe completed before releasing 3.1?
> > [I don't think that it's possible without a huge effort from everyone.]
Ticket created:
Le 30/08/2012 05:08, Sébastien Brisard a écrit :
> Hello,
>
> 2012/8/30 Gilles Sadowski :
>> Hello.
>>
>> To summarize:
>> (1) Does anyone disagree with having all CM exceptions inherit
>> from a new "MathRuntimeException" which itself will inherit
>> from the standard "RuntimeException
Hi,
2012/8/30 Gilles Sadowski :
> On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote:
>> On 8/29/12 3:04 PM, Gilles Sadowski wrote:
>> > Hello.
>> >
>> > To summarize:
>> > (1) Does anyone disagree with having all CM exceptions inherit
>> > from a new "MathRuntimeException" which it
On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote:
> On 8/29/12 3:04 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > To summarize:
> > (1) Does anyone disagree with having all CM exceptions inherit
> > from a new "MathRuntimeException" which itself will inherit
> > from the stand
Hello,
2012/8/30 Gilles Sadowski :
> Hello.
>
> To summarize:
> (1) Does anyone disagree with having all CM exceptions inherit
> from a new "MathRuntimeException" which itself will inherit
> from the standard "RuntimeException"?
+0: my background is not good enough.
> (2) Does anyone d
On 8/29/12 3:04 PM, Gilles Sadowski wrote:
> Hello.
>
> To summarize:
> (1) Does anyone disagree with having all CM exceptions inherit
> from a new "MathRuntimeException" which itself will inherit
> from the standard "RuntimeException"?
+0
> (2) Does anyone disagree with all exceptions
Hello.
To summarize:
(1) Does anyone disagree with having all CM exceptions inherit
from a new "MathRuntimeException" which itself will inherit
from the standard "RuntimeException"?
(2) Does anyone disagree with all exceptions being mandatorily
advertized in the "throws" clause of
> > No, you are not missing anything. Having only the javadoc without the
> > declaration in the signature is a pain. I would prefer to keep both.
>
> +1
>
> Just "going boom" with an unadvertised RTE is not acceptable
> behavior. We used to be very good about documenting and advertising
> all
> >> [...]
> > I think we had a discussion a few months ago on how exceptions should
> > be documented. We came to no agreement at that time, although one
> > option (which I followed) was to
> > - remove unchecked exceptions from the method's signature
> > - add the unchecjked exceptions to th
On 8/29/12 12:11 PM, Luc Maisonobe wrote:
> Le 29/08/2012 20:31, Sébastien Brisard a écrit :
>> Hello,
> Hi Sébastien,
>
>> 2012/8/29 Luc Maisonobe :
>>> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
Hi.
>>> Hello,
>>>
>> [...]
> I think I get your point, but again given transitive /
Le 29/08/2012 20:31, Sébastien Brisard a écrit :
> Hello,
Hi Sébastien,
>
> 2012/8/29 Luc Maisonobe :
>> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
>>> Hi.
>>
>> Hello,
>>
>>>
> [...]
I think I get your point, but again given transitive / nested
dependencies I would not wa
Hello,
2012/8/29 Luc Maisonobe :
> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
>> Hi.
>
> Hello,
>
>>
[...]
>>>
>>> I think I get your point, but again given transitive / nested
>>> dependencies I would not want to depend on it, even if all of the
>>> components have single-rooted exceptio
Le 29/08/2012 01:40, Gilles Sadowski a écrit :
> Hi.
Hello,
>
>>> [...]
>>
>> I think I get your point, but again given transitive / nested
>> dependencies I would not want to depend on it, even if all of the
>> components have single-rooted exception hierarchies. This is
>> especially true if
29 matches
Mail list logo
