Re: Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43226] Re: Re: New version, new bugs
- From: Dr Bob <drbob at bigfoot.com>
- Date: Wed, 20 Aug 2003 22:25:25 -0400 (EDT)
- References: <bhd9a7$roa$1@smc.vnet.net> <200308160653.CAA25919@smc.vnet.net> <200308191153.HAA23518@smc.vnet.net>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
Amen, Daniel.
Ada does a lot of much simpler tasks, while Mathematica, in trying to
provide an environment for mathematics, inevitably opens itself to all
sorts of possibilities, some useful and others mystifying.
It's an apple-and-orange comparison.
I was never associated with Ada in my Air Force days, but as of my
retirement in 1995, the requirement to use Ada "for everything" was still a
vague threat, somewhere on the horizon, that most of us ignored (in the
forecasting and simulation business, anyway). We continued to use SAS,
Fortran, and Simscript for modeling and analysis tasks. (I wish
Mathematica had been in the mix!)
I think complete specification is nice to have in a language tool, but the
benefit is overblown. Completely specifying the PROBLEM you're trying to
solve is much harder. That is, if Ada is well specified, fine. But is the
analysis problem you're trying to solve, and the mathematical solution
repertoire, also well specified? (Almost always, no. Real problems grow
and evolve with time, and SHOULD do so.) For anyone who's trying to keep
up with that evolution, a flexible language with many powerful built-in
tools (like Mathematica) is far more useful than a well-specified and
documented language without such tools.
That doesn't mean I'll stop complaining (as I sometimes do) about gaps in
Mathematica documentation. Offsetting advantages make Mathematica an
amazingly useful environment overall, but that doesn't mean we should
simply accept the flaws.
Bobby Treat
On Tue, 19 Aug 2003 07:53:14 -0400 (EDT), Daniel Lichtblau
<danl at wolfram.com> wrote:
> 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
>
>
--
majort at cox-internet.com
Bobby R. Treat
- References:
- Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Re: Re: New version, new bugs
- From: Daniel Lichtblau <danl@wolfram.com>
- Re: New version, new bugs