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)
- Mathematica language issues