Services & Resources / Wolfram Forums
MathGroup Archive
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2007

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

Search the Archive

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

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

Finally, due to the mysterious implementation, Dynamic does not work as

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

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: [mg80831] [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

  NumericQ has clearly been designed with this in mind. Note, for
example, that althou NumericQ is Protected, a definition like


does not require unprotecting NumericQ. Moreover, it does not add a
DownValue to NumericQ.

NumericQ[g] = True;

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

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:


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: Help with numerical differentiation
  • Next by Date: Re: is there a better way to do constraint logic programming in Mathematica?
  • Previous by thread: Re: Re: Rule-based programming: declare variables to be a number
  • Next by thread: Re: Re: Re: Rule-based programming: declare variables to be a number