--- Robert Dodier wrote:
> Hello all, a few random comments on Cliff's recent message.
> Many thanks to Cliff for his work on this topic.
Actually, Barton has done most of the heavy lifting. Thanks should be
directed his way :-).
> > Hmm. OK. I take it there isn't a convenient list of lisp level
> > funcitions that have been "Maximaized"?. That should probably be
> > its own section in the Programming chapter.
>
> Agreed that such a list would be very useful. Cliff, maybe
> you want to file a bug report and assign it the "documentation"
> category so that this item isn't forgotten?
That's a good idea. OK, bug entered.
> > Actually, we decided to deliberately make the finalevallist a
> > non-maxima list in order to provide for the possibility of
> > preventing the user from assigning stupid stuff to the list.
>
> Um, I have to say I'm not in favor of this -- preventing
> stupidity by the user often has the side effect of preventing
> cleverness as well... If nothing else, making this list a
> Lisp list instead of a Maxima list means it cannot be
> conveniently inspected. If we're going to provide this
> feature, I just don't see a motivation for making it
> more cumbersome than necessary.
Barton has implimented a more complete version of this function which
has the option to "show" the current state of the list. This can be
done multiple ways - I don't know which one is "best". At some level
it's a fairly minor point, I think - this is after all a programmer
level function. Normal user use of this feature won't be encouraged,
there's just too much potential for trouble and normally it isn't
needed. Here is the Barton's latest version (just fyi we all agree a
better name is needed):
(defun $finaleval(x &rest f)
(cond ((eq x '$show) (displa (cons `(mlist) *finalevallist*)))
((or (eq x '$append) (eq x '$create))
(cond ((every #'symbolp f)
(if (eq x '$create) (setq *finalevallist* nil))
(setq f (reverse f))
(dolist (fi f)
(if (symbolp fi) (push fi *finalevallist*))))
(t (merror "The second and all subsequent arguments to
'finaleval'
must be symbols"))))
((eq x '$delete)
(dolist (fi f) (setq *finalevallist* (delete fi *finalevallist*))))
(t (merror ("First argument must be 'append', 'create', 'delete' or
'show'. ~%"))))
'$done)
(%i2) finaleval('show);
[]
(%o2) DONE
(%i3) finaleval('create,a,b,c)$
(%i4) finaleval('show)$
[a,b,c]
(%i5) finaleval('delete,b,c)$
(%i6) finaleval('show)$
[a]
An error doesn't change *finalevallist*
(%i7) finaleval('append,p About the name --
>
> > Perhaps lastsimp would be better?
>
> How about tellsimplast ? Then it is in a group (conceptually)
> with tellsimp and tellsimpafter. The corresponding front-end
> simplification function would be tellsimpfirst, I guess.
Maybe, but there again that would suggest it is a user level feature -
I don't think the need for this will be too strong.
Barton came up with post-eval-modify, which I like.
> > It [tellsimpafter] seems to insist on looking at
> > subexpressions, which for certain unit situations
> > doesn't work at all.
>
> From studying some tellsimpafter examples, it appears
> that tellsimpafter works bottom up, so it starts with
> subexpressions and ends with the entire expression.
> Perhaps this sheds some light on simplifying top-down --
> is there a way to determine if some expression is a
> subexpression? (Unlikely, I suppose.) Or maybe we can
> consider changing bottom-up to top-down?
I don't think we need to - if this proposed mechanism is acceptable
that should remove the need for tellsimp hacking. I am not at all
eager to mess with tellsimp and friends for a number of reasons, not
the least of which is some rather intimidating code and very limited
commenting.
> Cliff, maybe you can clarify which kinds of units
> simplifications seem problematic. I naively suppose that
> if there is a canonical simplification, it wouldn't matter
> if some detour were made on the way up the expression tree
> -- eventually the whole expression is reached. But
> apparently that doesn't describe what's happening here.
> Can you fill us in?
The problem arises when one wants to find derived units in an
expression. The way the units pacakge works, all incoming units are
rendered down into their MKS fundamentals. Then, letsimp with
letrat:true looks for the MKS equilivents of the desired derived units,
and substitutes in factor*newunit, where factor is 1 for MKS units.
Then, any remaining base units are converted. The problem with the
tellsimpafter routines is that for, say, kg*m/s^2 tellsimpafter will
apply all simp routines to kg*m, then proceed. If it applies the final
MKS->final conversion of base quantities on kg*m before considering
kg*m/s^2, the form it will recognize as 1000*dyne (assuming the user
has chosen dyne) is destroyed by the first round of substitution. This
will not appear if the desired output units are all MKS, but that
cannot be depended on. There may be workarounds, but I think it is a
lot less hackish and easier to maintain to simply allow the letsimp
commands to be executed in proper order by some version of
post-eval-modify.
CY
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/