On Nov 2, 12:07 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 2, 2008 at 11:46 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > On Nov 2, 11:38 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> >> On Sun, Nov 2, 2008 at 3:10 AM, Wilfried_Huss
>
> > Hi,
>
> >> <[EMAIL PROTECTED]> wrote:
>
> >> > Hi,
>
> >> > I have written some code for the Maxima interface.
> >> > You can find the patches at:
> >> > http://www.math.tugraz.at/~huss/sage
>
> >> > calculus1.patch implements the conversion from Maxima
> >> > matrices to Sage matrices.
>
> > This should come in handy, but starting with 3.2 we will finally have
> > pynac available for some of the basic symbolic manipulation tasks. It
> > is far from bullet proof, but it is a start, so the days of Maxima as
> > the default implementation of the low level symbolic stuff is coming
> > finally to an end :)
>
> And I think we still want to have as many conversions between
> Maxima and Sage as possible, even if Maxima isn't the default
> backend for symbolic manipulation. It's still very good for
> Maxima and Sage to be able to communicate. The more
> capabilities for communication between Sage and other systems,
> the better.
Yes, I do not disagree, but I would much rather see fundamental
functionality directly implemented in Sage than to use Maxima for say
the generation of a Vandermonde matrix. Sooner or later someone will
complain about the performance when it is generated in Maxima since
due to pexpect it can never approach native speed implementations for
something where the overhead to computational ratio is so bad. That
obviously applies to any system that has to communicate via pexpect
for licensing or technical reasons, i.e. GAP, Axiom, Magma and so on,
but computations where the communication overhead is tiny compared to
the computational effort the pexpect overhead is negligible can employ
pexpect without too much of a penalty. William and I disagree on this
point, but in 10 years I see very little non-optional functionality in
Sage provided via pexpect since someone in the Sage project will
either have implemented the functionality natively or the project we
are using has been library-fied some way.
> >> > calculus2.patch adds symbolic gamma and factorial functions.
> >> > (The factorial is named fact() so it doesn't clash with the
> >> > factorial in sage.rings.arith)
>
> > Provided the factorial bit does not interfere with the current non-
> > symbolic code this could be useful.
>
> +1
>
>
>
> >> > Finally calculus3.patch renames the symbolic factorial to factorial(),
> >> > and changes all imports of sage.rings.arith.factorial to
> >> > sage.calculus.calculus.factorial. I had to keep a renamed version
> >> > of the factorial function in sage.rings.arith to avoid circular
> >> > imports at startup.
>
> > I don't like this patch at all since it forces us to use a Maxima
> > function even for integers which ought to be the most common use of
> > factorial.
>
> I didn't look at the patch, but just want to comment that using
> sage.calculus.calculus.factorial instead of sage.rings.arith.factorial
> doesn't a priori imply that Maxima is used to compute factorials.
> I.e., I could imagine an implementation where GMP is still used
> for this:
>
> sage: time n = factorial(10^6)
> CPU times: user 1.90 s, sys: 0.10 s, total: 2.00 s
Yes, factorial should try to use gmp in case the argument can be
coerced into an Integer and should that fail have pynac/Maxima have a
go at it.
> > When the point counting code was using Maxima to compute
> > ceil, floor and sqrt the code as a whole was slower by a factor of
> > three which illustrates nicely why we don't want to use Maxima unless
>
> Do you really mean "three orders of magnitude", i.e., a factor of 1000? :-)
The doctest jumped from about 250 seconds to 800 just by using ceil,
floor and sqrt from calculus. And those values were only used to
determine some thresholds for the computation and barely used any
significant time in to algorithm. But using the calculus functionality
instantly I noticed that performance went to shit, so I complained
about it and ceil, floor and sqrt in that code are no longer imported
from calculus :)
> > there is a good reason to do so. Especially considering that using
> > mpfr's functions was abotu a million times faster since there is no
> > pexpect overhead. I could see using that code in case the argument is
> > non-integer, but not using the highly optimized gmp implementation for
> > something that is many orders of magnitude slower is just not what we
> > want to do.
>
> If a ticket is posted with the third patch, the reviewer should just make
> sure that factorial(n) for input an integer (1) doesn't slow down, and (2)
> returns an integer.
+1
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
