Rather subtle problem with ordergreat+letsimp

That would in fact be my preferred long term solution, but it has
several drawbacks:

1)  It would involve a change or update (or minimally redefinition by
the unit package) of a core Maxima function.  I've already got
post_eval_functions in the queue, and I'm still rather overwhelmed by
the sheer complexity of the eval process so finding all the gotchas
that can be caused by working at that level is a bit daunting. 
(ordergreat+letsimp is a case in point.) Perhaps I should create a
units.lisp file with all necessary redefinitions in there, have
units.mac load that, and remove them as any changes deemed desirable
are incorporated into Maxima proper. As a design principle I still
think it is a Bad Idea to have share packages redefining core
functions, but perhaps I'm being overly paranoid.

2)  If I have things displayed in the fashion a*b, where a is the
grouping of non-unit terms and b is the grouping of unit terms, would a
resort at the displa level allow, say, part to access a and b?  If not
this would in effect break the expected behavior of part from the
user's point of view, which I prefer not to do if possible. 
Unfortunately, I have no idea what would need to be changed to make
this happen - the a*(b/c) -> (a*b)/c simplification seems to be well
buried (perhaps repeatedly performed) over the course of an evaluation,
and that may not be the only transformation that could cause problems.
I would like not just the on-screen display but the internal form to
reflect this organization so things like part selection work - if it is
going to be done at all it should be done correctly.

3)  In general, it seems rather difficult to determine at what point in
an eval process things change. Clearly when ordergreat is set the
character of user entered units changes, but those already defined in
arrays are not transformed for the purposes of evaluation.  Is this
expected?  is it desirable?  If there is a better way than great to
achieve my purpose here I'd prefer to use it, but it might be
considered a bug in ordergreat.

I know about displa for actual display - presumably the place to sort
an expression into a "final" non-simplified form for display only is
either inside displa or just before it, but I have no idea where to
look if it IS before displa.  I might be able to trace my way back
eventually, and if that's what I need to do I will, but ick.  Would you
(or anybody) happen to know how that part of the tail end of things
works?

I can't help but wonder if CLOS might be useful somehow in all this -
if variables and expressions were CLOS objects one might be able to 
define different display sorting methods and be able to set the
preferred one for a particular object. But any CLOS stuff would be a
major rework and waaaay down the road.

CY

--- Richard Fateman  wrote:
> I haven't been following this too closely, but if the issue
> is a display issue, why not write a program, presumably a
> modification of "displa", that separates out the units and
> displays them the right way.  You could even invoke this program
> automatically from the normal display program when the data is
> tagged in some way, e.g.
> 
> R: units_expression( 66 *feet/second);
> 
>      66`fps   or    whatever you want.
> 
> 
> RJF
> 
> C Y wrote:
> 
> > Hi all.  I have attempted to use ordergreat to get Maxima to
> display
> > units  at the end of an expression, but it turns out there is a
> problem
> > with this.  In the user session, it manifests itself as an apparent
> > .....
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail