Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43185] Re: [mg43175] Re: New version, new bugs
- From: Andrzej Kozlowski <andrzej at platon.c.u-tokyo.ac.jp>
- Date: Sun, 17 Aug 2003 04:27:55 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
>
On Saturday, August 16, 2003, at 08:53 AM, Maxim wrote:
>
> Andrzej Kozlowski wrote:
>
>> On Tuesday, August 12, 2003, at 10:43 AM, Maxim wrote:
>>
>>> Also I once again ran into the fact that named and unnamed (Slot[k])
>>> function parameters behave differently; consider the following
>>> definition:
>>>
>>> In[1]:=
>>> f = #1 /. {x_, y_} :> Refine[Sign[{x, y}], #2] &;
>>> f[{a - b, b - a}, a > b]
>>>
>>> Out[2]=
>>> {1, -1}
>>>
>>> The function f simply returns the signs of the pair of elements under
>>> given
>>> assumptions, but not in this case:
>>>
>>> In[3]:=
>>> f[{y, x}, y > 0 && x < 0]
>>>
>>> Out[3]=
>>> {-1, 1}
>>>
>>>
>>
>> I admit it can be a nuisance but a minor one since to fix it you need
>> just to add half a line:
>>
>> f = #1 /. {x_, y_} :> Refine[Sign[{x, y}], #2] & /. {x ->
>> Unique[x], y -> Unique[y]};
>>
>> In[3]:=
>> f[{y,x},y>0&&x<0]
>>
>> Out[3]=
>> {1,-1}
>>
>> The flexibility of the Mathematica's pattern matching language means
>> that one can form a huge number of patterns, many of which the
>> designers of the language could not have possibly foreseen. Not
>> surprisingly some of them will not work as one might expect.
>> On the other hand the same flexibility makes it usually easy to find
>> an
>> alternative way to achieve the intended result without the problems
>> encountered encountered with the original approach. It seems to me
>> not
>> unreasonable to view most of the constructions that do not work and
>> which have working alternatives as improperly formed. (The same
>> applies, I think, to your earlier HoldPattern[head][body]
>> construction. Since what it intends to do is exactly equivalent to
>> HoldPattern[head[#]]&[body]-in both cases head is held but body is
>> evaluated - and since the latter approach works without any glitches,
>> it seems to me reasonable to consider the former to be improperly
>> formed and to be avoided).
>>
>> Andrzej Kozlowski
>> Yokohama, Japan
>> http://www.mimuw.edu.pl/~akoz/
>> http://platon.c.u-tokyo.ac.jp/andrzej/
>
> Using Unique is a very useful suggestion, especially when there are
> twenty
> pattern variables and some of them already have values assigned.
>
> Actually, as I already wrote in my message, Function with named formal
> parameters works differently -- which already provides a workaround,
> but
> that's missing the point entirely.
>
> In my opinion, all workarounds always boil down to one thing: 'Don't do
> that and the error won't appear.' I think such helpful suggestions
> aren't
> worth much.
>
> As to the claim that 'if it doesn't work as expected, then it's
> improperly
> formed', I don't know how anyone can say that seriously. How stupid the
> people who developed Ada and other reliability-focused systems were!
> They
> should have just said, guys, there are millions of programs you can
> write,
> how are we supposed to know how they'll work? If something goes wrong,
> it's
> all your fault!
>
> I'd like to add a couple of words about the Trott-Strzebonski method: I
> don't think this is something that should be used as an illustration
> of the
> power of Mathematica language -- it illustrates something else. How is
> the
> user supposed to know that
>
> Hold[x] /. x :> Module[
> {},
> Random[] /; True
> ]
>
>
> gives one answer, but
>
>
> Hold[x] /. x :> Block[
> {},
> Random[] /; True
> ]
>
> works differently? The answer is that nobody can know that without
> actually
> trying it out. I understand this trick can be useful, but I just
> wouldn't
> call an obvious kludge 'a clever idiom'. The words that it was
> *discovered*
> by Trott and Strzebonski are very characteristic -- as though we were
> talking about a black box, not something operated by known rules.
>
> Even for something as far from ideal in this aspect as C language
> (I'm, of
> course, not comparing the two languages), it is always mentioned
> explicitly
> in the specifications whenever the result is not well-defined.
>
> Maxim Rytin
> m.r at prontomail.com
>
>
>
Using Unique may not be a perfect solution, but it took me about two
seconds to think of it, which shows something about what I called the
flexibility of Mathematica. I can actually think of some other ways,
but as you say it would be pointless to list them here. In fact, I
would like to see your "realistic example" with twenty variables all
suffering form the same problem since I rather doubt that it exists,
for like most of your other recent examples it seems to been created
just to score some debating points. The only problem is that the debate
seems to be a monologue or would be if I were not such a fool that
allows himself so to be so easily provoked into taking part in this
pointless exercise.
Of course we have an entirely different attitude to programming. I must
confess I actually rather like all these aspects of Mathematica that
you criticise including even the lack of complete documentation. I
particularly like the fact that you can explore Mathematica in a way
that somewhat resembles the way one explores mathematics. Even the fact
that some things do not work as expected is not such a great fault from
my point of view, probably because in over 20 years of mathematical
research I got used to this sort of thing. And the fact that you can
find beautiful and unexpected tricks like the Strzebonski-Trott method
is, for me, actually one of the strongest incentives for using
Mathematica rather than the alternative systems, which seem to offer a
lot fewer such possibilities.
From your recent messages it seems clear that none of this applies to
you. So it also seems strange that you continue to use Mathematica when
it is so easy to switch to one of the alternatives, which obviously
ought to be much more to your taste. Moreover, why do you keep sending
all these angry sounding messages since as you have already noted
yourself they are being ignored and are almost certain to continue to
be so as they contain very few constructive suggestions that could be
realised without a fundamental re-write of the whole program as well as
a change of the philosophy behind it? (I am of course exempting your
reports of the genuine bugs you have found, although they really ought
to be sent first to WRI's Technical Sopport).
Andrzej Kozlowski
Yokohama, Japan