Re: pattern bugs and comment on intuitive syntax for the New Year
- To: mathgroup at smc.vnet.net
- Subject: [mg115167] Re: pattern bugs and comment on intuitive syntax for the New Year
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Mon, 3 Jan 2011 03:56:41 -0500 (EST)
I certainly don't intend to provide incentive for more of these seemingly never ending monologues by Richard. They standard pattern that they have followed for years is to begin a discussion about some aspect of Mathematica (usually to claim or suggest some "bug" or bad design) and then when it is pointed out that the behaviour described is perfectly natural and logical (given the basic principles of Mathematica) to point out triumphantly that ... it is done differently in Lisp... A typical example was in a recent response to a post of mine (which I decided to ignore at the time): when I pointed out that symbolic programs can't be compiled in Mathematica Richard kindly informed me that they can be compiled in Lisp, which is hardly surprising given that Lisp, unlike Mathematica, is a compiled language. (When posting here Richard generally assumes that no one but him knows anything about languages like Lisp. It may perhaps come as a shock to him but I actually thought Scheme for three years, to, horror of horrors, computer science students, using Friedman and Felleisen's The Little Schemer and the Seasoned Schemer. This was at a major computer science school in Japan, where none of the students knew any Lisp or Scheme and now that I no longer teach this course, nobody else does either. It suggests to me a less than bright future for this once important language and, of course, any CAS that use it for programming). So, while I don't intend to respond to this latest RJF post in detail, there are a couple of issues here that may be of some general interest and seem worth commenting on. First, most of the patterns used in these examples are unlikely to appear in practice. If I understand correctly the intention behind them, the natural way to achieve the "desired" result would have been: x + 3 /. x_ + c_. :> aha[c] x /. x_ + c_. :> aha[c] x + y + 3 /. x + y + c_. :> aha[c] which all produce the expected results. Perhaps I am missing something but I can't see at all why anybody would use BlankNullSequence in this situation. Second, the one thing, that may be somewhat puzzling among the examples below, is the difference between: MatchQ[x + y, x + y + c___] True MatchQ[x, x + c___] False Actually there is nothing surprising here. The first match works because of the Flat and OneIdentity attributes of Plus cause Plus[x,y] to be rewritten as Plus[x,y,Plus[]] so that now the pattern Plus[x,y,c___] and the answer is: x + y /. x + y + c___ :> aha[c] aha() Mathematically this does "match" does not make sense but then nobody wanting to make sense would use a BlankNullSequence in this situation: it is an artificial examples made up purely to cause puzzlement and an appearance of something like a "bug". In the case x /. x + c___ :> aha[c] x one gets a different outcome because no match is found, but there is nothing at all surprising here since the function Plus with its attributes is not explicitly involved and one would not expect Mathematica to replace all instances of single symbols by Plus[x] in order to make a match. In fact, by using an explicit Plus (with Unevaluated) we get the expected behaviour: Unevaluated[Plus[x]] /. x + c___ :> aba[c] aba() Every single one of the examples given below is logical and easily predictable. This is not to say that it "could not be different" (this is the kind of claim that nobody here ever makes except perhaps in Richard's imagination, which of course provides him with another excuse for providing more jolly news about Lisp and the existence of other CAS systems that do things in a different way, etc...) but that it is all intentional and consistent. Whether it is better or worse than other approaches is essentially a matter of taste and, I am glad to observe, my taste rarely agrees with Richard's. Andrzej Kozlowski On 2 Jan 2011, at 10:56, Richard Fateman wrote: > > > Guess the results. > > x+3 /. x+c___ -> aha[c] > x /. x+c___ -> aha[c] > x /. x+c___:0 -> aha[c] > > compare to > > x+y+3 /. x+y+c___ -> aha[c] > x+y /. x+y+c___ -> aha[c] > x+y /. x+y+c___:0 -> aha[c] > x+y+a+b /. x+y+c___ :> aha[c] > x+y+a+b /. x+y+c___ :> aha[Plus[c]] > x+y /. x+y+c___ :> aha[Plus[c]] > > > > I think the requirement for the :0 represents a bug. Maybe the > need for the Plus[], too. The treatment of NullSequences within > a Flat operator could be different, leaving an operator around. > > ............ > > Another item. really, syntax. > > define > > GreaterThan[q_]:= #>q& > gt2==GreaterThan[2] (* a function of one argument. > is that argument > 2? *) > > > mm[2, 10] /. mm[q_, s_?GreaterThan[q]] :> aha[q, s] > > doesn't give aha.. > > > mm[2, 10] /. mm[q_, s_?gt2] :> aha[q, s] > > does give aha > > this works, though. > mm[2, 10] /. mm[q_, s_?(GreaterThan[q])] :> aha[q, s] > > I love that intuitive syntax. None of that excess > parentheses and stuff. (sarcasm) > > This error would have been > much more apparent in Lisp. > > happy new year. > > > >