On 09/06/2013 01:09 AM, Stavros Macrakis wrote:
> I assume you're talking about something like this:
>
> %solve([sin(x)],[x]) => %union([x=%pi*%z11])
>
> where %z11 is declared as an integer and therefore added to the
'props' list.
Not only that:
(%i3) %solve(abs(x)=1,x);
(%o3) %union([x = - 1], [x = 1])
(%i4) props;
(%o4) [ ... , %c1]
The user doesn't know that %c1 has been created.
(%i5) %solve(sin(x)=0,x);
(%o5) %union([x = %pi %z7])
(%i6) props;
(%o6) [ ... , %c1, %z7, %c8]
(%i7) nicedummies(%o5);
(%o7) %union([x = %pi %z0])
(%i8) props;
(%o8) [ ... , %c1, %z7, %c8, %z0]
More unseen temporary variables.
> I don't think it is correct to kill the integer property of %z11 until
any expressions involving it are inaccessible. In general, the only way
you can know that is after a kill(all).
The intermediate variables should be removed, but I'm not suggesting
that %z0, etc. should be removed behind the user's back. I have a
function to_poly_clean() that can be used whenever it's convenient.
>
> I am surprised that leaving %z11 etc. around doubles the runtime of
the test suite each time you run it. I wonder if you can narrow down the
slowdown problem to some specific operation(s)?
Well not yet. Maybe something is doing a linear search of lists such as
props.
... or maybe nicedummies slows down
(%i2) length(props);
(%o2) 54
Running tests takes 19 s
length(props) --> 670
Running tests takes 35 s
length(props) --> 1256
Running tests takes 50 s
length(props) --> 1842
Running tests takes 88 s
length(props) --> 2428
This example is rather artificial, but there could be other
applications, where temporary variables pile up quickly.
If I kill all temporary variables after each test, then the testsuite
runs first in 15 s and every time after in about 11 s. This actually
varies a bit.
I modified new-gentemp to record each variable as it is created. Then,
the user can call to_poly_clean() to remove them all at once. I use a
hash table, but just pushing them on a list and then calling kill on the
list might be simpler. Anyway, that is not as important as the temporary
variables that the user can't see.
--John
>
> -s
>
>
>
> On Thu, Sep 5, 2013 at 6:32 PM, John Lapeyre
<lapeyre.math122a at gmail.com> wrote:
>
> Greetings,
>
> I notice that to_poly_solve generates temporary variables that can
> slow things down. I started writing something to remove them, but
> before I go further: Is there a facility to deal with this that I am
> missing ?
>
> For instance before running the testsuite, length(props) is 12.
> After running it, length(props) is 652.
>
> I notice it especially since I reorganized to_poly_solve to survive
> kill(all). When I rerun the tests without cleaning the temporary
> variables and without calling `kill', the time required doubles each
> time. On the other hand, if I remove the temporary variables during
> the tests, the time to run the tests is reduced and remains constant
> with repeated runs of the test suite.
>
> This is what I have, but it does not catch all the temporary
> variables. nicedummies adds more variables to props that I don't
> remove.
>
> https://github.com/jlapeyre/mext/blob/master/tpsolve/to_poly.lisp
>
> btw. The alias to %solve, makes dealing with the code very tedious
> and difficult... Maybe there are tricks I don't know about.
>
> HTH,
> John
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>