Re: Mathematica language issues

*To*: mathgroup at smc.vnet.net*Subject*: [mg52981] Re: [mg52955] Mathematica language issues*From*: DrBob <drbob at bigfoot.com>*Date*: Sat, 18 Dec 2004 04:00:16 -0500 (EST)*References*: <200412171020.FAA16185@smc.vnet.net>*Reply-to*: drbob at bigfoot.com*Sender*: owner-wri-mathgroup at wolfram.com

Yikes again!! It's a wonder we get anywhere at all! But we do, so your examples must be perverse in some way. Bobby On Fri, 17 Dec 2004 05:20:39 -0500 (EST), Maxim <ab_def at prontomail.com> wrote: > > > All the typical issues with the Mathematica programming language are > still present in version 5.1: > > Compile[{}, > Module[{x = 0}, > While[x++; EvenQ[x] ]; > x > ]][] > > still evaluates to 3, and it is easy to construct other similar > examples: > > In[1]:= > Module[ > {L = Partition[Range[8], 2]}, > Table[L[[i, j]], {i, 4}, {j, If[EvenQ[i], 1, 2]}] > ] > > Compile[{}, > Module[ > {L = Partition[Range[8], 2]}, > Table[L[[i, j]], {i, 4}, {j, If[EvenQ[i], 1, 2]}] > ]][] > > Out[1]= > {{1, 2}, {3}, {5, 6}, {7}} > > Out[2]= > {{1, 2}, {3, 4}, {5, 6}, {7, 8}} > > In the second case EvenQ[i] is evaluated before i is assigned a > numerical value, and therefore for each i the inner iterator is {j, > 2}. Thus pretty much all that is known about Compile is that the > result will work roughly similar to the uncompiled code. Nothing > beyond that is guaranteed. > > The issues with Unevaluated are all here as well, from really serious > problems such as > > In[3]:= > Unevaluated[D[y, x]] /. {y -> x} > Unevaluated[D[y, x]] /. {{y -> x}} > > Out[3]= > 1 > > Out[4]= > {0} > > where you can find out how many Unevaluated wrappers are required in > each case only by trial and error, to curious glitches like > > In[5]:= > Unevaluated[1 + 1]*2 > 2*Unevaluated[1 + 1] > > Out[5]= > 4 > > Out[6]= > 2*Unevaluated[1 + 1] > > Next, there's the question of how various functions act on patterns. > Suppose you want to convert Max[x, -Infinity] to x and write > > Max[x, -Infinity] /. Max[x_, -Infinity] -> x > > This will not work, because Max[x, -Infinity] is left unevaluated, but > Max[x_, -Infinity] evaluates to x_. Besides, when _+_ evaluates to 2_, > this is not only counter-intuitive, but also not very logical, because > unnamed patterns are supposed to stand for two possibly different > expressions. > > Another example: > > In[7]:= > x /: x + (a_.) = a; > x > > Out[8]= > x > > If, provided that we define f[y+a_.]=a, f[y] evaluates to 0, I can't > see why it should work differently in the above case. > > Then there are the old problems with pattern matching: > > a + b + c /. Plus[a, b] :> 0 > a + b + c /. s : Plus[a, b] :> 0 > a + b + c /. Plus[a, b] /; True :> 0 > a + b + c /. HoldPattern[Plus][a, b] :> 0 > > The first expression evaluates to c, others leave a + b + c unchanged. > Adding a name for the pattern, putting a condition on the left-hand > side of the pattern or wrapping the head of the expression in > HoldPattern all break pattern matching for Plus. More precisely, in > those cases Mathematica will still recombine the arguments of Plus to > transform a + b + c into Plus[Plus[a, b], c] and so on, but the > replacement rules will work only on the expression as a whole, not on > subexpressions such as Plus[a, b]. > > Here is a variation along the same lines, based on Paul Buettiker's > post ( http://forums.wolfram.com/mathgroup/archive/2004/Sep/msg00090.html > ): > > In[9]:= > a + b /. HoldPattern[Plus[s__]] :> s > a + b /. s2 : HoldPattern[Plus[s__]] :> s > > Out[9]= > a + b > > Out[10]= > Sequence[a, b] > > The only difference is that in the second example we add a name for > the pattern. > > Maxim Rytin > m.r at inbox.ru > > > > -- DrBob at bigfoot.com www.eclecticdreams.net

**References**:**Mathematica language issues***From:*ab_def@prontomail.com (Maxim)