Something unfortunate has happened to properties, and it could be easily
fixed. (Again)
How much it would speed things up is not clear, but let's take the
example of the
sine operator, %sin.
The most important property, at least in terms of time-critical access,
is probably
the "operators" property, which determines which program to call to
simplify it.
This property is accessed whenever a sub-tree with %sin at its head is
simplified.
It is currently the 14th entry on the property list of %sin. and hence
28 memory accesses
following a linked list must be followed to reach it. This is done each
time %sin is
simplified.
For "+" (that is, mplus), the simplification program is found by
following 30 links.
(Though this may be short-circuited often by simplifya and simplus.)
There USED to be a program run just before dumping out a lisp image that
took the
operators property and put it in the front of the property list.
It seems that it is either not there, or no longer run.
The properties that are fastest to access appear to be related to TeX
typsetting.
To see the list, do :lisp (symbol-plist '%sin)
I suggest that this rearrangement of the property lists of important
symbols be
put back in the stream of activities setting up the image.
It could be that the test suite will not run significantly faster after
this change, but
then I am fairly sure that the implicit weighting of functionality in
the test suite
is mostly irrelevant to long-running symbolic calculations. I think the
test suite
is like a umpteen-point checkup given to used car: yep, there's water
in the
windshield washer, yep, there's air in the spare tire, yep, the ashtray
is empty...
It doesn't deal with the analogous issue of (say) gas mileage.
As for whether the property list of a symbol or some other place (like the
symbol-function slot) should be used for storing information, it is not
clear what the advantages would be here, but placing information at the
end of a list of 44 items does not strike me as a great idea. I do expect
that a small hashtable would be SLOWER than a short property list, where
"short" would have to be determined by timing tests. (guess: short is <20,
but depends on memory speed, locality, caches etc.)
RJF
On 8/5/2012 9:16 AM, Robert Dodier wrote:
> On 2012-08-04, Raymond Toy <toy.raymond at gmail.com> wrote:
>
>> Neat. Looks like an error in the mapc at line 167. Change "simperf" to
>> "simp-erf".
> Cutting out the superfluous simplification property for %ERF seems to
> fix the problem. I've pushed that change.
>
>> Don't know why the mapc is there, though. Maybe the lambda
>> form should check to see if the 'operators property is already set and
>> do nothing? Didn't investigate that, though.
> I think the code should put the simplification property in the same
> place as the function definition. That would help avoid the problem
> which we ran into here (function changed, property assigned at location
> of new function, previous, now-incorrect property not updated).
>
> The properties assigned in the MAPC are now correct, although some might
> be superfluous, and some should be moved out of src/simp.lisp.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima