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: [mg80846] 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:42:14 -0400 (EDT)
  • References: <fb83lf$82d$> <> <> <>

On 3 Sep 2007, at 23:47, danl at wrote:

>> 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.
> Not really, though it seems to work. More below.

>> 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
> The sort of usage you describe might be convenient and useful,  
> which is
> all to the good. The design intent was for other purposes, to wit,  
> to flag
> expressions for which N[...] or N[...,precision] would yield an
> approximate number. That said, it is understood that there are  
> cases we
> would mess up. For example, NumericQ[Sin[3, 4]] will return True.
> (Why? Because internally we use a simple mode of testing and  
> transmission;
> NumericQ objects have a flag and NumericFunction heads of NumericQ
> arguments get the flag set. This use of flagging, along with the  
> fact that
> many special functions are implemented in Mathematica and need to  
> support
> it, is also why NumericQ setting does not affect DownValues.)
> A common sort of internal use is in deciding when certain tests  
> should be
> performed by the evaluator, e.g. is the base of a power positive.  
> The code
> in question needs to be sufficiently robust to not care if numerical
> testing returns some flavor of not-a-number (NaN), such as  
> Indeterminate,
> an infinity, non-NumberQ output identical to the input, etc. What this
> implies, in effect, is that flagging some symbol as NumericQ should  
> cause
> no harm. Hence symbols can "safely" be flagged for the sort of  
> purposes
> indicated above. (Which is to say, I'll call it safe until people  
> start
> showing examples of breakage it might cause. Then I'll call it  
> "unsafe".
> But probably not a bug.)
> As for those purposes indicated earlier in this thread, yeah, I  
> guess one
> can get the algebra to work that way. Myself, I'd instead demarcate  
> the
> noncommuting variables (e.g. by specific heads), thus treating  
> everything
> else (implicitly) as scalars. One reason is I then find it easier to
> support the algebraic operations in cases where there is a commutator
> defined.
> Daniel Lichtblau
> Wolfram Research

Thanks for the clarifications. At the risk of sounding self- 
justifying, I would just like  to add that  I had guessed most of the  
above myself but out of laziness and lack of spare time did not make  
it quit clear what I really meant. Actually, when I wrote : "designed  
with this in mind" I was not really referring to the algebra but  
simply to the possibility of adding new numeric quantities by  
choosing a symbol, say a and setting the numeric flag on with NumericQ 
[a]=True. The property of being numeric is then automatically  
propagated to arithmetical expressions involving existing numeric  
quantities and values at such numeric quantities of functions with  
Attribute  NumericFunction. Assuming this is properly implemented  
then it would seem to me a logical consequence  that the "algebraic  
approach" that this thread was about, should also work without  
problems because it relies exactly on the same properties that are  
needed for adding of new numerical quantities to work. That is all  
that I meant but it did not seem to me at that time worth writing so  
much on this topic. As usual in such cases I ended up writing far  
more than would have been necessary had I been clearer about what I  
thought about this from the beginning.
By the way, I also often use the approach you discuss at the end, in  
fact I use it exclusively in work intended for "my own consumption".  
I like to use the method of defining scalars by means of NumericQ  
when I am teaching students without serious exposure to Mathematica  
because it is easy to make things look just like in a math book,  
without having to explain Mathematica syntax such as Heads of  
expressions etc.

Andrzej Kozlowski

  • Prev by Date: Re: Re: Re: Rule-based programming: declare
  • Next by Date: Re: Re: Re: Rule-based programming: declare variables to be a number
  • Previous by thread: Re: 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