PART+, was: Re: [Maxima] Yet another units package

--- Richard Fateman  wrote:

> I wrote matrun etc about 35 years ago. I don't know it
> has been rewritten  (I heard claims that Macsyma Inc rewrote
> pieces), but I think the Maxima code is pretty much what I
> wrote.  Note that Lisp in the 1960's was less sophisticated
> than now.  But I think I can express the intention.
> That is, a pattern that looks like a sum, without any further 
> qualifications, is a bad idea. A pattern like a*x^2+b is OK, 
> if x is not a pattern variable, because it is qualified.
> The generated program looks for the coefficient of x^2 and names it 
> a. The sum of everything else is named b.  {subject to predicates..}

I'm glad to see this explicitly stated, because I had a hunch it was
something like that - the available matching functionality is
deliberately kept with certain limits.  It felt to me like we kept
trying to get tellsimpafter to do things it really didn't want to do -
perhaps my intuition was worth something after all.

> A pattern like a+b does NOT try all possible partitions.
> I believe that it picks one item for a. Everything else is grouped
> as b. This is not because the author was ignorant of re-partitioning
> possibilities, but because the author knew that such searches could 
> be expensive. E.g. the matcher in Mathematica can be given tasks 
> that take exponential time in the length of the input. The hope was 
> to keep the matcher fast enough so that it would be useful for 
> simplifier hacking.

So tellsimp and tellsimpafter are focused on cases where the author or
user is looking to impliment a simplification and wants to be sure the
time involved will remain reasonable?  This makes sense, but should be
explicitly discussed in all aspects of tellsimp documentation, because
the impression I had was that tellsimp was the one and only general
simplification method for Maxima.  From what your saying it sounds like
it should be the first and primary choice, but I at least would like to
have the option of stepping into more risky (in the sense of
time/processor expensive) matchings as well.

> Why was this choice made for the macsyma matcher?  Because the other
> kind of match was already programmed in macsyma, in the program
> "schatchen" written by Joel Moses.  (Schatchen is Yiddish for
> "matchmaker"). The program is in the SIN or SININT file, and is, I 
> think, called M1.

This is very good to know.  I was unaware of this second matcher.  Is
there documentation for it anywhere?

> If you want a top-level matcher that looks more like Mathematica's I
> suppose this could be put together by putting together calls to M1, 
> suitably clothed in various ways.  Or the MockMMA matcher could be 
> moved to Maxima. Or for the specific case you could write a program 
> that looks for a sum  (i.e. inpart(E,0)="+") and then picks out the 
> terms and disposes of them in whatever way you had in mind.

Adding user level M1 simplification tools, and/or importing the MocMMA
parser, sound to me like very good ideas.  Making use of PART was in
essence what I intended to do for the unit package (or rather a
variation on that theme).  I think it would be a good idea to offer
both save and potentially expensive options for simplification to the
user, because there may be some cases where the user is willing to
accept the longer run time to get the form they want.  Or the
expectation is that in all real world cases the simplification will be
rapid, and the expensive cases are sufficiently unlikely that the
programmer prefers to run the risk and get the additional functionality
in the (more common) basic cases.

CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com