On 5/22/20 3:39 PM, Nils Bruin wrote:
> I think this might need some work:
>
> S=RealBallField(100)
> M=Matrix(S,2,1,[1,1])
> M.solve_right(vector([1,2]))
>
> There's enough information here to conclude there is no solution; or in
> a rather deranged way, perhaps it should give a rather large ball back
> so that the multiplication results in a vector consisting of balls that
> actually contain the values 1 and 2. Currently, it just returns a wrong
> answer.
This "accidentally" gave the right answer (no solution) in the past due
to the "check" parameter, implemented in the base matrix class,
# Have to check that we actually solved the equation.
if self*X != B:
raise ValueError("matrix equation has no solutions")
return X
that is generally nonsensical over an inexact ring (it rejects good
answers). The change you're seeing -- and the change in the original
post -- is that in the base matrix class we no longer try to check the
answer using equality over inexact rings. While removing the check may
have toggled a few (right, wrong) answers, I believe that doing so was
correct in and of itself.
> For systems that are even generically overdetermined, I don't think it
> makes sense to default to a least squares solution in a routine that is
> supposed to detect inconsistent systems. There the stable numerical
> behaviour actually IS being inconsistent.
How should we know if an inexact system is overdetermined? (Does the
term "generically overdetermined" have some technical meaning?)
We're only doing least squares over RDF and CDF. The default solve is
otherwise still totally naive. The real benefit of the refactoring is
that now we are in a position to override _solve_right_general() and
_solve_right_nonsingular_square() in any matrix subclasses where
additional information can be taken advantage of. For example, if the
answer can be checked reliably over RealBallField(100), then it should
be fairly easy to do so without wrecking things for, say, RR.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/9be14041-f74e-c1ae-aab4-a27762ab8b6b%40orlitzky.com.
