On May 16, 2008, at 11:48 AM, William Stein wrote: > On Fri, May 16, 2008 at 11:44 AM, Carl Witty > <[EMAIL PROTECTED]> wrote: >> >> On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]> >> wrote: >>> What I think should happen is that sqrt(2) should be an element >>> of QQ >>> [sqrt(2)] rather than an element of SR. There is work supporting >>> this >>> kind of thing in the new coercion model (specifically, sqrt(2) would >>> be an element of QQ[sqrt(2)] with a specified embedding into RR, so >>> stuff like RR(1) + sqrt(2) would work). Then this kind of casting >>> could make a lot more sense. >> >> Anybody who implements this should steal code from qqbar.py. >> >> AA/QQbar can basically be divided into two parts: a framework for >> lazy >> arbitrary-precision arithmetic, that does computations using interval >> arithmetic whenever the interval arithmetic suffices to give an >> answer >> to the desired precision; and an exact layer that is used when the >> interval arithmetic is insufficiently precise. This exact layer is >> almost exactly what you describe above: it maintains extensions of QQ >> with embeddings into RR or CC, and automatically combines the >> extensions to let you do arithmetic like sqrt(2) + sqrt(3). >> >> I probably won't do it myself, but I would be very happy if somebody >> cleaned up this exact layer and moved it into number fields. > > Or maybe sqrt(2) should return an element of QQbar or AA?
QQbar is great, but it doesn't seem as neat. I want to be able to do stuff like sage: (1+sqrt(2))^3 3 + 2*sqrt2 instead of sage: (1+sqrt(2))^3 [5.8284271247461898 .. 5.8284271247461908] Especially working in Z[i] I think will look cleaner. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
