Re: scope all wrong? in Mathematica 4.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg31874] Re: [mg31827] scope all wrong? in Mathematica 4.1*From*: Richard Fateman <fateman at cs.berkeley.edu>*Date*: Sat, 8 Dec 2001 05:51:53 -0500 (EST)*Organization*: University of California, Berkeley*References*: <FD567E2C-EAC9-11D5-93E0-00039311C1CC@tuins.ac.jp>*Sender*: owner-wri-mathgroup at wolfram.com

Andrzej Kozlowski wrote: > > >> If you try to build a robust system of substantial complexity, >> the tools must not have hidden flaws. >> > Well, to me at least, these remarks show that you are engaging in > rhetoric designed to discredit Mathemaitca or Wolfram rather than an > objective argument. You know perfectly well that non-transitive notions > of "equality" are quite common in mathematics dealing with approximate > and uncertain quantities, indeed there are a whole subjects (for example > something called "fuzzy geometry") based on such notions. I don't know about fuzzy geometry, and I certainly do not encourage people to compare for equality of floating point numbers except in a very limited sense. (Typically a convergence criterion that says "did the last iteration change the result AT ALL" ... but even so this is generally not a good idea). But that the programming language itself would have a notion of equality that was not transitive... this is bizarre, and I think unique to Mathematica. In fact you > yourself have pointed out that comparisons of this kind between > approximate quantities ought to be avoided. In fact Mathematica has a > strict notion of equality (SameQ) and this worn argument is just a red > herring. As for the other point, well Mathematica is clearly a pattern > matching language with a functional syntax, which makes it easier to > use, but may be misleading to those who have not studied it carefully. > But one can no more blame it for not being like Lisp as for not being > like C or Java. The notation f[x_]:=... is commonly thought of, and used, as though it were (in Lisp equivalent notation) (defun f(x) ...) This is, as you say, potentially misleading. Especially since very few people DO study it carefully! I certainly think of f[x_]:= as a function definition, and so I am surprised when it fails to work that way. Only then do I go back and say, OH, as a pattern, it is doing something else. > >> >> I can do this in Lisp, since Macsyma has those pieces, though these >> parts of Mathematica are probably OK. Well actually, the evaluation >> of integrals has problems... > > > Presumably you would argue that the reason why Macsyma never really > managed to gain any popularity outside a few departments of mathematics > or computer science (it was there when I was beginning to teach in the > US, before Mathematica, yet today it seems to be even less well known > than in those days) is somehow the result of failure of people to > realize its superior excellence. But claims like this are common, > particularly by the authors of the less successful products. Actually I don't blame users at all. There is a marketplace for scientific software, and they made choices based on their criteria. I don't believe the "customer is always right" but certainly "the customer is important". Macsyma did not succeed because customers (users) did not buy it. If customers think that Mathematica is better than it really is, then it is a success in marketing. I think that the choice between Maple and Mathematica is made --sometimes quite correctly-- on the basis of price. I think part of the failure of Macsyma to gain great popularity is political and financial. That is, MIT sold the exclusive commercial rights to Symbolics Inc. For many years they refused to sell the program except on their own special hardware. Not on Vaxes or on Suns. Why did they buy Macsyma from MIT? Apparently so that their rivals in the Lisp Machine business (LMI) would not buy it and have a competitive advantage. Thus part of the blame is (a) MIT and its decision-makers (Mike Dertouzos and Joel Moses and their lawyers; (b) Arthur D. Little Inc, the "deal-maker" who chose Symbolics, Inc. and (c) Symbolics Inc. management. There are differences between systems, and I have written rather critically of Macsyma (also). The disappointment is that the lessons of Macsyma were not understood in the construction of Maple and Mathematica. Instead, the same mistakes were implemented. It will be interesting to see if the free version of Macsyma will have an increasing impact, now that commercial Macsyma seems to have disappeared. > >> >> >> I actually disagree. Look at the disclaimer at the front of the book >> that says not to use Mathematica for computations involving life, or >> property. >> >> Regards >> RJF >> >> > > Hm, are you saying that you would be willing to accept personal > liability for any damage to life or property that could result from a > bug in Macsyma? If so I find it very admirable since I am not aware of > any other software developer who has the courage to take this attitude. No, I would not accept personal liability for errors. But there is a difference between disclaiming responsibility for errors, and what SW says: "The author, WRI and AW do not recommend the use of the software described in this book for applications in which errors or omissions could threaten life, injury or significant loss." (added in the second edition of The Book). I wonder how many other software system authors specifically recommend AGAINST using their software? I can't find any such disclaimers in the reference manuals for other packages, but maybe I have not looked enough. RJF > > > Andrzej Kozlowski > Toyama International University > JAPAN > http://platon.c.u-tokyo.ac.jp/andrzej/ >