About Bug 1742275: featurep(false, 'complex)

 I haven't been following all this discussion carefully, but note that the
scoping of some declarations uses contexts, independent of dynamic or
lexical scoping of values. 
E.g.

Assume(x>0)

  foo(r):=block([x], forget(x), assume(x<0) ,...)

After executing foo and returning,  what is assumed about global x?
Whether this is right or wrong, or easy or hard to do, are issues that
puzzled people in 1970's.

RJF


> -----Original Message-----
> From: maxima-bounces at math.utexas.edu 
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Harald Geyer
> Sent: Sunday, July 15, 2007 6:19 AM
> To: Stavros Macrakis
> Cc: maxima at math.utexas.edu
> Subject: Re: [Maxima] About Bug 1742275: featurep(false, 'complex)
> 
> > > Ideally I'd also like to see some possibility to specify 
> the defaults
> > > for undeclared symbols and some uniform way to query this 
> information.
> > > Right now we have the variable "domain", but it isn't used enough.
> > 
> > Agreed about "domain", but probably a big job to fix that.
> > solve(x^2+1,x) would have 0 solutions, not 2, asin(2.0) 
> would give an
> > error (or return itself), etc. etc.
> 
> That's not really what I have in mind: solve() doesn't care about
> declarations at all - whether this is ok is a different issue.
> Restricting the result of a function, is not a matter of declarations
> either. If you think that the above should be governed by 
> "domain" then I'll
> have to think about a new variable ...
> 
> What I want is a way to specify how undeclared symbols will 
> be interpreted.
> 
> > A lot of work. 
> 
> It wont be too much work to review the calls of "decl-complexp", 
> "kindp" et al and substitute them with a new clever function where
> appropriate. That's why I raised the question, how such a function
> should look like, in my last mail. Still not sure.
> 
> An other, even more important question: Which features can be global
> defaults? Anything else besides complex/real? 
> 
> integer comes to my mind, but even if this would be useful to some 
> users, maxima probably doesn't have the capabilities to cater for 
> their needs anyway.
> 
> scalar/nonscalar looks like good candidates to me.
> 
> How should this work? Multiple separate variables? One list of
> enabled default features?
> 
> 
> I think these are the most important questions to answer, 
> before making
> a concrete proposal. In case anybody has an opinion, input is much
> appreciated.
> 
> 
> Harald
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>