On Jun 24, 11:48 am, Rob Beezer <[email protected]> wrote: > I am just now about to implement optionally promoting a QQ matrix to a > QQbar matrix when the eigenvalues lie outside QQ, to obtain an > alternate format for output, as described above. I don't think there > will be any disagreement with making that available. The question > will be - what should the default be?
For the core functionality methods, we should not be guided by pedagogical concerns but with what makes most sense in the entire system. It is valuable to have consistent defaults. For general fields (e.g., and algebraic extension of the function field Q(x,y)) we won't have any reasonable analogues of QQbar, so I don't think there is a reasonable default possible other than giving eigenvalues/vectors/ spaces defined over the original base field. For rings the whole concept becomes a little more complicated anyway. However, if these are methods that are already added to provide a pedagogical/convenient interface, then core consistency is of course not an issue. In general, I would say the methods are the place for core functionality offered in a consistent (because ducktyped!) way and toplevel functions exist to do funny, convenient, less consistent tricks (such as the injecting "var" on interactive toplevel), but putting extra eigenspace/value/vector functions in toplevel might be too much pollution. -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
