Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2001

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

Search the Archive

Re: Peculiar behavior of DiscreteDelta

  • To: mathgroup at smc.vnet.net
  • Subject: [mg28764] Re: [mg28731] Peculiar behavior of DiscreteDelta
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Fri, 11 May 2001 20:00:42 -0400 (EDT)
  • References: <200105110738.DAA19465@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Jack Goldberg wrote:
> 
> Hi group;
> 
> I am using Mathematica, version 4.0 on a Mac OS.9 system and a Unix system. On
> both systems I get the following peculiar buglet:
> 
> In[1]:= DiscreteDelta[1/2(1-Sqrt[5])+1/2(-1+Sqrt[5])]
> 
> results in a message entitled $MaxExtraPrecision::meprecp :  ...
> 
> and an output which is identical to the input.  This does not happen if
> DiscreteDelta is replaced by a numeric function such as Sin.  This led me
> to note that
> 
> *  DiscreteDelta does not have the Attribute NumericFunction.

This may be an oversight, I'm not certain.


> Back to the main point:
> 
> If the output of In[1] is followed by FullSimplify, then we get 1 which is
> expected since the argument of DiscreteDelta is 0.  If Sqrt[5] is replaced
> by other Sqrt[n] where n is not a perfect square, the result is again the
> message and the input is returned unaltered.  However if Sqrt[5] is
> replaced by Sqrt[r] (where r is symbolic) the input is returned unaltered
> with no message.

At least since version 3.0 we have avoided use of symbolic tactics e.g.
Simplify in the internal processing of numeric functions. Only numeric
evaluation will be attempted. As you noticed, this cannot in general
show that something is zero (it is much better suited to showing that a
quantity is non zero).


> Since  DiscreteDelta is not an oft used function, my guess is that Wolfram
> will not get around to fixing this for some time.  While I wait, I would
> like to write a "work around".
> 
> ** I define a pseudo  DiscreteDelta say JackDelta[x] which, like
> DiscreteDelta, gives 0 if the argument is not 0 and 1 otherwise. (That is,
> 
>         JackDelta[0]  = 1;
>         JackDelta[x_?NumericQ] = 0;
> 
> Amazingly,
> 
>         JackDelta[1/2(1-Sqrt[5])+1/2(-1+Sqrt[5])]
> 
> returns 1. I am delighted but very puzzled.

Me too (puzzled, that is). When I did that I got 0, which is what I
expect.


> Well experts, what's up?
> 
> (1) Why doesn't
> 
>         Sin[1/2(1-Sqrt[5])+1/2(-1+Sqrt[5])]
> 
> return 0.  (It returns the input unaltered)

As noted, attempts at "simplification" are not done in processing exact
or symbolic arguments to numeric functions (this is not the same as
automatic evaluations that are in fact performed, e.g.
1/Sin[x]-->Csc[x]) . The main reason is efficiency, although one might
also argue that there is no "canonical" notion of exactly what
simplification should take place.


> (2) Why does
> 
>         JackDelta[1/2(1-Sqrt[5])+1/2(-1+Sqrt[5])]
> 
> return 0. In view of (1), it should!
> 
> (3) Why does
> 
>         DiscreteDelta[1/2(1-Sqrt[5])+1/2(-1+Sqrt[5])]
> 
> have an error message associated with it.

That was a warning message to the effect that numerical evaluation could
not decide what should be the correct value. I find such messages to be
useful, although some folks might disagree.


> (4) Why does Mathematica have a different response for each of these calls?
> 
> These things drive me nuts.
> 
> Jack


Daniel Lichtblau
Wolfram Research


  • Prev by Date: Re: Interior of a polygon
  • Next by Date: Re: Peculiar behavior of DiscreteDelta
  • Previous by thread: Peculiar behavior of DiscreteDelta
  • Next by thread: Re: Peculiar behavior of DiscreteDelta