QQbar computations in 4.3 slow
Håkan Granath
It seems computations in QQbar is sometimes much slower in Sage
4.3 than in the previous version. Here is an example (I am sorry
if it is too convoluted):
v1 = sqrt(QQbar(3))
v2 = QQbar(999/1000*I)
v3 = (1 + v1)/2 + v2*(-3 - v1)/2
v4 = (3 - v1)/2 + v2*(1 - v1)/2
v5 = v3*(1/2) + v4*QQbar(500/999*I)
v6 = v3*(1/2) + v4*QQbar(-500/999*I)
v7 = -(v5/v6).conjugate() - QQbar(abs(v5))/v5/v6.conjugate()*QQbar(I)
v8 = -(v5/v6).conjugate() + QQbar(abs(v5))/v5/v6.conjugate()*QQbar(I)
v9 = abs(v8)
v10 = abs(v7)
v11 = (v7 - v8 + QQbar(v9*v9)*v7 - QQbar(v10*v10)*v8)/\
(v8.conjugate()*v7 - v7.conjugate()*v8)
v12 = (v11*QQbar(I) - QQbar(-I)*v11.conjugate())/2/QQbar(I)
v13 = abs(v12)
v14 = QQbar(1 - sqrt(1 - 1/(v13*v13)))*v12
time real(v14)
In Sage 4.3 I get the output:
Exception TypeError: TypeError('Unable to convert number to real
interval.',) in 'sage.symbolic.pynac.py_is_real' ignored
CPU times: user 67.94 s, sys: 0.30 s, total: 68.23 s
Wall time: 68.68 s
-0.5773508481209188?
In Sage 4.2.1 on the same computer I get the output:
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
-0.5773508481209188?
Should this be considered a bug?
/Håkan
John Cremona
Incidentally, if you insert I=QQbar(I) at the top then you should
not need most of the subsequent explicit QQbar() calls:
sage: I=QQbar(I)
sage: v1 = sqrt(QQbar(3))
sage: v2 = 999/1000*I
sage: v3 = (1 + v1)/2 + v2*(-3 - v1)/2
sage: v4 = (3 - v1)/2 + v2*(1 - v1)/2
sage: v5 = v3*(1/2) + v4*(500/999*I)
sage: v6 = v3*(1/2) + v4*(-500/999*I)
sage: v7 = -(v5/v6).conjugate() - (v5.abs())/v5/v6.conjugate()*I
sage: v8 = -(v5/v6).conjugate() + (v5.abs())/v5/v6.conjugate()*I
sage: v9 = v8.abs()
sage: v10 = v7.abs()
sage: v11 = (v7 - v8 + (v9*v9)*v7 - (v10*v10)*v8)/ (v8.conjugate()*v7
- v7.conjugate()*v8)
sage: v12 = (v11*I - (-I)*v11.conjugate())/2/I
sage: v13 = v12.abs()
sage: v14 = (1 - (1 - 1/(v13*v13)).sqrt())*v12
sage: time v14.real()
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
-0.5773508481209188?
This also caused the error message to go away. Note that in your code
I was a symbolic object, so you were mixing symbolic and algebraic
objects in an unnecessary (and probably inefficient) way.
John
2010/1/5 Håkan Granath <hakan....@googlemail.com>:
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Håkan Granath
It seems to boil down to that real(v14) is slow and shows the
Exception, whereas v14.real() is instant and gives no error. I would
have thought them to be equivalent.
/Håkan
John Cremona
I think it's always best to use the form a.real() (and similarly
a.sqrt(), a.conjugate() etc) even if the functional version real(a),
(etc) works since python has to do less work finding the appropriate
function to apply.
Looking at real?? I see that it does not appear to (as I would have
expected) first try self.real() and then do something else if that
fails. The docstring you see with real?? is th documentation for
class Function_real_part(GinacFunction).
Does anyone know why real(x) does not call x.real() when that exists?
John