MathGroup Archive 2003

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Simplification of radicals
  • Next by Date: Re: Re: New version, new bugs
  • Previous by thread: Re: Re: New version, new bugs
  • Next by thread: Re: New version, new bugs