To my mind, it would be best to make eigenvalues actually have the
same behavior as polynomials
sage: QQ["x"]("x^2 + 1").roots() # only roots in the base ring
[]
sage: QQbar["x"]("x^2 + 1").roots()
[(-1*I, 1), (1*I, 1)]
Polynomials actually allow a nice syntax to search roots somewhere
else with the extra argument "ring"
sage: QQ["x"]("x^2 + 1").roots(QQbar)
[(-1*I, 1), (1*I, 1)]
sage: QQ["x"]("x^2 + 1").roots(ring=QQbar)
[(-1*I, 1), (1*I, 1)]
Vincent
On Wed, 3 Dec 2025 at 18:47, Nils Bruin <[email protected]> wrote:
>
> 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.
--
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/CAGEwAA%3Dd7SBAMy2HuMJ%3DxP846ABEwUp2sJtsdqhf6e%3DHEnTGsw%40mail.gmail.com.
