Rather subtle problem with ordergreat+letsimp

C Y wrote:

>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. 
>

One way to approach this is to have all expressions that are units 
expressions have a wrapper
like units(.....).  Then without changing anything else in display, you 
can use a data-directed addition
to displa  (and nformat) to   format and display  unit expressions.  
These additions could be
in a separate file. 

> 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.
>
It would not be so much re-defining as augmenting,  if the only display 
objects affected are
explicitly tagged as units.

>
>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? 
>
nformat  is, I think, used by part. (not inpart, which uses internal 
forms).   part would see
the terms grouped exactly as nformat groups them.

> 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.
>
if nformat separates these things properly, you should have  part  
working properly.

>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.
>

there is a distinction between the commands part and inpart.  note that 
the internal version
of a/b  is more like a*b^(-1)   and so already the internal form does 
not reflect the
part-selection operations.

>
>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 think you should probably not use ordergreat for units if it causes 
such problems.
That's just a guess though.

>
>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.
>
nformat.

>  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.
>
already there, in essence. In 1967 we didn't know the phrase "object 
oriented" but the
idea was used.  Operators have display properties and know how to 
display themselves.

> But any CLOS stuff would be a
>major rework and waaaay down the road.
>  
>
It would not be a priority for me, either.  But some people want to hack 
UI stuff
and don't know enough math to do anything else.

RJF

>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 
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>  
>