Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43211] Re: [mg43175] Re: New version, new bugs
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Tue, 19 Aug 2003 07:53:14 -0400 (EDT)
- References: <bhd9a7$roa$1@smc.vnet.net> <200308160653.CAA25919@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
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!
We were not infallible, though certainly we were fairly smart. I say
that as one who spent three years of his professional life, from
1983-85, working on various parts of the USAF Ada Integrated Environment
project.
There are many significant differences between Ada and similar
languages/systems, and Mathematica. First and foremost, by mandate (that
is, even preceding design), they were intended to have "complete"
semantic specifications. This of course means that things not "valid"
were simply declared to be "invalid". Among other things, this mean that
projects such as ours had "language lawyers" to figure out what exactly
the were the gray areas in the semantics, and either render decisions or
else inform the DoD in cases of potential problems. Moreover we had
several dozen technical staff at work on this project, and we were but
one of several such projects supported by the DoD. Suffice it to say
that quite alot of people were paid specifically to consider language
semantic issues. This is far removed from market place forces that drive
development of Mathematica and other commercial technical systems.
As I left in '85 to attend graduate school, I cannot speak as to the
success of Ada, or how well it met its original intent (which was to
become, at the least, the DoD standard language and programming
environment for all software). Certainly it has not supplanted C (I
doubt anyone thought or intended that it would). It has not, alas,
supplanted Fortran, nor will it ever do so; I think Fortran would
swallow it whole before allowing that to happen. I do not know the state
of Cobol. I believe Pascal is largely extinct, but I don't know if that
was caused in any way by the emergence of Ada. (Curiously, we used
Pascal to build a subset-Ada bootstrap compiler.)
As you note, Ada was meant to be reliability-focused. Its other main
need was runtime speed. Even with the reliability criterion, I have
doubts as to how adequate it would be for even basic mathematical
programming. For example, how well specified are the numerics? How might
one use if in conjunction with standard numeric libraries e.g. LAPACK?
Does one gain anything by using these in Ada as opposed to, say, Fortran
or C? My point being that, while Ada certainly has its uses, they would
appear to be largely disconnected from mathematical programming. Yes,
one could write something like the Mathematica kernel in Ada. But there
would be no point to doing so. I realize this is not an issue you
raised. I'm simply trying to give examples of how different are Ada-type
considerations and those that underly Mathematica.
Mathematica, by way of contrast, was not designed with full semantic
specification in mind. A few of the main design goals were:
Powerful mathmatical functionality.
A powerful, flexible programming language.
Ability to extend the language e.g. for Front-end representation
purposes.
An ability to explain "most" of the "common" uses in terms that, when
possible, are not burdened by jargon.
Note that the complexity of the language, and for that matter even the
basic syntax, bring it well beyond the level of ADA. A less complete
specification of Mathematica is a part of the price paid for this level
of complexity. To give another example of the different levels of
complexity, the resources we at WRI throw at testing the Mathematica
kernel dwarfs that which we used to assess the reliability of the Ada
system on which I worked. This is in part a reflection of the gradual
maturation of software testing. But it also serves as evidence of the
vastly greater difficulty in assessing Mathematica's level of
reliability.
> 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
C is a much simpler (though of course quite powerful) language. Moreover
it has been through ANSI. That it should have more or less "complete"
specification, while Mathematica does not, can hardly be a surprise.
Over the past three weeks or so you have raised some issues with bugs
and documentation lapses involving the Mathematica pattern matching
facility. Let me say a few words about this. I have no doubt but that
you have found several legitimate anomalies either in the form of bugs
or un(der)documented features. But to what end? Do they approach a level
of severity worthy of note?
Let me give some background. I have done some amount of programming in
Mathematica. Most of NSolve, for example, I wrote in Mathematica. Over
the past several years I have written a few hundred responses to
MathGroup questions, the majority of which include some Mathematica
code. I have almost never run across the problems you note (and in the
rare exceptional cases, have of course resorted to alternatives that
elude the trouble, which you may take as a tacit disagreement with your
claim that such suggestions have little merit). These anomalies simply
does not arise with any frequency in the sort of day to day technical
programming I have done, and I would claim to have tackled a fair range
of programming problems.
There are of course large thorny areas in the Mathematica kernel. I'll
name a few that have caused me to lose sleep.
(1) Code reentrancy e.g. stable behavior when one enters a dialog
subsession.
(2) Robustness in handling interrupts. This can be especially
problematic if "temporary" data structures are utilized and need to be
cleared.
(3) Behaving well when large memory grabs arise.
(4) Getting several of the mathematical functions to behave for
problematic input.
(5) Striking a reasonable balance the need for correct results and the
need for reasonable speed.
(6) Fixing code that relies on time constraints so that the Mathematica
kernel does not give platform and/or session dependent results.
Vagaries of the pattern matcher are not on my radar. If they cause you
to lose sleep, I suppose this is unfortunate. You might wish to provide
some examples where use of misbehaved and/or underspecified patterns has
caused trouble for you. The anomalies in and of themselves do not rise
to "must fix" status, especially when faced with limited developer
resources and the need for appropriate triage.
To respond to an implied question in your comparison with Ada's
developers, I'll remark that those of us who develop Mathematica are
also fairly smart.
Daniel Lichtblau
Wolfram Research
- Follow-Ups:
- Re: Re: New version, new bugs
- From: Dr Bob <drbob@bigfoot.com>
- Re: Re: New version, new bugs
- References:
- Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Re: New version, new bugs