meval



ratdisrep etc  changes only the FORM of data. meval changes the
value by looking up bindings.  If hayat converts information into
rat form and then calls meval on kernels, and there is a possibility
that the call to meval itself calls ratdisrep, and it does so without
locally protecting the values of genvars and varlist by making local
copies, then there would be a chance for a bad interaction.

It seems to me a really bad idea to mix form-changing programs with
value-changing programs this way.

  Ideally,
no lisp program except one that is written with full understanding of
the genvar/ varlist situation should be handed the "insides" of a
rat form.
By inside I mean the stuff like  (g0012 1 1)
inside

((mrat simp ($x) (g0012 ..)) (g0012 1 1) . 1)

Somehow I get the feeling that I am repeating myself.  It would be
tempting to re-do this whole aspect of the rational function package
in a way that would be cleaner, except that I'm not sure how that
new version would work.  The concept of using tagged data  (e.g.
tagged with MRAT)  as an external interface, but using the untagged
data internal to some suite of programs, is pretty standard, I think.
People messing around with the internal data form need to abide by
the standards of that form.



RJF



Martin RUBEY wrote:
> On Wed, 5 Feb 2003, Richard Fateman wrote:
> 
> 
>>meval should not have to be protected unless it is called
>>from a program like pdisrep, which uses the 'raw' genvars,
>>and in which it again calls ratdisrep.
> 
> 
> Thus, in hayat meval needs to be protected, because hayat uses the 'raw' 
> genvars...
> 
> But, in fact I do not quite understand your statement. Do you mean
> 
> a call to meval needs to be protected only if the program that calls meval 
> uses 'raw' genvars before and after the call to meval?
> 
> (I tried hayat with meval instead of maxima-substitute, getting the wrong 
> answer, just as I expected, because meval eventually calls 
> maxima-substitute, of course)
> 
> 
>>Any call to meval from pdisrep would be, in my view,
>>a mistake waiting to happen.
> 
>  
> I don't understand you here. pdisrep doesn't call meval.
> 
>  
> 
>>The gensym program that tacks  x onto a number instead
>>of calling them all g0123, g0124, .... looks cute but
>>seems to be bad idea if the SAME print name is used for
>>different symbols.  The way maxima seems to be set up, you
>>have confusing printouts, and unnecessarily so.  In theory
>>one could have all gensyms with the same print name, in some
>>bizarre attempt to save memory perhaps.  This seems dumb.
>>Shouldn't the counter be incremented so that
>>#:|x21773| can only occur once?  Is this a bug in GCL?
>>Does this problem occur in all Lisps?
> 
> 
> I think that this is not really a great problem. It just makes debugging a 
> *little* more difficult
> 
> Martin
> 
> 
> 
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima