Re: Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43313] Re: [mg43272] Re: [mg43232] Re: New version, new bugs
- From: Dr Bob <drbob at bigfoot.com>
- Date: Sun, 24 Aug 2003 04:55:10 -0400 (EDT)
- References: <200308231208.IAA25148@smc.vnet.net>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
I have to agree with Andrzej here. There's no point in endlessly criticising Mathematica unless you have a better option to present. I do wonder what WRI is doing about Maxim's bug list, though. Bobby On Sat, 23 Aug 2003 08:08:54 -0400 (EDT), Andrzej Kozlowski <akoz at mimuw.edu.pl> 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/ > > -- majort at cox-internet.com Bobby R. Treat
- References:
- Re: Re: New version, new bugs
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Re: New version, new bugs