|Re: [eigen] solve with and without check|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] solve with and without check
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 24 Aug 2009 14:23:32 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IbTkcruK0OEKGqlrAbUwCYVwRqkLoe6UMEbNjIecV3k=; b=oy4H0pjHxJs96VYtVe3o5NEq11YYHzF2ByQJ5JblNIXsVweBEKuY/6EOU8tDQrXvKg /Aw/phesDSsSwhOnz8+gWCrJNK26MScG6EihvFYlAX9gYptW8IAG1Ra3Fs6DwVa1gJJC UEj42xC5GKmfh1uLmRAyhR7mXg3F2JDtmfocI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Jo4tkTHF1TG6LWjSaCI3GFpsfNTEcLjlJlnLZGM+tYY7HjUv1GV25Cbg23Rk4K3Wd1 /tjAe6zXYie0gA8qHDLSkLijTZ2tPIRdgU8lyteeo3qTKJZ+KSDOq9TGZo8btHlA2P44 zmU4sI6pdvvTSX6hcG0r8GSdw3fDfd///1RRw=
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"
> "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
> 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
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.