Re: Re: Re: Rule-based programming: declare
- To: mathgroup at smc.vnet.net
- Subject: [mg80838] Re: [mg80822] Re: [mg80797] Re: Rule-based programming: declare
- From: danl at wolfram.com
- Date: Tue, 4 Sep 2007 03:38:08 -0400 (EDT)
- References: <fb83lf$82d$1@smc.twtelecom.net>
> > On 2 Sep 2007, at 08:51, David Bailey wrote: > >> As others have commented, it is not a good idea to write code like >> NumericQ[g]=True because this changes the basic operation of >> Mathematica. For example, such code might work OK until you try to >> combine it with some more code that needs NumericQ for something else! >> >> David Bailey >> http://www.dbaileyconsultancy.co.uk > > > Who are the "others"? > Anyway, I completely disagree with this statement in this particular > context. > > NumericQ has clearly been designed with this in mind. Not really, though it seems to work. More below. > Note, for > example, that althou NumericQ is Protected, a definition like > > NumericQ[a]=True > > does not require unprotecting NumericQ. Moreover, it does not add a > DownValue to NumericQ. > > NumericQ[g] = True; > DownValues[NumericQ] > {} > > > There are plenty of other reasons to believe that all all > theseproperties of NumericQ are designed precisely for this type of > use. Besides, I have another reason to think that no probems of the > kind you are imagining would happen in this case: I have been using > NumericQ inprecisly this way for about 10 years in numerous notebooks > without any problems. > > Note alo the post from Carl Woll which, I think, can be regarded as > an "offcial" WRI authorization for this kind of usage ;-) > > (However, note also that using Carl's definition: > > In[19]:= g /: NumericQ[g] = True; > > Dos not actually add an UpValue to g: > > UpValues[g] > {} > > and I don't think it has any advantage over the more straightforward > > NumericQ[g] = True; > > > I am sure all this is deliberate design, and even though it may not > be easy to explain, it is very convenient. > > Andrzej Kozlowski The sort of usage you describe might be convenient and useful, which is all to the good. The design intent was for other purposes, to wit, to flag expressions for which N[...] or N[...,precision] would yield an approximate number. That said, it is understood that there are cases we would mess up. For example, NumericQ[Sin[3, 4]] will return True. (Why? Because internally we use a simple mode of testing and transmission; NumericQ objects have a flag and NumericFunction heads of NumericQ arguments get the flag set. This use of flagging, along with the fact that many special functions are implemented in Mathematica and need to support it, is also why NumericQ setting does not affect DownValues.) A common sort of internal use is in deciding when certain tests should be performed by the evaluator, e.g. is the base of a power positive. The code in question needs to be sufficiently robust to not care if numerical testing returns some flavor of not-a-number (NaN), such as Indeterminate, an infinity, non-NumberQ output identical to the input, etc. What this implies, in effect, is that flagging some symbol as NumericQ should cause no harm. Hence symbols can "safely" be flagged for the sort of purposes indicated above. (Which is to say, I'll call it safe until people start showing examples of breakage it might cause. Then I'll call it "unsafe". But probably not a bug.) As for those purposes indicated earlier in this thread, yeah, I guess one can get the algebra to work that way. Myself, I'd instead demarcate the noncommuting variables (e.g. by specific heads), thus treating everything else (implicitly) as scalars. One reason is I then find it easier to support the algebraic operations in cases where there is a commutator defined. Daniel Lichtblau Wolfram Research