Replace and ReplaceAll -- simple application
amannuc1
constructs such as "1." in the expressions. I want to convert these to
"1" and thereby eliminate them. However, these examples don't seem to
work. This is Mathematica 7 on OS X.
In[40]:=
Replace[1.(y1-1.yr),1.->1]
Out[40]= 1. (y1-1. yr) (* Nothing happens *)
In[39]:=
ReplaceAll[1.(y1-1.yr),1.->1]
Out[39]= y1-1. yr (* Only first one is replaced *)
Any help is appreciated. Thanks.
-Tony
Bob Hanlon
expr = 1. (y1 - 1. yr);
expr /. x_?NumericQ -> Round[x]
y1-yr
expr // Rationalize
y1-yr
expr /. x_ :> Rationalize[x]
y1-yr
Bob Hanlon
---- amannuc1 <Anthony.J...@jpl.nasa.gov> wrote:
=============
Scot T. Martin
Also, you need to use the level specification.
In: Replace[1. (y1 - 1. yr), {1. -> 1, -1. -> -1}, Infinity]
Out: y1-yr
David Park
Look at the FullForm.
expr // FullForm
Times[1.`,Plus[y1,Times[-1.`,yr]]]
There is a 1. And a -1. and you must have a replacement for each of them.
expr /. {1. -> 1, -1. -> -1}
y1 - yr
expr /. a : (1. | -1.) -> Sign[a]
y1 - yr
Another possible construction is:
expr // Rationalize
y1 - yr
I don't know how you arrived at the initial expression, but if possible you
could try to enter only exact expressions (avoiding numbers with decimal
points, called approximate numbers). Enter approximate numbers only when you
are absolutely forced to. Try to keep all equations symbolic, free of
approximate numbers. Also keep them free of units. Then once you have solved
the equations (if you can do that) then substitute data values with
approximate numbers and units.
David Park
djm...@comcast.net
http://home.comcast.net/~djmpark/
DrMajorBob
y1 - yr
Bobby
On Sat, 26 Dec 2009 18:06:43 -0600, amannuc1
<Anthony.J...@jpl.nasa.gov> wrote:
> I am doing some manipulations in Mathematica and end up with
> constructs such as "1." in the expressions. I want to convert these to
> "1" and thereby eliminate them. However, these examples don't seem to
> work. This is Mathematica 7 on OS X.
>
> In[40]:=
> Replace[1.(y1-1.yr),1.->1]
> Out[40]= 1. (y1-1. yr) (* Nothing happens *)
>
> In[39]:=
> ReplaceAll[1.(y1-1.yr),1.->1]
> Out[39]= y1-1. yr (* Only first one is replaced *)
>
> Any help is appreciated. Thanks.
>
> -Tony
>
AES
"David Park" <djm...@comcast.net> wrote:
> I don't know how you arrived at the initial expression, but if possible you
> could try to enter only exact expressions (avoiding numbers with decimal
> points, called approximate numbers). Enter approximate numbers only when you
> are absolutely forced to. Try to keep all equations symbolic, free of
> approximate numbers. Also keep them free of units. Then once you have solved
> the equations (if you can do that) then substitute data values with
> approximate numbers and units.
After pondering this for a while, I'd agree that sounds like good advice.
But, there are still lots of opportunities for confusion with "/." and
rules. The definition of "/." says:
ReplaceAll (Built-in Mathematica Symbol)
expr /. rules applies a rule or list of rules in an attempt to
transform each subpart of an expression expr.
ReplaceAll looks at each part of expr, tries all the rules on it, and
then goes on to the next part of expr. The first rule that applies to
a particular part is used; no further rules are tried on that part,
or on any of its subparts.
So try
In[1]:= 1./.{1.->1}
Out[1]= 1
In[2]:= -1./.{1.->1}
Out[2]= -1.
In[3]:= a/.{a->b}
Out[3]= b
In[4]:= -a/.{a->b}
Out[4]= -b
Hmmm -- apparently "-1." is _one_ part (or subpart), but "-a" is _two_
subparts.
I suppose the point is that "-1." is a number (and hence a single thing,
or single part, that has to be matched), while "-a" is (somehow!) two
things or two parts -- an operator, and a symbol? -- that are tested
separately.
Interestingly, a further test shows that "- 1." (note space) is also a
single part in an expression -- and is in fact matched by "-1." (no
space) in a rule.
And "-(1.)" is also matched in the same way by "-1." (which seems an
unfortunate behavior; writing it this way should clearly separate the
operator "-" from the approximate number).
These behaviors clearly account for my difficulties with rules involving
I and -I.
But if there's a formal or rigorous definition of "part" or "subpart"
anywhere in the Mathematica documentation, I have yet to find it.
Richard Fateman
> 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
Bobby
On Mon, 28 Dec 2009 03:57:38 -0600, Richard Fateman
<fat...@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.
>
AES
Richard Fateman <fat...@cs.berkeley.edu> wrote:
I'll defer to Richard Fateman (and/or other computer algebra experts) as
to whether this general behavior (!! especially with respect to -I !!)
is a bug that should be fixed, or a feature.
But if it's gonna be considered a feature in Mathematica, I'd strongly
suggest that it should be strongly **featured** �� or, if you like, it
should be warned about!! �� in the Mathematica documentation, especially
at the more elementary levels of documentation, **so that ordinary users
can't miss being warned about this unexpected behavior** ^HH^H^H^H
sorry, so that they can't miss being warned about "this feature".
For example, right after the first line of the Help for I, which says
I represents the imaginary unit Sqrt[-1].
there might be a warning line which says
WARNING: I is a number and not a symbol. Attempting to replace
or reverse the sign of I using a rule, such as expr/.{I->-I) may
produce unexpected results if the expr contains -I.
(By the way, note the wording above: "I represents", not "I is".)
There are a very large number of other places in the Mathematica
documentation where emphasized WARNINGs like this would be helpful.
(I suppose there could even be optional warning messages that appear any
time a cell executes a rule containing a number on the LHS of a
ReplaceAll symbol. And, the documentation for ReplaceAll could have an
initial WARNING message that it is not just the kind of Global Search
and Replace command that many ordinary users, familiar with many other
word processing and software apps, might well think it is. )
DrMajorBob
David Park
thing I find inconvenient is the way expressions often Simplify to a form
that contains extra minus signs. But perhaps trying to design these things
out will just push out problems somewhere else.
Nevertheless, I think this is primarily an education problem. Users do not
learn the basic use of Mathematica early enough and then they stumble over
various features just when they have a serious problem that needs solving.
Very frustrating.
One skill that students may especially lack is the ability to manipulate
expressions in a more detailed form. They may want to do this to obtain a
specific textbook form, or just because they prefer a certain form, or
because they want to follow a specific solution path. Mathematica is really
good at that kind of stuff but learning to do it takes education, time and
practice. Just adding extra notes and examples in Help, although useful, is
not in itself going to solve the education problem. And it's not fair to
students to throw Mathematica at them on difficult material, when they have
not really learned how to use it.
From: AES [mailto:sie...@stanford.edu]
In article <hh9vfo$1rk$1...@smc.vnet.net>,
Richard Fateman <fat...@cs.berkeley.edu> wrote:
I'll defer to Richard Fateman (and/or other computer algebra experts) as
to whether this general behavior (!! especially with respect to -I !!)
is a bug that should be fixed, or a feature.
But if it's gonna be considered a feature in Mathematica, I'd strongly
suggest that it should be strongly **featured** -- or, if you like, it
should be warned about!! -- in the Mathematica documentation, especially
DrMajorBob
We should be told that -I is an atom, hence it does NOT contain I as a
part.
a - I is NOT an atom, since we get a match in
Cases[a - I, -I, {0, Infinity}]
{-I}
AtomQ[a - I]
False
yet 1 - I _is_ an atom, so
Cases[1 - I, -I, {0, Infinity}]
{}
AtomQ[1 - I]
True
I don't know that this ever hinders me in practice, but the rationale
escapes me.
Bobby
On Tue, 29 Dec 2009 00:18:40 -0600, AES <sie...@stanford.edu> wrote:
> In article <hh9vfo$1rk$1...@smc.vnet.net>,
> Richard Fateman <fat...@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.
>
>
> I'll defer to Richard Fateman (and/or other computer algebra experts) as
> to whether this general behavior (!! especially with respect to -I !!)
> is a bug that should be fixed, or a feature.
>
> But if it's gonna be considered a feature in Mathematica, I'd strongly
> suggest that it should be strongly **featured** or, if you like, it
> should be warned about!! in the Mathematica documentation, especially
> at the more elementary levels of documentation, **so that ordinary users
> can't miss being warned about this unexpected behavior** ^HH^H^H^H
> sorry, so that they can't miss being warned about "this feature".
>
> For example, right after the first line of the Help for I, which says
>
> I represents the imaginary unit Sqrt[-1].
>
> there might be a warning line which says
>
> WARNING: I is a number and not a symbol. Attempting to replace
> or reverse the sign of I using a rule, such as expr/.{I->-I) may
> produce unexpected results if the expr contains -I.
>
> (By the way, note the wording above: "I represents", not "I is".)
>
> There are a very large number of other places in the Mathematica
> documentation where emphasized WARNINGs like this would be helpful.
>
> (I suppose there could even be optional warning messages that appear any
> time a cell executes a rule containing a number on the LHS of a
> ReplaceAll symbol. And, the documentation for ReplaceAll could have an
> initial WARNING message that it is not just the kind of Global Search
> and Replace command that many ordinary users, familiar with many other
> word processing and software apps, might well think it is. )
>
Murray Eisenberg
"Numbers containing I are converged to the type Complex."
And in the Examples section, subsectin "Possible Issues", 4th set of
examples:
"Complex numbers are atomic objects and do not explicitly
contain I:"
FullForm[2+I]
Complex[2,1]
This is not to contradict your assertion that it would be useful to give
an explicit example that doing something like
2+3I /. I->-I
does not in fact form the expected conjugate. But at least the
documentation given does give some pause as to whether such an attempt
might fail to work.
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. (Yes, I know a
number have asked about the same thing here, but then of course one
hears only from those for whom it was an issue, and not from those for
whom it was not.) I can imagine, in fact, that a majority of users --
at least of relative novice users, might first think, "I want to take a
conjugate; let me search the documentation how to do that -- I'll look
up 'conjugate'." And, finding immediately the reference page for
Conjugate, use that.
AES wrote:
> In article <hh9vfo$1rk$1...@smc.vnet.net>,
> Richard Fateman <fat...@cs.berkeley.edu> wrote:
>
> I'll defer to Richard Fateman (and/or other computer algebra experts) as
> to whether this general behavior (!! especially with respect to -I !!)
> is a bug that should be fixed, or a feature.
>
> But if it's gonna be considered a feature in Mathematica, I'd strongly
> suggest that it should be strongly **featured** or, if you like, it
> should be warned about!! in the Mathematica documentation, especially
> at the more elementary levels of documentation, **so that ordinary users
> can't miss being warned about this unexpected behavior**
> sorry, so that they can't miss being warned about "this feature".
>
> For example, right after the first line of the Help for I, which says
>
> I represents the imaginary unit Sqrt[-1].
>
> there might be a warning line which says
>
> WARNING: I is a number and not a symbol. Attempting to replace
> or reverse the sign of I using a rule, such as expr/.{I->-I) may
> produce unexpected results if the expr contains -I.
>
> (By the way, note the wording above: "I represents", not "I is".)
>
> There are a very large number of other places in the Mathematica
> documentation where emphasized WARNINGs like this would be helpful.
>
> (I suppose there could even be optional warning messages that appear any
> time a cell executes a rule containing a number on the LHS of a
> ReplaceAll symbol. And, the documentation for ReplaceAll could have an
> initial WARNING message that it is not just the kind of Global Search
> and Replace command that many ordinary users, familiar with many other
> word processing and software apps, might well think it is. )
>
--
Murray Eisenberg mur...@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
AES
DrMajorBob <btr...@austin.rr.com> wrote:
> -1. is a Real, hence an Atom, so it has no subordinate parts.
>
> Bobby
>
Thanks -- except, after digging out and reading the Basic Objects
tutorial (which was useful), I think you mean "hence an atomic object"?
Is "Atom" a defined term in Mathematica? The tutorial doesn't seem to
use it.
[And as an aside, is the shaded table of atomic objects in this tutorial
supposed to be a *complete* list of *all* the atomic objects in
Mathematica? I'm never clear whether these shaded lists are supposed to
contain all, or just some, of the objects they illustrate.].
da...@wolfram.com
> Richard Fateman <fat...@cs.berkeley.edu> wrote:
>
>> Scot T. Martin wrote:
>
>> repeatedly. Just as I does not occur in -I.
>> It can be fixed, should be fixed, and has been fixed in other CAS.
>
>
> I'll defer to Richard Fateman (and/or other computer algebra experts) as
> to whether this general behavior (!! especially with respect to -I !!)
> is a bug that should be fixed, or a feature.
>
> But if it's gonna be considered a feature in Mathematica, I'd strongly
> suggest that it should be strongly **featured** �� or, if you like, it
> should be warned about!! �� in the Mathematica documentation, especially
> at the more elementary levels of documentation, **so that ordinary users
> sorry, so that they can't miss being warned about "this feature".
>
> For example, right after the first line of the Help for I, which says
>
> I represents the imaginary unit Sqrt[-1].
>
> there might be a warning line which says
>
> WARNING: I is a number and not a symbol. Attempting to replace
> or reverse the sign of I using a rule, such as expr/.{I->-I) may
> produce unexpected results if the expr contains -I.
In the Documentation Center search for I. Under Possible Issues one sees
"Complex numbers are atomic objects and do not explicitly contain I:",
along with FullForm representations that show this. I would not mind if an
example along the lines you suggest, e.g. "3+4*I/.I->-I evaluates to
3+4*I" were added. Would having such an example there have helped you?
> (By the way, note the wording above: "I represents", not "I is".)
>
> There are a very large number of other places in the Mathematica
> documentation where emphasized WARNINGs like this would be helpful.
It is difficult to anticipate all manner of misunderstandings of
functionality. It is also the case that Mathematica is a complex language,
hence has room for many such misunderstandings. I run into my share. The
documentation mainly states what various functions do, not what they do
not do.
The misunderstanding you allude to above is fairly common, and perhaps
deserves more attention in the ReplaceAll et al pages. I would not ascribe
that level of importance to all such issues you have raised in this forum.
> (I suppose there could even be optional warning messages that appear any
> time a cell executes a rule containing a number on the LHS of a
> ReplaceAll symbol. And, the documentation for ReplaceAll could have an
> initial WARNING message that it is not just the kind of Global Search
> and Replace command that many ordinary users, familiar with many other
> word processing and software apps, might well think it is. )
I think the documetation is clear that it is a syntactic replacement and
not a string replacement. Under "More Informnation: it states "ReplaceAll
looks at each part of expr, tries all the rules on it, and then..."
Having configurable warning messages of the sort you describe is on the
wish list of many people. I think it is fair to call this a design
weakness in the Mathematica language, that it is not easy to make such a
message system. I do not think Mathematica is exceptional in this regard:
the current message system is perhaps more advanced than one finds in
other software of serious complexity.
Daniel Lichtblau
Wolfram Research
da...@wolfram.com
>> The problem is that "-1." is not "1".
>
> repeatedly. Just as I does not occur in -I.
> It can be fixed, should be fixed, and has been fixed in other CAS.
Deja vu all over again. Why it was only three weeks ago I was seeing
various assertions of bughood mentioned in the Usenet sci.math.symbolic
thread at URL below (insert usual caveats about email line breaking of
URLs).
http://groups.google.com/group/sci.math.symbolic/browse_thread/thread/0256579cfacee298#
One response, from Jon McLoone of Wolfram Research, was quite on target.
I'll try to give a different one.
The first rule of syntactic replacement is that it must obey syntax.
Whether Mathematica's InputForm and related formatting is in some way
misleading in that -1.0 "looks like" it contains 1, or 3-4*I "looks like"
it contains I, is of secondary importance (or maybe tertiary). Far more
important are the following.
(1) InputForm must be readily interpreted (by Mathematica) in an
unambiguous manner. Where possible, e.g numeric notation, it should also
not be overly burdened with prefix notation (that is to say, it is also
nice to have something that is human-readable). Example: Use some familiar
notation, say 3-4*I, to denote what in Mathematica FullForm is
Complex[3,-4].
(2) Numbers must be entities that contain no arithmetic operators e.g.
minus or times. Example: There is no Minus or Times in Complex[3,-4], even
though it "looks" like 3-4*I in Mathematica InputForm. This is important
for efficient arithmetic, and I think also for general evaluation of input
(Example: one wants 3*x/4 and (3/4)*x to evaluate to the same internal
representation, using Times[Rational[3,4],x]).
(3) As noted earlier, syntactic replacement should not arbitrarily and
capriciously depart from following syntax (Examples: Do not consider
Complex[3,4] as "containing" Complex[0,1], even though their respective
InputForm notations are 3+4*I and I, Do not consider Times[3,Power[x,-2]]
as containing x^2, even though InputForm shows it as 3/x^2).
Clearly there are design decisions behind all this. Anyone is free to
state dislike of those decisions. That does not make them bugs. It does
not even necessarily make them bad decisions. Me, I think the ones
itemized above are just fine, which is why I took the trouble to mention
them explicitly.
Daniel Lichtblau
Wolfram Research
Andrzej Kozlowski
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
> <fat...@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.
>>
>
>
> --
> DrMaj...@yahoo.com
>
DrMajorBob
I doubt whether any such list is complete in the documentation.
Bobby
AES
Murray Eisenberg <mur...@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.
Richard Fateman
> 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?
>
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.
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.
Now sometimes this cuts the other way -- that is, what is
"mathematically obvious" to some novice really can't be the default in
a CAS because it contradicts what is "mathematically obvious" to most
experts (or even some other novices). This is when mathematical
ambiguities show up.
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 try to move with the times so what concerns me is that my Front End is
> crashing too often.
Maybe you should tie your shoelaces?
>
RJf
AES
[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.)
Murray Eisenberg
you'll find is AtomQ. The term "atom", with a lower-case "a", appears
in examples there.
But you'll find no entry for "Atom" as a built-in symbol.
AES wrote:
> In article <hhc79g$2np$1...@smc.vnet.net>,
> DrMajorBob <btr...@austin.rr.com> wrote:
>
>> -1. is a Real, hence an Atom, so it has no subordinate parts.
>>
>> Bobby
>>
>
> Thanks -- except, after digging out and reading the Basic Objects
> tutorial (which was useful), I think you mean "hence an atomic object"?
>
> Is "Atom" a defined term in Mathematica? The tutorial doesn't seem to
> use it.
>
> [And as an aside, is the shaded table of atomic objects in this tutorial
> supposed to be a *complete* list of *all* the atomic objects in
> Mathematica? I'm never clear whether these shaded lists are supposed to
> contain all, or just some, of the objects they illustrate.].
>
--
Andrzej Kozlowski
On 31 Dec 2009, at 02:18, Richard Fateman wrote:
> Andrzej Kozlowski 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?
>
> 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.
Useful? Funny you should mention that. "Dismiss as useless and stupid"?
Its only you that keeps doing that. A remarkable example of the purest
hypocrisy.
Do you really think you have ever posted anything that would be useful
to anyone on this forum it its entire history? Everything you have
posted over the years can be quite fairly summarised as the following
advice to new and naive users : Mathematica is full of "bugs", and
other evil and perverse things, and worse, was created by a guy whose
guts I hate, so give it up and use instead my own favourite CAS, which
years ago I helped to make. Oh, and don't mind that it is practically
defunct and useless nowadays.
>
>
>> I try to move with the times so what concerns me is that my Front End
is crashing too often.
>
> Maybe you should tie your shoelaces?
>
Well, this comment just shows typical shallowness of thinking and lack
of knowledge and well as manners.
Has it ever occurred to you that here (in Japan) people generally do not
use shoelaces?
Andrzej Kozlowski
DrMajorBob
it... but here goes.]
I think Andrzej's post (rant?) is overstated... but largely in style, not
substance.
I complain (rant?) quite a bit myself, but I also answer a lot of
questions. I give VERY substantial offline assistance at times (sometimes
without an initial post to the group), and I try to contribute positives,
in general, in terms of coding style and responsiveness to beginning
users. I help people understand Mathematica, whenever I can.
I fully admit that Mathematica is better documented than most or all
software I've worked with, despite my sometimes harsh assessment of Help
deficiencies. I get annoyed at having to figure things out the hard way,
and if that's what it is, that's what I call it. I sound more critical
than I really am, but I have no patience for hints hidden somewhere in the
docs. I want solid information, easily found.
Andrzej contributes far more to the group than I do, in some ways at
least, and he rarely critiques anything but outright "bugs", both of which
speak well of him.
I agree with Andrzej that some complainers don't contribute much to
balance their criticism, but I don't believe I'm in that group. I fit, I
hope, well into the middle ground between Andrzej and RJF.
I also agree that most of my gripes (and many of the gripes of others)
have little to do with getting things done; Andrzej ignores problems that
don't matter in practice, as well he should.
I frequently have to remind myself to do the same, and when I forget...
there's always Andrzej!
Bobby
On Wed, 30 Dec 2009 17:06:30 -0600, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:
Andrzej Kozlowski
On 31 Dec 2009, at 09:42, DrMajorBob wrote:
> I agree with Andrzej that some complainers don't contribute much to
balance their criticism, but I don't believe I'm in that group. I fit, I
hope, well into the middle ground between Andrzej and RJF.
Actually I never mean to associate you in any way with RJF. I only
replied to your post because I always feel a little sick when replying
to him directly.
Andrzej=
DrMajorBob
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 <ak...@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
>> <fat...@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.
>>>
>>
>>
>> --
>> DrMaj...@yahoo.com
>>
>
>
da...@wolfram.com
>
>> stuff, might suffice to escalate some issues to the point of requiring
>> more prominent warnings.
>
> 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
Murray Eisenberg
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...@smc.vnet.net>,
> Murray Eisenberg <mur...@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.)
--
DrMajorBob
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@ComplexExpand@Conjugate@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 <sie...@stanford.edu> wrote:
> In article <hhf5kg$go6$1...@smc.vnet.net>,
> Murray Eisenberg <mur...@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.
>>
> 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
Bobby
On Thu, 31 Dec 2009 02:16:25 -0600, Murray Eisenberg
<mur...@math.umass.edu> wrote:
> If you search for "atom" in the Documentation Center, the first thing
> you'll find is AtomQ. The term "atom", with a lower-case "a", appears
> in examples there.
>
> But you'll find no entry for "Atom" as a built-in symbol.
>
> AES wrote:
>> In article <hhc79g$2np$1...@smc.vnet.net>,
>> DrMajorBob <btr...@austin.rr.com> wrote:
>>
>>> -1. is a Real, hence an Atom, so it has no subordinate parts.
>>>
>>> Bobby
>>>
>>
>> Thanks -- except, after digging out and reading the Basic Objects
>> tutorial (which was useful), I think you mean "hence an atomic object"?
>>
>> Is "Atom" a defined term in Mathematica? The tutorial doesn't seem to
>> use it.
>>
>> [And as an aside, is the shaded table of atomic objects in this tutorial
>> supposed to be a *complete* list of *all* the atomic objects in
>> Mathematica? I'm never clear whether these shaded lists are supposed to
>> contain all, or just some, of the objects they illustrate.].
>>
>
Noqsi
> 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".
David Park
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.
From: AES [mailto:sie...@stanford.edu]
In article <hhf5kg$go6$1...@smc.vnet.net>,
Murray Eisenberg <mur...@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
Bill Rowe
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.
Richard Fateman
...
>
> 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
> 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 <read...@sbcglobal.net>
wrote:
> On 12/31/09 at 3:13 AM, fat...@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.
>
>
Andrzej Kozlowski
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
DrMajorBob
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
<fat...@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
>
>>
>>
>
Bill Rowe
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.
AES
Murray Eisenberg <mur...@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
Murray Eisenberg
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...@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**.
--