Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43296] Re: [mg43232] Re: New version, new bugs
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Sun, 24 Aug 2003 04:54:54 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
I feel that I still have not expressed myself clearly enough, so I have decided to have another go at it. Basically the essence of my disagreement with Maxim is this. I am convinced that most of Maxim's "problems" concerning pattern matching (at least those realted to the Flat attribute which as far as I can recall means all of them), are inherent in the very concept of mathematical programming by pattern matching, and therefore cannot be "fixed". Of course particular examples could be "fixed" but there will always remain others that will behave in a similar way. The reason is that the mathematical notions like associativity cannot be perfectly implemented in a pattern matching system on present day computers. A system that, when dealing with associative functions (i.e. functions having the Flat attribute) always attempted to find all possible matches by trying all the possible ways of parsing the input would not have an acceptable performance. On the other hand, if some choices are made and only certain matchings are attempted then one will always be able to construct examples that will look like Maxim's, that is, the system will fail to find patterns that ought to be found on the basis of our mathematical notion of associativity. I think what Mathematica implements is a pretty good compromise, and a compromise is in fact all one can hope for. Therefore Maxim's arguments are in fact arguments against using pattern matching as such, but if so then they are arguments against using Mathematica. I have not considered carefully his arguments related to scoping, which may be more constructive. The reason is that I have never felt that scoping (Module, Block etc) is an essential aspect of Mathematica and the sort of examples he constructs are totally alien to my style of programming. Since I cannot imagine myself ever wanting to nest Modules, I am not willing to devote any effort to try to understand what, if anything, he finds so objectionable in the way Mathematica deals with this issue. There are other occasional contributors to this list who have written with similar complaints but none of them has to my knowledge ever produced a program that a user of Mathematica like myself would ever even dream of writing. Andrzej On Saturday, August 23, 2003, at 08:32 AM, Andrzej Kozlowski wrote: > > On Thursday, August 21, 2003, at 04:25 AM, Maxim wrote: > >> When I was speaking about 'stupid' Ada >> developers, my sarcasm was pointed only at people with attitude 'most >> of the time >> it works ok, so why bother'. > > > One reason why this thread is never going to get anywhere is that you > are "figthing" straw oponents and ascibe to them ridiculous ideas > which you can then easily knowck down. There is nobody here who argues > that: > 'most of the time it works ok, so why bother'. What some people have > said is that an ordinary Matheamtica user who does not wish to spend > time delving deply into the intricacies of the langage is extremly > unlikely ever to come against the sort of "problems" you have been > presenting. A sophisticated user, on the other hand, will understnad > that most of them are a consequence of exactly the sort of thing that > makes Matheamtica so easy to use for the "simple" user. He will also > be able to find workarounds. In any case, the point is that in order > for your arguments to carry any weight you would have to be able to > show how Matheatica could retain all of its good points and avoid the > quirks you describe. You have not even made a start showing that. > Consider agian your latest pattern matching example: > > >> In[1]:= >> x + y + (x + y)^2 /. x -> a >> x + y + (x + y)^2 /. x + y -> a + b >> >> Out[1]= >> a + y + (a + y)^2 >> >> Out[2]= >> a + b + (x + y)^2 >> >> I think this illustrates the contradiction between the two design >> goals: to have >> a powerful language and to try to explain it in very simple terms to >> the user. >> For a calculator-like usage the examples above are just fine, but for >> progamming? >> If ReplaceAll should catch both occurences of x+y in the last >> example, then it's >> a bug. But maybe ReplaceAll just might do that if it feels like it, >> then it's not >> a bug, but in both cases the programmer is guaranteed to have some >> enjoyable >> moments trying to work it out. > > Like your other pattern matching examples, this one relies on the > behaviour of the pattern matcher when the Flat attribute is present. > Thus: > > In[1]:= > f[x,y,g[f[x,y]]]/.f[x,y]->a > > Out[1]= > f[x,y,g[a]] > > When f has the flat attribute this behaves differently: > > In[3]:= > SetAttributes[f,Flat] > > In[4]:= > f[x,y,g[f[x,y]]]/.f[x,y]->a > > Out[4]= > f[a,g[f[x,y]]] > > Obviously, Flat not going to have any effect in your supposedly > similar case: > In[5]:= > f[x,y,g[f[x,y]]]/.x->a > > Out[5]= > f[a,y,g[f[a,y]]] > > So the question is why does the Flat attribute cause this strange > behaviour? Well, why don't you try yourself to implement > "associativity", that properly works with pattern matching and does > not produce any such curious "quirks"? It's enought to spend a few > minutes thinking about this issue that makes one realize it is far > from easy. In fact I am sure no perfect implementation is possible, if > not for other reasons than because of performance issues. The presence > of associative functions in an expression leads to extremly rapid > growth in the number of possible matches and it would nto be realistic > for a symbolic algebra program to try to find all possible matches. > The result is that the Mathematica implementation of Flat gives the > impression of being incomplete. However, this has little or no > practical siginicance, and there are usually easy workrounds: > > In[6]:= > f[x,y,g[f[x,y]]]//.f[x,y]->a > > Out[6]= > f[a,g[a]] > > or in your case: > > In[7]:= > x + y + (x + y)^2 //. x + y -> a > > Out[7]= > a + a^2 > > In any case, the point is, when you have written the correct > implementation of Flat does not suffer from these problems send it to > WRI and let us know. It's not that 'most of the time it works ok, so > why bother', but rather that one the choice being offered is to use > what already works pretty well or not use it at all, then thoas eof us > who find Mathematica usefula nd elegant will choose the former. > > > > > Andrzej Kozlowski > Yokohama, Japan > > > Andrzej Kozlowski > Yokohama, Japan > http://www.mimuw.edu.pl/~akoz/ > http://platon.c.u-tokyo.ac.jp/andrzej/ > >