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