MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

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

  • To: mathgroup at
  • Subject: [mg80858] Re: [mg80822] Re: [mg80797] Re: Rule-based programming: declare variables to be a number
  • From: Andrzej Kozlowski <akoz at>
  • Date: Tue, 4 Sep 2007 03:48:22 -0400 (EDT)
  • References: <fb83lf$82d$> <> <> <>

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


NumericQ[a] = 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:


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]
> Sent: maandag 3 september 2007 12:13
> To: mathgroup at
> 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
> 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

  • Prev by Date: Re: Re: Re: Rule-based programming: declare variables to be a number
  • Next by Date: weights diagram of a representation
  • Previous by thread: Re: Re: Re: Rule-based programming: declare variables to be a number
  • Next by thread: Re: Rule-based programming: declare variables to be a number