MathGroup Archive 2004

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

Search the Archive

Mathematica language issues

  • To: mathgroup at smc.vnet.net
  • Subject: [mg52955] Mathematica language issues
  • From: ab_def at prontomail.com (Maxim)
  • Date: Fri, 17 Dec 2004 05:20:39 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

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


  • Prev by Date: Re: Minors
  • Next by Date: Re: Many keys not working under Linux Mandrake 10.1
  • Previous by thread: NonlinearRegress+NIntegrate
  • Next by thread: Re: Mathematica language issues