Re: [eigen] solve with and without check

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


2009/8/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2009/8/24 Andrea Arteaga <yo.eres@xxxxxxxxx>:
>>> --> i propose the following change:
>>> in all decompositions that have a solve() checking for existence,
>>> let's rename solve() to solveWithCheck()   (or whatever native English
>>> speakers prefer... perhaps trySolve() ? checkSolve() ? )
>>> then let's add a method solve() that doesn't do any check, making it
>>> the responsibility of the caller that a decent solution exists.
>>
>> Or the opposite.
>> For example if one want to access to a matrix without control, has to use the coeff() or coeffRef()
>> methods, while the operator() (i.e. the primary choice) makes a control. In order to ensure the
>> consistency with the other parts of Eigen, the solve() method should make a control, while another
>> method (solveWithoutCheck() or whatever) should return the solution without performing the check.
>
> Here we have a bad case of conflicting principles:
>
> "The safest should be the default"
>
> versus
>
> "The most common should be the default"
>
> For operator() versus coeff(), it was an easy choice because in most
> cases the user wants the check, and can always disable it by disabling
> asserts.
>
> Here it's different, solveWithCheck is probably not the most common case.
>
> Let me stress the problem a bit more: the current solve isn't too
> reliable

Need to stress this: because of this unreliability, the current solve
isn't really the "safe way" that it's supposed to be.

My humble opinion: we remove it for now (so solve becomes
non-checking) and at a later date, if/when we have triangular solvers
that can check for existence, we add it back as solveWithCheck.

Of course it's not hard to write such triangular solvers, as long as
one doesn't try to optimize.

Benoit



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/