# [Maxima] Simplifications of 3*sqrt(2)/sqrt(3)/sqrt(6)

Stavros Macrakis macrakis at alum.mit.edu
Fri Jul 3 15:09:26 CDT 2009

```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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.math.utexas.edu/pipermail/maxima/attachments/20090703/d07bdac0/attachment.htm
```