From: Arthur Norman <acn1@ca...>  20110823 16:15:58

The existing code for prepf reads symbolic procedure prepf u; (if null x then 0 else replus x) where x=prepf1(u,nil); symbolic procedure prepf1(u,v); if null u then nil else if domainp u then list retimes(prepd u . exchk v) else nconc!*(prepf1(lc u,if mvar u eq 'k!* then v else lpow u . v), prepf1(red u,v)); when replus calls unplus and so scans all down the created list. I was concerned that the calls to nconc might lead to a worst then linear time cost so attempted a rewrite as roughly symbolic procedure prepf1(u, v); reversip prepf1_reversed(u, v, nil); symbolic procedure prepf1_reversed(u, v, r); begin top: if null u then return r else if domainp u then return (retimes(prepd u . exchk v) . r); r := prepf1_reversed(lc u, if mvar u eq 'k!* then v else lpow u . v, r); u := red u; go to top end; Then I tried to merge the unplus stuff into the above. That reveals cases where "plus" and "minus" end up used as names of variable with really odd effects. At top level you can go: Reduce (Free PSL version), 10Aug11 ... 1: a := part(x+y, 0); b := part(y, 0); a+b; ws^2; a := plus b := minus minus <<< !!!!!! 2 2 minus + 2*minus*plus + plus I observe that prepf/unplus gets called on things with "plus" as a variable in at least poly.tst and liepde.tst... I am minded to alter the behaviour of prepf so as not to strip "plus" so enthusiastically, but since that is incompatible I though I should see what views others have first. And if anybody understands whether poly.tst of liepde.tst OUGHT to have things like (((minus . 1) . 1) ((plus . 1) . 1))) as standard forms that get passed to prepf (and hence get damaged  that case seems to end up as (plus (minus minus)) where the (plus..) wrapped around it looks to be against what replus/unplus want to do, and the discarded plus is surely just plain wrong. Arthur 