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

*To*: mathgroup at smc.vnet.net*Subject*: [mg80858] 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:48:22 -0400 (EDT)*References*: <fb83lf$82d$1@smc.twtelecom.net> <200709020651.CAA25850@smc.twtelecom.net> <200709031012.GAA09453@smc.vnet.net> <DFA3206A564B80499B87B89B49BCD31301BB5408@EXCHANGE3.campus.tue.nl>

I understand these arguments since quite a long time ago I thought about them myself (I even sent a "puzzle" to the list asking where the "DownValue" of the definition NumericQ[a]=True is stored but the only "answer" I got referred to a story by Stanislaw Lem) but since I have long since convinced myself that this behaviour is intentional and extremely useful I believe them to be mistaken. First of all a practical remark: of course is no problem at all with "undoing" since one can easily undo NumericQ[a] = True with NumericQ[a] = False False Not only that but this is the logical and sensible thing to do. Having considered this matter quite carefully (and quite a long time ago) I do not agree with any of Fred's points about the "basic principles of Mathematica" in this particular case. NumericQ is simply special and there is no reason why some functions should not be special. To start with, without any user definitions, we have: NumericQ[a] False and yet False is not a DownValue of NumericQ. It seems quite natural for me therefor that NumericQ[a]=True simply changes the above "built-in" behaviour and does not create any DownValue either. Therefore it does not make any sense to me to try Clear[NumericQ]. Note also another very important fact. NumericQ is Protected yet you can define NumericQ[a]=True, which seems to contradict a "basic principle of Mathematica". But, and this is the key point, you can't make NumericQ[a] to be anything you like. Just try: NumericQ[a] = 3 NumericQ::set:Cannot set NumericQ[a] to 3; the lhs argument must be a symbol and the rhs must be True or False. >> In fact, I consider this message the key to the whole issue and in my opinion it refutes all of David's and Fred's objections to this use of NumericQ. This "error message" is precisely the missing part of the documentation. In fact, not having this message in the documentation is the only thing that I find "regrettable" about NumericQ. Not only is the function itself not regrettable but I would go as far as to say that (after GroebnerBasis) it is my second favourite function in Mathematica, which I have used without problems for many years (and in quite many of my past post to the MathGroup ) and would find it almost irreplaceable. I have ignored Fred's point about Dynamic because I can't possibly imagine any practical situation in whcih this kind of use of Dynamic might be encountered and, in my opinion, the most basic principle of Mathematica, which overrides all other prinicples, is that "problems" should be taken seriously only if there is some possibility that they could be encountered in a practical context and were not simply artificially manufactured to score a debating point or for some other "academic" reason. Andrzej Kozlowski Since this is not an O On 3 Sep 2007, at 15:59, Simons, F.H. wrote: > I have very mixed feelings about NumericQ. I agree with Andrzej > that it > is a very useful function. > > But for quite another reason I also agree with David Bailey. The > function NumericQ has attribute Protected, so I did not even get the > idea to try the command NumericQ[a]= True. This command should not > work, > it violates basic principles of Mathematica. > > As David states, unprotecting a Mathematica function and adding some > extra definitions is usually not a good idea. Instead, it is much > better > to use TagSet, as Carl Woll did. > > The other thing I do not like is that I have no idea where the > definition of NumericQ[a]= True is stored. It is not in the downvalues > of NumericQ, nor in the upvalues of a. So undoing this definition > cannot > be done with Clear[NumericQ] or with UpValues[a]={}, both very natural > commands. > > Finally, due to the mysterious implementation, Dynamic does not > work as > expected: > > Consider Dynamic[NumericQ[a]] > > It shows False. Assigning a numeric value to a changes it to True, and > unassigning a changes it back to False. That is correct. The command > NumericQ[a] returns True, but the display of Dynamic incorrectly > remains > False. Then do a=3, followed by a=., and Dynamic shows True. Now give > the command NumericQ[a]=.. Then the Dynamic object still shows True. > > One of the very, very strong points of Mathematica is its uniform > structure. NumericQ seems to be a very regrettable and, as far as I > can > see, unnecessary exception, despite the fact that the function works > fine. > > > > Fred Simons > Eindhoven University of Technology > > -----Original Message----- > From: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] > Sent: maandag 3 september 2007 12:13 > To: mathgroup at smc.vnet.net > Subject: [mg80822] Re: [mg80797] Re: Rule-based programming: declare > variables to be a number > > > 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. 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 >

**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>

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

**weights diagram of a representation**

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

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