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: Rule-based programming: declare variables to be a number