My vote, which is from a user's and not a developer's perspective, is
to somehow coerce QQbar and AA into SR to preserve exact values and
manipulate symbolic expressions such as QQbar(sqrt(2))*x. That sure
would be helpful for my work. Is that problematic?
Alex
On Apr 8, 11:44 pm, Burcin Erocal <bur...@erocal.org> wrote:
> Hi again Alex,
>
> Many thanks for the report.
>
> On Wed, 7 Apr 2010 16:05:09 -0700 (PDT)
>
> Alex Raichev <tortoise.s...@gmail.com> wrote:
> > Hi all:
>
> > I ran into an error trying to evaluate the exponential function at an
> > algebraic number. Looks like there's a bug in substituting algebraic
> > numbers for variables; see below. While i was at it, i tried creating
> > the expression QQbar(sqrt(2))*x and got a not implemented error.
> > Wasn't symbolics with QQbar working in previous versions of Sage, or
> > am i mistaken?
>
> Most structures in Sage coerce to SR, so when you do
>
> sage: 1 + x
>
> the result in SR, even though 1 is in ZZ, and x in SR. This is not the
> case for QQbar and AA. Copying from a comment in
> sage/symbolic/function.pyx:
>
> # There is no natural coercion from QQbar to the symbolic ring
> # in order to support
> # sage: QQbar(sqrt(2)) + sqrt(3)
> # 3.146264369941973?
>
> I wrote that comment to document the current behavior, but I don't
> necessarily agree with this policy.
>
> Under these conditions,
>
> sage: x*QQbar(sqrt(2))
>
> cannot work. Since we cannot coerce QQbar(sqrt(2)) to SR, we try to
> coerce x to QQbar.
>
> I worked around this limitation for evaluating symbolic functions like
> exp, but didn't think about substituting values. This can be fixed
> easily by converting QQbar arguments to CC before we coerce them to SR.
>
> I think we should reconsider the coercion policy though. For example
>
> > sage: exp(QQbar(sqrt(2)))
> > 4.11325037878293
>
> this should remain exact, since QQbar keeps exact values. Then you can
> evaluate to an arbitrary precision. Since sqrt(2) is converted to CC,
> an inexact parent, we get a numerical evaluation in this case.
>
> If we change the coercion policy the examples below will just work.
> Otherwise
>
> > sage: exp(x).subs({x:QQbar(sqrt(2))})
>
> <boom>
>
> > sage: x.subs({x:QQbar(sqrt(2))})
>
> <boom>
>
> These two are bugs, they will be equivalent to
> sage: x.subs({x:CC(QQbar(sqrt(2)))})
>
> after the fix.
>
> This one cannot work with the current coercion direction SR -> QQbar.
>
> > sage: QQbar(sqrt(2))*x
>
> <boom>
>
> Comments?
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
To unsubscribe, reply using "remove me" as the subject.
