On Feb 8, 5:29 am, Burcin Erocal <[email protected]> wrote: > If we use number fields for algebraic numbers, then the degree of the > extension over QQ grows to unreasonable values rather quickly. E.g., > if we add \sqrt{2}, \sqrt[3]{2}, sqrt[5]{2}, ... the degree will be > proportional to factorial(n). Though, I would also like all the numeric > values to be in the coefficients.
Yes, I was more surprised that I *does* get represented as an algebraic number and not just as an abstract symbol. It leads to strange discrepancies like: sage: (1+cos(x))*(1+I) (I + 1)*cos(x) + I + 1 sage: (1+cos(x))*(1+sqrt(2)) (cos(x) + 1)*(sqrt(2) + 1) It also means that in unpacking an Expression, one has to be prepared to deal with the possibilities that pyobjects that emerge may be algebraic numbers (and then come up with a watertight criterion when it's safe to map it over to imaginary "I"). Given one can already deal with sqrt(..), wouldn't it be safer to make SR(I) be represented internally as sqrt(-1)? It would be elegant if one could use Qbar, since that keeps track of ambiguities between conjugates like sqrt(d) and -sqrt(d). Given that elements there would be represented as sparse polynomials with some extra data to tell apart conjugates, I don't think it would be that much more expensive than the expression trees that get used now. There are some potentially very expensive operations, but those would likely be impossible or lead to wrong answers in the present model (think nested radicals). Any expression going to maxima and back would obviously have its special Qbar properties ruined. -- 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
