Replace and ReplaceAll -- simple application
in [Mathematica]
|
From: David Park on 1 Jan 2010 05:33 Replying to your two emails Tony. I agree with you that there are problems (or we might say challenges!) but I disagree with you on the identification of the problems and the solutions. You see the problem in WRI trying to do too much and Mathematica being too difficult to learn with all its features. You see the solution in a pared down Mathematica, perhaps something more like a super-graphical-calculator, and better documentation. I see the challenges differently. I'm really enthusiastic about Mathematica because I see it as a revolutionary medium that allows one to write literate mathematical documents with all the power of Mathematica behind the document. Such documents have tremendous advantages over the present practice. They have a large amount of self-proofing; they create generated knowledge in the form of definitions and routines; they can be much more expressive with all the active and dynamic capabilities of Mathematica. It may take a while for this concept to be taken up by the majority of users but I am certain it will eventually win through because of its great advantages. Obviously, I wouldn't want a pared down Mathematica. That would destroy the prospects. I really don't want an application that is just a super-calculator or a programming language. I want to be able to write, communicate AND do math with it. I see the principal problem as being education and acceptance of the application. One can't just buy Mathematica off the bit-server and start using it productively. We didn't learn how to write literate essays in a week. We actually had years of schooling in the use of our language. We can't just add mathematics and the use of Mathematica in a week - especially with graphics and dynamic presentations. Mathematica may have its quirks, but most languages have their quirks also. We just have to learn about them and practice. Students who might be headed toward technical careers should really be starting in early secondary school. That's the real problem! It isn't sufficient for students to get to university, illiterate in mathematical writing, and just modify examples provided by the professor. They have to be able to think with Mathematica on their own. It isn't sufficient to do calculations without integrating them with textual discussion. (Unless you're a super genius that is.) By the time students get to university they should know the basic syntax and usage of Mathematica. They should know how to use Help. They should know how to write definitions and routines in good style. They should know how to do reasonable graphics and some dynamics. They should know how to write packages. They should have written a few mathematical essay notebooks using sectional headings and textual discussion. A second major problem is that Mathematica notebooks should be able to be read (but not written) by anyone. I think that WRI is not oblivious to the problem and it might get solved. Another problem is the cost and acceptance of Mathematica. Some people in academia resent the commercial status of Mathematica. I think this is unfair because there are LOTS of commercial products that have near monopolies in various educational niches. But the WRI use restrictions, licensing practices, and cost, do present barriers. I don't know what the answer to these problems are, but surely there are answers. Finally, this whole discussion got started with the behavior of 1., -1., I and -I, and pattern matching. Whether or not this behavior could be improved, anyone who has had an even half-way good education in Mathematica knows that looking at the FullForm is the way to diagnose pattern matching problems. And students should learn early not to mix approximate numbers or units into symbolic equations. And they should also learn early that Conjugate and ComplexExpand is the general method for taking complex conjugates. These are far more educational issues than they are Mathematica issues. David Park djmpark(a)comcast.net http://home.comcast.net/~djmpark/ From: AES [mailto:siegman(a)stanford.edu] In article <hhf5kg$go6$1(a)smc.vnet.net>, Murray Eisenberg <murray(a)math.umass.edu> wrote: [Re documentation issues and I->-I] > Only gathering usage statistics, or having a focus group of users trying > stuff, might suffice to escalate some issues to the point of requiring > more prominent warnings. 1) Fully agree. My understanding is that many software vendors (and hardware equipment vendors, for that matter), at least the larger ones, do exactly this, systematically and extensively, on their products, and especially the interfaces to their products. I have no idea whether Wolfram does any of this or not. 2) On this point let's note that, to many users, the _interface_ to Mathematica -- what the user has to (learn to) type in, to get useful results out -- is the most important (and sometimes frustrating?) part of the product. What Mathematica does or can do -- it's "capabilities" as contrasted to its interface -- is of course also of primary importance; and Mathematica seems to rank very highly on this criterion. It's the user interface where many if not most of these problems arise. 3) And let's note the explicit assertions by Conrad Wolfram (in the screencasts/video gallery on the Wolfram web site), and by others, that Mathematica is intended to be a program that does *all* tasks, for *all* users, in a *single* application (with 'all' and 'single' taken very broadly). This means, necessarily: a) A *very* complex interface (with, in particular, a _huge_ vocabulary). b) And at the same time, a very broad and diverse set of users, with very different levels of education and knowledge and experience. And this may mean that this basic goal and approach of the Wolframs' for Mathematica may not be realistic or possible. The "focus groups" you suggest will have to be very diverse in makeup, corresponding to the huge diversity of the proposed users; and each different group of users will have different interface (and documentation) needs, and want very different things. If the Wolframs' are going to insist on following this path, then user documentation -- easily accessible, brilliantly designed documentation, readily available in different forms oriented to the needs of different users -- is the primary thing they have to focus on. Thus far, so far as I can see, Heikki Ruskeepaa may be the only person on the planet who recognizes this and does something about it. Mathematica's own documentation gets maybe a C- on this score. And simply expecting ordinary users to learn ever more arcane CAS concepts and terminology in order to use Mathematica effectively seems as unrealistic as it is absurd.
From: Bill Rowe on 1 Jan 2010 05:39 On 12/31/09 at 3:13 AM, fateman(a)cs.berkeley.edu (Richard Fateman) wrote: >No, I think it is not masochism. It is an attempt to provide a >useful to answer questions that come up from time to time from >people who would otherwise dismiss a CAS as useless and stupid >bedause they find unexplainable (to them) behavior. >Some posts explains that a CAS really could do the mathematically >obviously correct thing, even if it appears they do not. But using pattern matching to do replacements is not doing mathematics. >They may point out that a group of fans insists that the right thing >for users to do is to discard their mathematically obvious >understanding and study programming. >But when the weight of all mathematical obviousness is on one side, >and the developers could fix a bug but simply refuse to do so, then >that is simply stubbornness. Do you have some definition for "bug" other than performance in a manner different than documented? That is, failure of any software to do what a user expects is certainly not a bug if that is what the software is documented to do. The key problem here is a novice user of Mathematica might think of using replacement rules as doing mathematics. That simply isn't the case. And since replacing one thing with another is not mathematics, insisting the result makes sense mathematically simply isn't a realistic expectation.
From: Richard Fateman on 2 Jan 2010 05:04 Bill Rowe wrote: .... > > Do you have some definition for "bug" other than performance in > a manner different than documented? Yes. > That is, failure of any software to do what a user expects is > certainly not a bug if that is what the software is documented > to do. False. Here's why. By your definition, no program has a bug if the programmer asserts that the program, by virtue of being written in a high-level language, is its own readable documentation. Therefore anything that the program does is documented by its own code and therefore is not a bug. or in the immortal words of Peewee Herman "I meant to do that". > > The key problem here is a novice user of Mathematica might think > of using replacement rules as doing mathematics. Maybe he was confused by the title "Mathematica -- A System for Doing Mathematics", and thought that Mathematica was a system for doing mathematics. That simply > isn't the case. Apparently you thought that Mathematica was "A system for doing rule-based syntactic transformations on FullForm expressions which may or may not correspond to what is displayed" And since replacing one thing with another is > not mathematics, insisting the result makes sense mathematically > simply isn't a realistic expectation. TaDa. I couldn't have expressed it better myself. Insisting that the results of a transformation is mathematically consistent, "isn't a realistic expectation." Which, in my view, demonstrates the existence of a bug. I suppose one could try to determine who is right by a survey, or ask people in the street what they think. RJF > >
From: DrMajorBob on 2 Jan 2010 05:06 > ...since replacing one thing with another is > not mathematics... It's what a mathematician spends much of his time doing, I'd say. Bobby On Fri, 01 Jan 2010 04:39:36 -0600, Bill Rowe <readnews(a)sbcglobal.net> wrote: > On 12/31/09 at 3:13 AM, fateman(a)cs.berkeley.edu (Richard Fateman) > wrote: > >> No, I think it is not masochism. It is an attempt to provide a >> useful to answer questions that come up from time to time from >> people who would otherwise dismiss a CAS as useless and stupid >> bedause they find unexplainable (to them) behavior. > >> Some posts explains that a CAS really could do the mathematically >> obviously correct thing, even if it appears they do not. > > But using pattern matching to do replacements is not doing mathematics. > >> They may point out that a group of fans insists that the right thing >> for users to do is to discard their mathematically obvious >> understanding and study programming. > >> But when the weight of all mathematical obviousness is on one side, >> and the developers could fix a bug but simply refuse to do so, then >> that is simply stubbornness. > > Do you have some definition for "bug" other than performance in > a manner different than documented? > That is, failure of any software to do what a user expects is > certainly not a bug if that is what the software is documented > to do. > > The key problem here is a novice user of Mathematica might think > of using replacement rules as doing mathematics. That simply > isn't the case. And since replacing one thing with another is > not mathematics, insisting the result makes sense mathematically > simply isn't a realistic expectation. > > -- DrMajorBob(a)yahoo.com
From: Andrzej Kozlowski on 3 Jan 2010 03:36
I would say that it only looks like that. What mathematicians (or at least "pure mathematicians") usually do, is to study various relations between object "up to some sort of equivalence relation". This can look like syntactic replacement but actually is quite different - it does not allow you to blindly replace one thing by another, for example. The best example in Mathematica that comes to my mind is using PolynomialReduce to do "mathematical replacement". This replaces polynomials by simpler ones which are equivalent up to division by a specified ideal. There have been over the years many posts by Daniel Lichtblau explaining how to do that. This sort of thing is exactly what mathematicians do and is quite different from syntactic replacement. The kind of changes that have been proposed to syntactic replacement would not help at all with this sort of mathematical replacement at all, so the only effect would be to sow confusion where there is clarity now (on the programming side) without making it in the last easier for anyone trying to do serious mathematics. Andrzej Kozlowski On 2 Jan 2010, at 19:06, DrMajorBob wrote: >> ...since replacing one thing with another is >> not mathematics... > > It's what a mathematician spends much of his time doing, I'd say. > > Bobby > > On Fri, 01 Jan 2010 04:39:36 -0600, Bill Rowe <readnews(a)sbcglobal.net> > wrote: > >> On 12/31/09 at 3:13 AM, fateman(a)cs.berkeley.edu (Richard Fateman) >> wrote: >> >>> No, I think it is not masochism. It is an attempt to provide a >>> useful to answer questions that come up from time to time from >>> people who would otherwise dismiss a CAS as useless and stupid >>> bedause they find unexplainable (to them) behavior. >> >>> Some posts explains that a CAS really could do the mathematically >>> obviously correct thing, even if it appears they do not. >> >> But using pattern matching to do replacements is not doing mathematics. >> >>> They may point out that a group of fans insists that the right thing >>> for users to do is to discard their mathematically obvious >>> understanding and study programming. >> >>> But when the weight of all mathematical obviousness is on one side, >>> and the developers could fix a bug but simply refuse to do so, then >>> that is simply stubbornness. >> >> Do you have some definition for "bug" other than performance in >> a manner different than documented? >> That is, failure of any software to do what a user expects is >> certainly not a bug if that is what the software is documented >> to do. >> >> The key problem here is a novice user of Mathematica might think >> of using replacement rules as doing mathematics. That simply >> isn't the case. And since replacing one thing with another is >> not mathematics, insisting the result makes sense mathematically >> simply isn't a realistic expectation. >> >> > > > -- > DrMajorBob(a)yahoo.com > |