Subject: Simplifications of 3*sqrt(2)/sqrt(3)/sqrt(6)
From: Stavros Macrakis
Date: Fri, 3 Jul 2009 16:09:26 -0400
On Fri, Jul 3, 2009 at 3:56 PM, Dieter Kaiser <drdieterkaiser at web.de> wrote:
> Am Freitag, den 03.07.2009, 14:55 -0400 schrieb Stavros Macrakis:
> > On Fri, Jul 3, 2009 at 1:48 PM, Robert Dodier
> > <robert.dodier at gmail.com> wrote:
> > > And I think always calling factor for these cases may not be
> > such a good
> > > idea. What if the number is the product of two fairly large
> > primes or
> > > even a prime? Maxima will spend a lot of time trying to
> > find the factors.
> >
> >
> > I don't have a very strong opinion about it, but I am leaning
> > towards
> > omitting the call to factor from simplification, and moving it
> > into
> > radcan or something like that, on the general theory that we
> > should
> > try to avoid potentially expensive operations in
> > simplification
> >
> > I agree that general simplification limit the amount of time it takes
> > on integer factorization, and that an explicit command (e.g. radcan)
> > should be called for larger cases.
> >
> > Here's how I'd limit it... suppose we think of a 'largish Maxima
> > calculation' as involving 1000 factorizations (that's a lot), and we
> > don't want more than say 10 seconds of CPU to be spent on
> > factorization for this simplification. Then we have a budget of about
> > 10mS per factorization, which on my machine would allow integers up to
> > about 10^13. This is a worst-case analysis, but 10^13 should in any
> > case be adequate for most work.
>
> The factorization of integers which are a base of an exponentiation is
> already done in the Maxima routine simpnrt. The algorithm in simpnrt
> does the factorization only on a base of the list of small prime numbers
> up to 10000.
>
Yes, what I was suggesting was that with current CPU speeds (> 3 orders of
magnitude faster than the original Macsyma PDP-10), the number could be
greatly increased.
> Therefore, I have proposed the same scheme to factorize integers in TMS.
> We only loose computation time, because some work is doubled. The reason
> is, that simpnrt has already all factors by hand, but does not use these
> factors completely. This could be improved, if we agree about the
> usefulness of simplification like the expression
> 3*sqrt(2)/sqrt(3)/sqrt(6) --> 1.
>
This sort of case needs no factorization at all, just GCD.
> The function $factor will not work in general for big numbers. Try e.g.
> factor(prev_prime(100!)*prev_prime(200!)). After a long time I have got
> a Lisp Error.
>
Not sure why we're discussing the $factor function at all in this thread....
-s