Your example hides a lesser consistency: the list of eigenvalues for a matrix over QQ does seem to lie either in Q (if all the eigenvalues lie in QQ) or in QQbar. Putting them in QQbar in all cases is of course the general thing to do, but if you know your matrix has rational eigenvalues and you just want to work with them (take their numerator and denominator perhaps? reduce them mod p?) it could be quite annoying to find them in QQbar. Arithmetic in QQbar is also going to be horribly slow in comparison.
I can see why, with such an expensive general parent, there might be an argument to put the arguments in a smaller parent when possible (for all of them). There is a practical argument to be made here for why one might want to deviate from the purity of "parent of return value determined by parent of input". The documentation is formulated in a confusing way: It can be read as if for matrices over QQ, only *separate* roots are returned: no multiplicity information. I haven't tested this, but I'm pretty sure that's not what is intended. The documentation also doesn't reflect the "parent optimization". I think that's your main question. As described above, I think there's some practical nuance to that... In actuality, due to the problem "eigenvalues in what field"? I'd probably steer away from routines like "eigenvalues" in my own code, because I wouldn't dare to trust the choice that's made. I probably instead would just ask for the characteristic poly and determine its roots where I want (that's almost never QQbar unless it's in an interactive situation), and then work with that. On Wednesday, 3 December 2025 at 01:52:39 UTC-8 [email protected] wrote: > Do we really want that the parent of the result depends on the *value* of > its input here, rather than on the parent of the input? > > Actually, strictly speaking the documentation promises something else: > > Return a sequence of the eigenvalues of a matrix, with > multiplicity. If the eigenvalues are roots of polynomials in > ``QQ``, > then ``QQbar`` elements are returned that represent each separate > root. > > Do I misunderstand this, or *is* the behaviour a bug? (If so, it is easy > to fix.) > > I am guessing that harmonizing the hash of QQbar with the hash of QQ is > expensive. Also, I don't think it would be the correct fix. > > Martin > On Tuesday, 2 December 2025 at 23:20:30 UTC+1 Martin R wrote: > >> sage: OZ = lambda P: (ones_matrix(P.cardinality()) - P.lequal_matrix()) >> sage: set(min(OZ(P).eigenvalues()) for n in range(1, 7) for P in >> posets(n)) >> {-1, -1, 0} >> sage: [type(x) for x in _] >> [<class 'sage.rings.rational.Rational'>, >> <class 'sage.rings.rational.Rational'>, >> <class 'sage.rings.qqbar.AlgebraicNumber'>] >> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/2a50d927-7b5b-47e1-b9d4-71074cc75155n%40googlegroups.com.
