Re: Re: Re: Rule-based programming: declare variables to be a number

*To*: mathgroup at smc.vnet.net*Subject*: [mg80846] Re: [mg80822] Re: [mg80797] Re: Rule-based programming: declare variables to be a number*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Tue, 4 Sep 2007 03:42:14 -0400 (EDT)*References*: <fb83lf$82d$1@smc.twtelecom.net> <200709020651.CAA25850@smc.twtelecom.net> <200709031012.GAA09453@smc.vnet.net> <2083.74.136.215.48.1188856037.squirrel@webmail.wolfram.com>

On 3 Sep 2007, at 23:47, danl at wolfram.com wrote: >> >> 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 > > Thanks for the clarifications. At the risk of sounding self- justifying, I would just like to add that I had guessed most of the above myself but out of laziness and lack of spare time did not make it quit clear what I really meant. Actually, when I wrote : "designed with this in mind" I was not really referring to the algebra but simply to the possibility of adding new numeric quantities by choosing a symbol, say a and setting the numeric flag on with NumericQ [a]=True. The property of being numeric is then automatically propagated to arithmetical expressions involving existing numeric quantities and values at such numeric quantities of functions with Attribute NumericFunction. Assuming this is properly implemented then it would seem to me a logical consequence that the "algebraic approach" that this thread was about, should also work without problems because it relies exactly on the same properties that are needed for adding of new numerical quantities to work. That is all that I meant but it did not seem to me at that time worth writing so much on this topic. As usual in such cases I ended up writing far more than would have been necessary had I been clearer about what I thought about this from the beginning. By the way, I also often use the approach you discuss at the end, in fact I use it exclusively in work intended for "my own consumption". I like to use the method of defining scalars by means of NumericQ when I am teaching students without serious exposure to Mathematica because it is easy to make things look just like in a math book, without having to explain Mathematica syntax such as Heads of expressions etc. Andrzej Kozlowski

**References**:**Re: Rule-based programming: declare variables to be a number***From:*David Bailey <dave@Remove_Thisdbailey.co.uk>

**Re: Re: Rule-based programming: declare variables to be a number***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>