Wouldn't it be easier and more robust to write
"clever" functions to set / remove properties on a symbol?
I suppose we could redefine putprop/defprop before any other packages are
loaded. Or we could go through the source code and change every instance
of putprop/defprop to mxputprop etc. Need to be careful about the
non-symbol case of putprop (not sure if Maxima uses it).
Though just going through all the property lists after everything else is
loaded and moving operators to the beginning seems simpler and perfectly
robust. This is, after all, just a performance hack and if some new
properties are added later before the operator property, it's no big deal.
-s
On Sun, Aug 5, 2012 at 2:10 PM, Rupert Swarbrick <rswarbrick at gmail.com>wrote:
> Richard Fateman <fateman at eecs.berkeley.edu> writes:
> > 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.)
>
> A quick question: Wouldn't it be easier and more robust to write
> "clever" functions to set / remove properties on a symbol? We could have
> a chosen order (with operators first) and the clever setter would ensure
> that the property was set in the right order. My logic is that setting
> and removing properties probably doesn't have to be fast. This would, of
> course, remove the need for an extra build step.
>
> Also, notice that:
>
> CL-USER> (symbol-plist 'foo)
> NIL
> CL-USER> (setf (get 'foo 'a) 1)
> 1
> CL-USER> (setf (get 'foo 'b) 1)
> 1
> CL-USER> (symbol-plist 'foo)
> (B 1 A 1)
>
> As such, even if the build system reordered the property lists, they
> would still be messed up the first time someone ran share/ code that set
> properties on some symbols.
>
>
> Rupert
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>