Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg42859] Re: New version, new bugs
- From: Jens-Peer Kuska <kuska at informatik.uni-leipzig.de>
- Date: Wed, 30 Jul 2003 19:31:21 -0400 (EDT)
- Organization: Universitaet Leipzig
- References: <bfdqd8$sfi$1@smc.vnet.net> <bg7vmu$hii$1@smc.vnet.net>
- Reply-to: kuska at informatik.uni-leipzig.de
- Sender: owner-wri-mathgroup at wolfram.com
Hi,
> Consider four
> nearly identical expressions:
>
> In[1]:=
> f[a] + f[b] + 1 /. HoldPattern[Plus][f[_] ..] /; True :> 0
> f[a] + f[b] + 1 /. HoldPattern[Plus[f[_] ..]] /; True :> 0
> f[a] + f[b] + 1 /. HoldPattern[Plus][f[_] ..] :> 0 /; True
> f[a] + f[b] + 1 /. HoldPattern[Plus[f[_] ..]] :> 0 /; True
>
> Exactly one of them evaluates to 1. This is something from Who Wants to Be a
> Millionaire, not a programming language.
If you don't know what you are doing you should not do it.
You first expression f[a]+f[b]+1 is ordered as
1+f[a]+f[b]
with out the Flat attribute of Plus[] your patterns above match only for
the
case f[a]+f[b]+f[c]+f[d]+... and *not* for 1+f[a]+f[b].
In the first two cases, the Condition[Holdpattern[_],_] is not evaluated
and the
Flat attribute is not applied, in the third case the
HoldPattern[Plus][_] prevent the application of the Flat
attribute ...
If something is "nearly identical" it does not mean that it
*is* identical.
If you avoid the useless HoldPattern[] nonsense and write
f[a] + f[b] + 1 /. Plus[f[_] ..] /; True :> 0
f[a] + f[b] + 1 /. Plus[f[_] ..] :> 0 /; True
all works as expected
>
> Another situation where the result is unpredictable is passing patterns to
> functions: can you guess what the result of Integrate[x_,x_] will be? And of
> Integrate[_,_]?
It is semantic nonsens to pass a pattern to a function that expect
a realisation of a pattern. If you have a function DriveA[car_]
a call of this function will drive a certain car like
DriveA[Mercedesbenz] but you can't expect that the function
can drive all possible cars at the same time when you say
DriveA[anyCar_]
>
> Then, of course, there is Mathematica's scoping:
>
> In[1]:=
> Module[
> {sub,f},
> sub[a_,b_]:=Module[
> {aa=a,x},
> aa-b
> ];
> f[x_]=sub[x,x]
> ]
>
> Out[1]=
> x$-x$38
>
> The problem is that the x in aa and the x in b get renamed differently; I am
> not even trying to figure out if it is a bug, I'm just pointing out how
> confusing it is (probably it has to do with the fact that assignment in
> Module initialization doesn't use Set).
It has to do with the fact that you are using lexical scoping and you
mean
dynamic scoping
Block[{sub, f}, sub[a_, b_] := Block[{aa = a, x}, aa - b];
f[x_] = sub[x, x]]
Mathematica does what you say and not that what you mean ...
>
> Another example:
>
> In[1]:=
> <<discretemath`
> UndirectedQ[FromAdjacencyMatrix[{{0,1},{0,0}},Type->Directed]]
> <<numbertheory`
> UndirectedQ[FromAdjacencyMatrix[{{0,1},{0,0}},Type->Directed]]
>
> Out[2]=
> False
>
> Out[4]=
> True
>
> Here the situation is clear: the reason for the two different answers is a
> name conflict. But it would be nice to at least see a warning message.
If you don't get a error message about symbol shadowing you have
switched it
of, but it is still you problem to *say* Mathematica what you mean and
to
write
<<discretemath`
UndirectedQ[FromAdjacencyMatrix[{{0,1},{0,0}},Type->Directed]]
<<numbertheory`
discretemat`UndirectedQ[discretemath`FromAdjacencyMatrix[{{0,1},{0,0}},
discretemath`Type->discretemath`Directed]]
And, yes it is a bug that Mathematica can't read your mind. But AFAIK
WRI is working on this feature ...
>
> Finally, whose brilliant idea was it to give the output for ??In and ??Out
> unsorted?
We must have different Mathematica's because my
DownValues[In]
are sorted. Or did you mean that In/Out should follow the
Input/Output cell order of the notebook and not the In/Out
commands send to the Kernel ?
Regards
Jens