Am Montag, den 15.03.2010, 16:36 -0700 schrieb Richard Fateman:
> Since $orderlessp and $ordergreatp are probably used rarely, that would
> be the logical place to put them.
>
> Changing great is like putting an extra check in an inner loop. A bad idea.
>
> I feel strongly about this because I personally spent several weeks
> trying to make "great" run faster, in
> the original Macsyma design, and spent several weeks at other times
> trying to figure out how to make
> it less necessary to call great. With some success. Dodier in
> particular has resisted installing these patches,
> though I must admit I have not pressed him on it, since whoever installs
> them would have to deal with the
> possibility of very subtle bugs and even slow-downs (on small expressions).
>
> note that simplus has a loop which effectively does a sort, using great,
> that is not only n^2, it is probably n^3 or worse,
> when it could be n*log(n).
> Same for simptimes.
>
> Why?
> 1. it uses a naive insertion sort. using lists not arrays.
> 2. it repeatedly compares items recursively whose order is already known.
>
> While checking to see if something is (say) in CRE form or not is only a
> small cost, it is in an inner loop of the simplifier.
>
> If by chance there is a CRE form, say F, something terrible may happen...
>
> say that doing totaldisrep(F) costs 1 second, because F is very complicated.
> Now add F to an expression of length n. The addition might cost n
> seconds, because each time
> great is called, and it may be done n times, totaldisrep is called again.
>
> One way around this is if you remember the totaldisrep value. maybe
> store it here ((mrat simp varlist genvars ***totaldisrepvalue***) .... )
> by some destructive operation. This might be hazardous.
>
> Also note that simplus and simptimes need not sort ANYTHING, but simply
> hash to match things up.
> Thus plus and times do not need to call great at all, unless there
> is some other operation that needs the order. Like printing.
>
> Poisson series are, I think, not used by anyone. Which is probably a
> good thing, because when I last looked, they were
> installed incorrectly.
> There are 2 versions, and you are supposed to choose which one to load.
> Instead, they are both loaded, one on top of the other.
> (I wrote these packages..)
>
> The original (and still operational!) version of loading up a Maxima
> system was done by running a lisp program which loaded up
> the files and then dumped out the binary system. It was set up so that
> one or the other Poisson system was loaded. This subtlety
> was, I think lost when "make" was used. Make is perhaps inevitable
> because parts of Maxima are not in lisp: plotting and wxmaxima
> for example. But it looks to me like way too much of the setup has been
> moved out of lisp, and requires tools that are perilous.
> See how much of the system setup has to be revised when a new version
> comes out.
Hello Richard,
meanwhile I have done some statistic for great. I was to optimistic. It
is not possible to avoid a lot of unnecessary calls to specrepchecks. I
have counted 8,243,414 calls of great form the testsuite. At least I
have needed 5,108,140 calls of specrepcheck to get a total order which
includes the special representations. That seems to me too much.
Furthermore, I have learned that it is easy to break something when
putting a specrepcheck at the wrong place.
As mentioned earlier we can replace in $orderlessp and $ordergreatp the
calls of specrepcheck with $totaldisrep and ignore the issue with the
Poisson representation.
This can be easy done, does not change much and we can close the bug
report.
Dieter Kaiser