Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43188] Re: [mg43175] Re: New version, new bugs
- From: Dr Bob <drbob at bigfoot.com>
- Date: Sun, 17 Aug 2003 04:27:59 -0400 (EDT)
- References: <bhd9a7$roa$1@smc.vnet.net> <200308160653.CAA25919@smc.vnet.net>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
Maxim,
>> 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!
Pattern matching and substitution are inherently a lot more flexible than
Ada language constructs, but it does seem that there should be a
specification for Mathematica's behavior. Perhaps there is for each
individual construct, but when you combine several of them, all bets are
off!
Perhaps it's an example of Godel's incompleteness theorem at work.
>> 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...
Some have the attitude that "If I know it, it doesn't need to be
documented," or "If it's written down anywhere in the world, it IS
documented." (No matter how impossible it is for a user to find it.)
>>
On the other hand, you need to compare Mathematica to something better, in
order to criticise it so much. And what would that be?
I do think WRI needs a more transparent and proactive reporting,
prioritization, and remediation process for bugs and documentation gaps.
(But again, who has that?)
Bobby
On Sat, 16 Aug 2003 02:53:57 -0400 (EDT), Maxim <dontsendhere@.> 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
>
>
>
--
majort at cox-internet.com
Bobby R. Treat
- References:
- Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Re: New version, new bugs