Replace and ReplaceAll -- simple application
in [Mathematica]
|
From: DrMajorBob on 31 Dec 2009 03:20 Well... I was (and am) of two minds on the issue. I posted the opinion that treatment of this could be better, and I posted the opinion (fact) that -1. is an atomic object, so it has no sub-parts (such as 1.). Truly, some issues have been argued to death. But not everyone was here to see that, and I see no harm in discussing them again, from time to time. Nobody's forcing anyone to participate. Bobby On Wed, 30 Dec 2009 03:23:31 -0600, Andrzej Kozlowski <akoz(a)mimuw.edu.pl> wrote: > What I find kind of impressive is that there are people who find it > amusing to keep posting essentially the same posts for about two decades > and this despite the fact that they are being completely ignored by the > developers (and there is no reason to think that anything will ever > change in this respect). Masochism? > > I try to move with the times so what concerns me is that my Front End is > crashing too often. > > Andrzej Kozlowski > > > > On 29 Dec 2009, at 15:18, DrMajorBob wrote: > >> True enough, I'd say. >> >> Bobby >> >> On Mon, 28 Dec 2009 03:57:38 -0600, Richard Fateman >> <fateman(a)cs.berkeley.edu> wrote: >> >>> Scot T. Martin wrote: >>>> The problem is that "-1." is not "1". >>> >>> And furthermore, this bug has been declared a feature. And defended, >>> repeatedly. Just as I does not occur in -I. >>> It can be fixed, should be fixed, and has been fixed in other CAS. >>> >> >> >> -- >> DrMajorBob(a)yahoo.com >> > > -- DrMajorBob(a)yahoo.com
From: danl on 1 Jan 2010 05:32 > 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. It pays to keep in mind that very few users require more than a modest percentage of the functionality of a Mathematica, in order to make it useful for their work. I probably need to know a bit more than most, and I'll be generous (to myself) and guess I have working familiarity with maybe 10 percent of the program's capabilities. > 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. Documentation can always use improvements. That notwithstanding, I have consistently found that most basic usage of most functionality unfamiliar to myself is documented sufficiently well that the job at hand can be done. Obviously I do not know if this holds for all aspects of the program. And clearly I cannot claim to have the same perspective, in reading documentation, as a novice user. But from what I have seen e.g. in work submitted to demonstrations.wolfram.com, users at all levels seem to figure out what is needed to get the job done. Something else I'll observe is that nothing in new functionality development would require users to "learn ever more arcane CAS concepts..." beyind what earlier Mathematica utilized. This is axiomatic: nothing requires one to learn about new functionality, because the functionality of years past is, in the vast majority of cases, unaltered. The point is that the new development of Mathematica (and other software) is motivated, often, by perceived needs of existing and potential user bases. This rarely if ever requires other users to learn the new things in order to use Mathematica effectively. It simply gives more tools to those who may wish to use them. Daniel Lichtblau Wolfram Research
From: Murray Eisenberg on 1 Jan 2010 05:33 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 Each pair of results is consistent within itself, whereas the second pair seems on first exposure to be inconsistent with the first pair. Evidently a case of unwarranted generalization by the "naive" user, worthy of further digging: how does ReplaceAll really work? (I say "naive" here without intending any negative connotation!) In my experience, eventually the same sort of dissonance will arise with any system where one is using only heuristics to accomplish tasks rather than the actual parsing/evaluation rules of the language. Not a moment for grief or cause for complaint about inconsistencies, but rather an opportunity for learning more. Language designers might claim, "Well, that's just the way it is." But that's really an inadequate response. Yes, one does eventually just have to learn and accept the underlying principles and rules. Still, there are interesting cognitive and pedagogical issues here (but NOT issues of flawed language design). But enough of "an I for an I" for today: time to celebrate the approach of New Year! P.S. I'm not sure what MathWorld is supposed to do with this: MathWorld is about mathematics, not Mathematica; it just happens to have some Mathematica code available. I would not at all expect MathWorld to instruct me on using Mathematica. AES wrote: > In article <hhf5kg$go6$1(a)smc.vnet.net>, > Murray Eisenberg <murray(a)math.umass.edu> wrote: > > [Re the I -> -I problem in particular:] > > ... it's very tempting to note that these > tFunc's contain nothing but purely real circuit elements (R's. L's and > C's, or masses and spring constants, or whatever), and I. > > And a quick test confirms that the rule {a->-a} does what it's supposed > to (whether or not a has a minus sign in front of it). Or, a quick test > confirms that I->-I properly converts R + I w L into R - I w L. Why > shouldn't it??? It just does what you'd expect a global find and > replace to do, or what you'd do "by hand" -- right? > > Take a look at the Mathworld entries for "phasor" and "transfer > function" and see how far down you'd have to dig to get an explicit > warning that the previous paragraph is misleading. (And note that the > entry for "Phasor" does not contain a "SEE ALSO:" for the term "Complex > Conjugation", and the link to that term within the text does not -- so > far as I can see -- give any hint the the rule I->-I will fail for an > expression containing -I.) -- 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
From: DrMajorBob on 1 Jan 2010 05:37 All true... but I know about the Conjugate function without ever (as far as I recall) having a need for it. Mathematica users should expect such a function to exist, besides, and it's easy to find if you're looking for it. One certainly might, of course, want to see a function's conjugate without a series of operations like: expr = (R + I L) (R - I w L); Factor(a)ComplexExpand@Conjugate(a)expr (-I L + R) (R + I L w) ....and that sequence won't work in general, anyway. If we want to see that, we might have to make the I -> -I substitution manually. For instance, expr /. {-I -> I, I -> -I} (-I L + R) (R + I L w) That works when the terms are symbolic, but not if the symbols are replaced with constants: expr = (1 + 2 I) (1 - 3 I) expr /. {-I -> I, I -> -I} 7 - I 7 - I That is annoying... that a simple Replace (though not as simple as I -> -I) works for symbols, but not for numbers. The following works for numbers AND for symbols, and it's no more complicated nor less intuitive, I suppose: expr = (1 + 2 I) (1 - 3 I) expr /. Complex[a_, b_] :> Complex[a, -b] 7 - I 7 + I expr = (R + I L) (R - I w L); expr /. Complex[a_, b_] :> Complex[a, -b] (-I L + R) (R + I L w) ....but the right path isn't obvious until we've had this discussion (or something like it). Bobby On Thu, 31 Dec 2009 02:14:13 -0600, AES <siegman(a)stanford.edu> wrote: > In article <hhf5kg$go6$1(a)smc.vnet.net>, > Murray Eisenberg <murray(a)math.umass.edu> wrote: > > [Re the I -> -I problem in particular:] > >> On the other hand, not every possible issue can be addressed immediately >> at the top of documentation just because this or that user happened to >> experience some difficulty with it. >> >> 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. >> >> I wonder how many users in fact experience this issue. > > I'll give you one sizable group. > > Engineering and science students and practitioners, at all levels down > to at least college sophomores and even advanced high school students, > are taught to solve systems of coupled linear differential equations > (e.g., the loop or node equations for linear electrical networks with > current and/or voltage sources, or forcing functions) using the phasor > approach. > > The first step in doing this is of course to replace d^n /dt^n by > (I w)^n (w as shorthand for omega), thereby converting these to coupled > algebraic equations. The next step is then to solve these equations to > obtain a matrix-valued transfer function or scattering matrix, whose > elements contain only *real-valued* parameters (R's, L's and C's in the > electrical circuit case) and I -- elements that look like R + I w L. > > In practice, the instructor and the students do a few problems of this > type by hand, with just one or two variables; define and examine the > poles and zeros of the transfer function; learn about concepts like > resonance and impedance and admittance, and scattering matrices and > input and output ports; and so on. But the instant one goes to anything > more realistic and interesting, with three or more variables, the > algebra and the numerical calculations just become too tedious. > > But, hey, Mathematica is just beautiful for this task. The Solve[ ] > function is perfect for doing the algebra to find the transfer function > -- simple, easy to understand, obvious; and all the elementary Plot > functions (David Park's "set pieces") will give you all the plots you > could ask for. And since the output variables are phasors, e.g. > voltages and currents, vc(t) and ic(t) (generally indexed and often > written with superimposed tildes to indicate that they are complex > variables), you can get numerical results for power flows and energy > densities using notations like p([t_] = Re[vc(t)] Re[ic(t)]. > > But at some point you may want to get analytical formulas as well, e.g. > the modulus and argument of the transfer function from an input to an > output port. And, maybe move on to the ideas of "lossless", that is, > unitary, and Hermitian scattering matrices. At which point, the idea of > the transfer function, call it tFunc, and its complex conjugate, > tFunctStar, become significant. EE students say "v" and "vStar" and "i" > and "iStar" all the time! > > And at that point, if you're focusing on the system properties and not > specific numerical calculations it's very tempting to note that these > tFunc's contain nothing but purely real circuit elements (R's. L's and > C's, or masses and spring constants, or whatever), and I. > > And a quick test confirms that the rule {a->-a} does what it's supposed > to (whether or not a has a minus sign in front of it). Or, a quick test > confirms that I->-I properly converts R + I w L into R - I w L. Why > shouldn't it??? It just does what you'd expect a global find and > replace to do, or what you'd do "by hand" -- right? > > Take a look at the Mathworld entries for "phasor" and "transfer > function" and see how far down you'd have to dig to get an explicit > warning that the previous paragraph is misleading. (And note that the > entry for "Phasor" does not contain a "SEE ALSO:" for the term "Complex > Conjugation", and the link to that term within the text does not -- so > far as I can see -- give any hint the the rule I->-I will fail for an > expression containing -I.) > -- DrMajorBob(a)yahoo.com
From: Noqsi on 1 Jan 2010 05:38
On Dec 31, 1:13 am, Richard Fateman <fate...(a)cs.berkeley.edu> wrote: > 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. I don't see any "mathematical obviousness" to the idea that syntactic replacements involving "I" will have sane mathematical consequences. "I" is explictily present only in a subset of complex number representations. "Root[#1^5 + 1 &, 2]" is a perfectly reasonable complex constant, but syntactic replacement of "I" with "-I" will not produce its conjugate. For mathematically aware manipulations, you need mathematically aware functions, "Conjugate" in this case. Expecting to do this syntactically seems as silly to me as expecting "x/.6->5" to yield "5x/6", or "32/.3->4" to yield "42". |