Replace and ReplaceAll -- simple application
in [Mathematica]
|
From: DrMajorBob on 3 Jan 2010 03:37 It's beating a dead horse, but I gotta mostly agree with Richard's sentiments, here. Mathematicians spend much of their time doing substitutions, so it doesn't wash to say substitution is syntactical, not mathematical. That said, we'd have to unravel a great deal, if we stopped using FullForm to explain pattern matching. Bobby On Sat, 02 Jan 2010 04:04:36 -0600, Richard Fateman <fateman(a)cs.berkeley.edu> wrote: > 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 > >> >> > -- DrMajorBob(a)yahoo.com
From: Bill Rowe on 3 Jan 2010 03:40 On 1/1/10 at 9:16 AM, fateman(a)cs.berkeley.edu (Richard Fateman) wrote: >Bill Rowe wrote: ... >>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. I agree there are those who lack sufficient integrity/honesty to admit error claiming whatever result is obtained is what was intended in the first place. But, I don't agree the existence of such people shows my definition above is equivalent to saying "no program has a bug". In short, your hypothetical is rather inane. >>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" I am very much aware something as complex as Mathematica is not adequately defined by a simple one line statement. That is Mathematica is more than simply a system for doing mathematics or a system for doing rule-based syntactic transformations. If I was forced to define Mathematica is a simple one line statement it would be something along the lines of "Mathematica is a general purpose programming language with an emphasis on doing mathematics. " If Mathematica was limited to doing just valid mathematics, it would be significantly less powerful and useful than it is currently. >>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. This would be a logical conclusion *if* the only allowed transformations where mathematical transformations. But since Mathematica provides the capability of doing far more than just mathematical transformations, it is very much unrealistic to expect a non-mathematical transformatino to be mathematically valid. And the fact such non-mathematical transformations exist certainly is a design feature not a bug. >I suppose one could try to determine who is right by a survey, or ask >people in the street what they think. And what would this accomplish? If I walk out to the street and ask those I encounter, my expectation is the overwhelming response would be "What is Mathematica?". Your entire point seems to be Mathematica should only return mathematically valid results and anything else is a "bug". This point ignores the fact that Mathematica is far more than a system for doing mathematics and consequently isn't a valid point.
From: AES on 13 Jan 2010 05:58 In article <hhkj1a$4tl$1(a)smc.vnet.net>, Murray Eisenberg <murray(a)math.umass.edu> wrote: > That's an instructive example on the point being discussed. As you note, > > R + I w L /. I -> -I > > works "as expected". But so does: > > I /. I -> -I > > What does NOT work is either of: > > R - I w L /. I -> -I > -I /. I -> -I > What you say is certainly correct -- but I believe it bypasses the core point. An individual with a physics background may manipulate the impedance for an RL circuit by writing R + I w L /. I -> -I while one with an EE background may very naturally write this as R + I 2 Pi f L /. I -> -I (or, in many textbooks, R + 2Pi I L /. I -> -I) And, **one of these will get a wrong answer**. [And if this "erroneous" input is buried in a sequence of compound expressions or definitions early in a notebook, that error may not even become apparent until hours later, way down in the notebook, in the form of bizarre and puzzling behavior in some much more complex derived result.] Same problem for two individuals, one of whom likes to use half width at half maximum linewidths and writes a complex lorentzian as 1 + I (x-x0)/dxHwhm and another who likes full width at half max linewidth, and so writes 1 + 2 I (x-x0)/dxFwhm R + I w L/.I->-I R + 2 Pi I f L/.I->-I 1+I ((x-x0)/deltax)^2/.I->-I 1+I (2(x-x0)/deltax)^2/.I->-I
From: Murray Eisenberg on 14 Jan 2010 05:49
An interesting pair of examples. But users of any CAS system just have to learn the basic rules -- the relevant one here being that replacements are made on the FullForm, so that I, that is, Complex[0,1] does NOT appear in the FullForm of the original expression (before the replacement is attempted) in the second of the two examples! The only "cure" for this I can see is for Mathematica's fundamental evaluation sequence to be radically changed, so that 2 I, meaning 2*I, does NOT first get replaced automatically by Complex[0,2]. The consequences of such a radical change could cascade throughout the entire system, with most unwanted effect. So one simply has to learn how things work here, and teach them to others. I don't think any number of new "inconvenient" examples or fulminations against the state of things here is going to change that state. On 1/13/2010 5:58 AM, AES wrote: > In article<hhkj1a$4tl$1(a)smc.vnet.net>, > What you say is certainly correct -- but I believe it bypasses the core > point. An individual with a physics background may manipulate the > impedance for an RL circuit by writing > > R + I w L /. I -> -I > > while one with an EE background may very naturally write this as > > R + I 2 Pi f L /. I -> -I > > (or, in many textbooks, R + 2Pi I L /. I -> -I) > > And, **one of these will get a wrong answer**. -- Murray Eisenberg murray(a)math.umass.edu Mathematics & Statistics Dept. Lederle Graduate Research Tower phone 413 549-1020 (H) University of Massachusetts 413 545-2859 (W) 710 North Pleasant Street fax 413 545-1801 Amherst, MA 01003-9305 |