MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

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/
> 




  • Prev by Date: Re: Re: coloring eveerything outside a circle
  • Next by Date: From Spline to Arc
  • Previous by thread: Re: scope all wrong? in Mathematica 4.1
  • Next by thread: Re: scope all wrong? in Mathematica 4.1