Re: Re: Re: Rule-based programming: declare variables to be a number
- To: mathgroup at smc.vnet.net
- Subject: [mg80833] 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:35:35 -0400 (EDT)
- References: <fb83lf$82d$1@smc.twtelecom.net> <200709020651.CAA25850@smc.twtelecom.net> <200709031012.GAA09453@smc.vnet.net> <DFA3206A564B80499B87B89B49BCD31301BB5408@EXCHANGE3.campus.tue.nl> <1B455F9B-C9DC-46BF-AB81-7C8F4853DE20@mimuw.edu.pl>
At the risk of beating a dead horse: the reason why it dos not make
sense to use UpValues or DownValues for NumericQ is precisely that
only two possible values are allowed, True or False. At least to me
it seems quite obvious that the mechanism of UpValues or Downvalues
is inappropriate in this situation, although I do not want to make a
drawn out argument out of this, which in the end is just a matter of
taste.
There are two other "matters of taste" involved here. First, it would
seem to me excessively pedantic to use:
g /: NumericQ[g] = True;
when we know that the shorter and simpler
NumericQ[g]=True
has exactly the same effect. The argument about Unprotecting
functions has no relevance here since nothing has to be unprotected
in this case.
The other issue is philosophical. Presumably Fred likes general rules
that hold without any exceptions. I, on the other hand, think
exceptions are what makes life, science, Mathematics and Mathematica
interesting. Just as, for example, exceptional Lie groups are the
most interesting lie groups so NumericQ is a beautiful function
because it has so many exceptional properties (which include the
fact, that, for example, NumericQ[a]=True and NumericQ[b]=True
automatically make NumericQ[a+Pi^Sin[b]] also True. That seems to me
to be also entirely against "the basic principles of Mathematica".
Andrzej Kozlowski
On 3 Sep 2007, at 17:07, Andrzej Kozlowski wrote:
> 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