MathGroup Archive 2007

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

Search the Archive

Re: Re: Re: Rule-based programming: declare

  • To: mathgroup at
  • Subject: [mg80838] Re: [mg80822] Re: [mg80797] Re: Rule-based programming: declare
  • From: danl at
  • Date: Tue, 4 Sep 2007 03:38:08 -0400 (EDT)
  • References: <fb83lf$82d$>

> 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

Daniel Lichtblau
Wolfram Research

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