Mock-up html manual page



I'm not proposing to remove the EV command.  It is just that
some simple uses of it, say to replace x by 3,  done by
ev(expression, x=3)

or
   expression, x=3

are probably more clearly thought of, and computed as, substitutions.


ev(expression, somethingflag=true)    is not a substitution, but
as you say, sometehing having to do with an environment.

Every system makes a hash of this.  Rules in Mathematica,
random flags in Maple and Macsyma.


RJf
C Y wrote:

> --- Richard Fateman  wrote:
> 
> 
>>I also suggest that we might add, in the documentation, notes that
>>give some advice, like "This command exists for compatibility with
> 
> old
> 
>>programs. We suggest you use .....  for new programs. {e.g. ev vs.
>>subst}" or "Some people expect this command to do ... but this is not
>>its objective.  {e.g. factor}"
> 
> 
> I guess in my still-newbie mind I still find it a bit odd that subst is
> a replacement for ev.  I guess I really shouldn't, but if we are really
> going to do away with ev I'd rather make it an inoperative command
> altogether, since (to my mind at least) it is rather seductive.  When I
> think of the ev command, I think "defining my own local specialized
> environment within which this expression will be evaluated."  What that
> implies I probably haven't thought through properly, and I'm not sure
> anyone has (or even if they really can).  But I don't immediately think
> of "subst", which my mind parses as "use this to substitute something
> in for something else" as a substitute for ev.  So one of these
> releases (not this one though) I'd like to see us decide some final
> resolution to this.  Clearly the strongest proponent of ev was the old
> Maxima documentation, since it has little current support.  Given
> another development cycle or so Maximabook will need the part relevant
> to ev revamped somewhat anyway, once I bring it back to life again, so
> I'm no longer worried about that.  But I think the whole business of
> ev, subst, ratsubst, whatever the part commands are, etc. should be
> written up (probably as its own chapter) and clearly explained,
> defined, measured, whatever.  Kill whatever isn't good, and add
> robustness where needed (in docs if no other place.)  I think this
> concept will be an important one to hammer out with finalty early on,
> since a) a lot of other behaviors will depend on it and b) it's one
> even new users are likely to start using early on.
> 
> Maybe it won't be so hard to sort out, but if ev is not a good command
> to use than IMHO it should die.
> 
> CY
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima