On Nov 2, 12:36 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 2, 2008 at 12:24 PM, mabshoff <[EMAIL PROTECTED]> wrote:
<SNIP>
> > 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
>
> It's not only pexpect. It's that maxima via clisp is itself very slow.
Sure, for example factorization and linear algebra aren't exactly fast
with sbcl either, but there are certainly useful and some times very
complex algorithms implemented in Maxima. Way back it was the right
decision to use Maxima to get up to speed quickly, but as is many
people would claim that for limits or integration it cannot compete
with either MMA or Maple, hence the drive to do our own
implementations starting from the bottom up.
> > 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.
>
> I hope I'm wrong!
Well, when I am looking at two potential software packages for
inclusion in Sage doing the same thing I always would prefer the
library solution even if it means more work. pexpect in the long term
is just a crutch for something that could be linked in as a library.
<SNIP>
> >> 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 :)
>
> Thanks for the clarification. Now I remember what you're talking about.
Good :). Note that the reason to use the calculus imports was that the
double precision version used previously was insufficient due to too
little precision. Right now we should be using mpfr versions of those
functions which are plenty fast and exact on all platforms :)
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
-~----------~----~----~----~------~----~------~--~---
