From: Arthur N. <ac...@ca...> - 2011-08-23 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), 10-Aug-11 ... 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 |
From: Rainer S. <rai...@gm...> - 2011-08-23 17:19:52
|
On Tue, 23 Aug 2011 at 17:15 +0100, Arthur Norman wrote: > 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))) In poly.tst I see ((((equal . 1) . 1) ((plus . 1) . -1)) . 1) This comes from the following line in the procedure testdecompose: if 'equal = part(p,0) then part(p,0) returns the symbol plus, and the comparison in algebraic mode is implemented by simplifying the difference of equal and plus and comparing the result to 0. crack/crsimpso.red contains similar code, ie. if part(n,0)='MINUS then cs1:=t which would give the one you quote. It all comes down to howto handle this comparison in algebraic mode. Should this particular case (one argument of equal being a quoted symbol) really be done as comparing simp '(difference equal plus) to zero, or rather as evaluating (equal 'equal 'plus) One way to achieve the latter would be to a) flag('(quote),'nochange) so that "(quote equal)" doesn't become "(aeval!* (quote equal))". (Isn't the noform flag meant to achieve this?) b) modify formbool as (not sure that's correct!) symbolic procedure evalequal(u,v); %%% First handle case of quoted symbol(s) if idp u or idp v then u eq v else begin scalar x; return if (x := getrtype u) neq getrtype v then nil else if null x then numberp(x := reval list('difference,u,v)) and zerop x else u=v end; Rainer |