On Sun, 2021-04-25 at 15:07 +0200, Fredrik Johansson wrote: > Hi all, > > I'm looking for benchmark problems for QQbar/AA arithmetic. Ideally such a > problem will: > > * Be reducible to a short program that, apart from using QQbar/AA > operations, is reasonably self-contained. > * Reflect real-world use, i.e. originate from using Sage to solve an actual > mathematical problem, with QQbar/AA arithmetic being a significant > ingredient.
I'm interested in Gram-Schmidt and the coordinate_vector() methods that solve linear systems over AA. For a benchmark, you could conjure a set of long vectors with entries in AA/QQbar, and orthonormalize them using the kindergarten algorithm that everyone knows. That will leave a linearly-independent set, and if you keep the input/output indices matched up, will let you know which of the input vectors correspond to that linearly independent set. Call the set of those input vectors "X". Then to benchmark the coordinate_vector() methods, you can generate random elements in W=span(X), and solve the system to find their W-coordinates in terms of the basis X. (Using the de-orthonormalized vectors as the basis makes the system harder to solve, and more representative of the general case.) Unimportant background information: A Euclidean Jordan algebra (EJA) is a real vector space where every element "x" has a self-adjoint "left multiplication by x" operation that I'll write L_x. It turns out that every EJA is a mishmash of various Hermitian matrix algebras, which is nice, because it lets you think of their elements as being some concrete object rather than just an abstract vector space element. For example, the space of real symmetric matrices with L_x(y) := (xy + yx)/2 induces an EJA. But when people think of a symmetric matrix, they're thinking of it in terms of the standard basis, which leads to a problem; namely that the basis [1 0] [0 1] [0 0] [0 0], [1 0], [0 1] for S^2 is not normalized. This raises a problem: while L_x is always self-adjoint, its matrix representation won't be symmetric unless your basis is orthonormal. And you need its matrix to be symmetric if you want to do anything cool with it in sage, because sage assumes that when you have a matrix full of numbers, they're with respect to the standard basis. In short, this means that a sqrt(2) must become involved, and the "2" isn't special. Here's where Gram-Schmidt comes in. Afterwards, matrices aren't vectors in sage, so converting back and forth between matrix/vector representations involves a lot of to_vector() and coordinate_vector() over AA. Things get worse: when constructing a subalgebra, its basis needs to be orthonormalized as well, and we need to be able to convert back and forth between the orthonormalized superalgebra coordinates and the orthonormalized subalgebra coordinates. Thus we wind up orthonormalizing vectors that already have ugly entries, and solving systems with uglier and uglier entries in AA. This is a bottleneck when the algebras get "big," which they do even in simple examples (the Albert algebra has dimension 27). -- 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/1620f0b7f268a16e477d74f7295d9b1340285604.camel%40orlitzky.com.
