On 09/06/2013 03:59 AM, Barton Willis wrote:
> The function new_variable gives each symbol it creates a symbol
property. I think it would be possible to examine
> each member of the output of props for these symbol properties. Maybe
something like
> Let me guess that the author of the fact database was aiming for
> 10s, not 100s, of entries. Likely the fact database is big oh
> challenged.
That was also my best guess. Furthermore, it's possible that the fact
database was designed on a lisp with neither arrays nor hashtables.
The solution I am playing with, which mostly works (it is not killing
a few temp variables) is:
Define record-gentemp, and then in new-gentemp, add lines like this
after creating each type of temporary variable to store it in a
database (hashtable, but it could be a list)
(record-gentemp g '$integer))
Then the function to clean them does what your code did, but also
calls unintern...
But there is still the fact that
(%i3) %solve(abs(x)=1,x);
(%o3) %union([x = - 1], [x = 1])
puts %c1 in the facts database, but the user doesn't know this. Am I
correct in thinking that these could safely be removed without affecting
what the user might later do with the solution ?
An example of a potential problem: A user might do something like the
following, with some plotting or something in addition.
(%i3) length(props);
(%o3) 54
(%i4) for x:1.0 step .01 thru 5 do float(%solve(abs(y)=x,y));
Evaluation took 5.9200 seconds (5.9090 elapsed) using 743.375 MB.
(%i5) length(props);
(%o5) 455
Restart, and this time call to_poly_clean after each solve.
(%i3) length(props);
(%o3) 54
(%i4) for x:1.0 step .01 thru 5 do
(float(%solve(abs(y)=x,y)),to_poly_clean());
Evaluation took 5.9000 seconds (5.8920 elapsed) using 743.622 MB.
(%i5) length(props);
(%o5) 54
So, in the former case, the facts database blows up, but solving does
not get slower compared to the latter. It looks like it is not
necessarily to_poly_solve itself that gets slower in the rtests; maybe
its nicedummies, or solving a different kind of equation that slows
the tests.
> Incidently: Likely the simplification rules associated with a %union
object, the symbol properties of new variables, and
> the altered environment are all lost when Sage uses to_poly_solve and
exits Maxima. Maybe Sage has its own solver now.
>
interesting, I wish I knew more about that.
By the way, I now have packaged alt_eigen and to_poly_solve in
a way that survives kill(all).
--John