Re: New version, new bugs
- To: mathgroup at smc.vnet.net
- Subject: [mg43232] Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Date: Wed, 20 Aug 2003 22:25:43 -0400 (EDT)
- References: <bhd9a7$roa$1@smc.vnet.net> <200308160653.CAA25919@smc.vnet.net> <bht3r8$n45$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Daniel Lichtblau wrote:
>
> 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.
>
>
>
> 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
First of all, I never intended to imply anything about Mathematica developers; I
apologize if it sounded that way. 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'.
And I knew I shouldn't have started all this comparison thing! Although I can
object that abstract data types, generic packages and many other things from more
traditional languages are far from being trivial, and so I don't think that
Mathematica is above reproach on account of it being so complex, but still it
seems like comparing inches to pounds.
I certainly don't propose to rewrite Mathematica kernel in some other language or
anything of the sort. Although I do think that the Mathematica language itself
isn't quite up to the standards I'd expect of a programming language. For
example, here's what the notes for Compile say: "The number of times and the
order in which objects are evaluated by Compile may be different from ordinary
Mathematica code". So I was wrong when I said that the behaviour of
Compile[
{},
Module[
{L={10,20,30},a=1},
L[[a++]]++;
Append[L,a]
]
][]
was a bug, because there's this major disclaimer, but that's a weak consolation.
In some other situation Compile might decide to evaluate AppendTo an extra couple
of times -- a construct like L2=AppendTo[L,elem] is quite reasonable and the
right-hand side of this expression then falls under the disclaimer's conditions
too. My point here is that it's taking the idea of 'less complete specifications'
a bit too far. Dr.Bob in a message in this thread used the phrase 'all bets are
off' and in this situation it might turn out to be disturbingly close to reality.
Or consider (sorry, pattern matching again)
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.
I think the inconsistency between named parameters and Slot parameters is also a
good example:
In[1]:=
Function[y,Module[{x=1},y+x]] @ x
Function[Module[{x=1},#+x]] @ x
Out[1]=
1+x
Out[2]=
2
memorize this difference, there are no general principles that can be applied to
deduce how it'll work; and second, it can lead to very untrivial and elusive
errors. An experienced programmer will have no problems working it out, but is
that a good argument?
Another example is the way Rule and Set treat scoping:
In[1]:=
Block[{s = 1}, Module[{s = 2}, s_ -> {s, t}]]
Block[{s = 1}, Module[{s = 2, t}, s_ -> {s, t}]]
Out[1]=
s_ -> {1, t}
Out[2]=
s$_ -> {s$, t$38}
In the first example s on the Rule's right-hand side is evaluated, but which s is
it? Mathematica decides that it's not Rule's local s or Module's s$38 but the
top-level s, so it evaluates to 1. Now in the second example renaming occurs and
s$ evaluates to itself. Since we can't tell when the renaming is going to happen
(we only know that it is possible), there's no way in principle to predict the
result. I think this can't be a good thing.
Another example: if I write something like
f[x_,y_]:=Module[
{g},
g[xx_]:=Module[{yy=1},xx+yy];
g[x]+y
]
then I should always remember that x and y are 'reserved' (at least, if they are
supposed to have numeric values) and cannot be used in the inner definitions.
Nesting Modules is a good programming technique that leads to well-structured
code but its usefulness is seriously undermined by this feature of Mathematica's
scoping.
Maybe all these are small things, but they're very fundamental -- I'm talking
about the language itself, in one way or another it does affect the programming.
And since we moved from single bugs to deeper things, they probably just can't
have 'must fix' status, but they might be a serious source of bugs, so to speak
(actually I sent my buglist to WRI Technical Support recently and I think quite a
lot of things in the list are genuine bugs). I cannot object anything to all this
just not being a priority...except maybe one thing. Who knows, probably the large
number of more 'mathematical' bugs does have something to do with the development
tools?
Maxim Rytin
m.r at prontomail.com
- References:
- Re: New version, new bugs
- From: Maxim <dontsendhere@.>
- Re: New version, new bugs