Replacement Rule with Sqrt in denominator
Themis Matsoukas
Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] /.
Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] -> G
G
but this doesn't:
1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] /.
Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] -> G
1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2]
The only difference is that the quantity to be replaced is in the denominator. If I remove Sqrt from the replacement rule it will work but I don't understand why a square root in the denominator (but not in the numerator) causes the rule to fail.
Themis
kj
>This replacement rule works,
>G
>but this doesn't:
Yes, that's very annoying.
The reason is that the pattern matching is done on the full forms
of the expressions, which is not always immediately obvious. To
see this compare FullForm[Sqrt[x]], which is
Power[x, Rational[1, 2]], with FullForm[1/Sqrt[x]], which is
Power[x, Rational[-1, 2]].
I don't know a way to write the replacement rule so that it works
for both Sqrt[x] and 1/Sqrt[x], but maybe someone else does.
~kj
Sebastian
ReplaceAll acts on the FullForm of an expression. Evaluate
FullForm[Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] ]
FullForm[1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] ]
and you will see why it fails in the 2nd case. One possible solution
is to use the following pattern
(-4 \[Zeta]^2 + (1 + \[Rho]^2)^2)^(_?(Abs[#]==1/2&))
HTH
Sebastian
Bob Hanlon
Replacements are done on the FullForm. Look at the FullForm to understand the differences.
expr1 = Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2];
expr2 = 1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2];
rule1 = Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] -> G;
expr1 // FullForm
rule1 // FullForm
expr2 // FullForm
Note that in the FullForm for both expr1 and rule 1 that the pattern is Power[_, Rational[1, 2]] so the replacement is made. However, in the FullForm for expr2 the pattern is Power[_,Rational[-1, 2]] so there is no match. You can generalize the rule
rule2 = (-4 \[Zeta]^2 + (1 + \[Rho]^2)^2)^Rational[a_, 2] -> G^a;
{expr1, expr2} /. rule2
{G, 1/G}
Or avoid the Power
rule3 = (-4 \[Zeta]^2 + (1 + \[Rho]^2)^2) -> G^2;
{expr1, expr2} /. rule3 // Simplify[#, G > 0] &
{G, 1/G}
Bob Hanlon
---- Themis Matsoukas <tmats...@me.com> wrote:
=============
Peter Breitfeld
Have a look at the FullForm, which is always used by ReplaceAll:
In your first example the FullForm looks like:
ff1=Power[Plus[Times[-4,Power[\[Zeta],2]],Power[
Plus[1,Power[\[Rho],2]],2]],Rational[1,2]]
In the second one:
ff2=Power[Plus[Times[-4,Power[\[Zeta],2]],Power[
Plus[1,Power[\[Rho],2]],2]],Rational[-1,2]]
the little but important difference is the "-" Sign in the last one. In
the first example the replacement takes place, because the FullForm
matches. You do ff1/.ff1->G
But in the second one it doesn't match because you try ff2/.ff1->G
You can do: ff2/. (1/ff1)->G (no need to use FullForm here)
--
_________________________________________________________________
Peter Breitfeld, Bad Saulgau, Germany -- http://www.pBreitfeld.de
Bill Rowe
>This replacement rule works,
>Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] /. Sqrt[-4 \[Zeta]^2 + (1
>+ \[Rho]^2)^2] -> G
>but this doesn't:
>1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2] /. Sqrt[-4 \[Zeta]^2 +
>(1 + \[Rho]^2)^2] -> G
>The only difference is that the quantity to be replaced is in the
>denominator. If I remove Sqrt from the replacement rule it will work
>but I don't understand why a square root in the denominator (but not
>in the numerator) causes the rule to fail.
It is essential to know Mathematica only does a replacement
where there is a literal match when applying replacement rules
and the match *must* to the form Mathematica uses to represent
the expression. Using FullForm
In[10]:= FullForm[1/Sqrt[-4 \[Zeta]^2 + (1 + \[Rho]^2)^2]]
Out[10]//FullForm= Power[Plus[Times[-4,Power[\[Zeta],2]],Power[Plus[1,Power[\[Rho],2]],2]],Rational[-1,2]]
you can see there is no Sqrt in the denominator. So, your
pattern fails to match and no replacement is done.
Richard Fateman
>
> I don't know a way to write the replacement rule so that it works
> for both Sqrt[x] and 1/Sqrt[x], but maybe someone else does.
>
> ~kj
>
See
www.cs.berkeley.edu/~fateman/papers/better-rules.pdf
which describes how one can automatically produce rules that overcome
this bug in Mathematica. oops. I mean rules that overcome this
"feature" in Mathematica.
RJF
Murray Eisenberg
FullForm[1/Sqrt[x]]
Power[x,Rational[-1,2]]
Thus there is no "Sqrt[x] really in 1/Sqrt[x] (the latter being just a
quick input form), just as there is no "I" in 1+2I.
--
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
Richard Fateman
> It's not a bug (and not really a "feature", either):
>
> FullForm[1/Sqrt[x]]
> Power[x,Rational[-1,2]]
>
> Thus there is no "Sqrt[x] really in 1/Sqrt[x] (the latter being just a
> quick input form), just as there is no "I" in 1+2I.
The bug is not in the representation. It is in the rule processing.
After all, a rule replacing Sqrt[x] by y could also replace
(x)^(-1/2) by y^(-1).
That would "fix" the "feature".
>
> On 11/30/2010 4:05 AM, Richard Fateman wrote:
>> On 11/20/2010 3:11 AM, kj wrote:
>>
>>>
>>> I don't know a way to write the replacement rule so that it works
>>> for both Sqrt[x] and 1/Sqrt[x], but maybe someone else does.
>>>
>>> ~kj
>>>
>> See
>> www.cs.berkeley.edu/~fateman/papers/better-rules.pdf
>>
>> which describes how one can automatically produce rules that overcome
>> this bug in Mathematica. oops. I mean rules that overcome this
>> "feature" in Mathematica.
>>
>> RJF
>>
>>
>
To quote from the above paper...
The argument that Mathematica already does
the right thing by \literally" matching expressions loses much of its
force by observing how frequently
mathematicians report its behavior as erroneous.
This report by kj is just another incident. You could argue "the
customer is always wrong", but you
don't really have to do that. See the referenced paper.
RJF
Bill Rowe
>I don't know a way to write the replacement rule so that it works
>for both Sqrt[x] and 1/Sqrt[x], but maybe someone else does.
This is easy using Alternatives. For example:
In[2]:= a Sqrt[x] /. Sqrt[x] | Power[x, _] -> b
Out[2]= a b
In[3]:= a/Sqrt[x] /. Sqrt[x] | Power[x, _] -> b
Out[3]= a b
Note, I've only shown a simple way to solve the specific issue.
I did not make the alternative using Power sufficiently
restrictive to prevent say x^2 from being replaced by b. If
there is to be made to cover the possibility of that something
like x^2 will be present but should not be replaced, the
alternative using Power would need to be more specific.
Themis Matsoukas
Of course there is an explanation as to why this happens but this doesn't make it correct. I know that Mathematical looks for literal occurrences when it applies replacement rules, and so I cut-and-pasted the denominator to create the replacement. Obviously what I see is not what there is. Nonetheless, when I manipulate an expression I go by what I see, and Mathematica in this case was deceitful.
tm
Daniel Lichtblau
> I will have to agree with kj and Richard Fateman that this is both
> annoying and borderline bug.
It certainly can be a nuisance. It's not a bug. It might be a feature,
if you define feature much differently than I do.
> Of course there is an explanation as to why this happens but
> this doesn't make it correct. I know that Mathematical looks for
> literal occurrences when it applies replacement rules, and so I
> cut-and-pasted the denominator to create the replacement. Obviously
> what I see is not what there is. Nonetheless, when I manipulate an
> expression I go by what I see, and Mathematica in this case was deceitful.
>
> tm
The alternative would be to output everything in FullForm. That's not
something many people would want. So for better or worse we go with the
form you refer to as "deceitful".
Changing the semantics of rule replacement to what amounts to "read my
mind" is not an alternative.
Daniel Lichtblau
Wolfram Research
Roland Franzius
Use rules like
HoldPattern[x^Rational[a_,2]] :> G^a
eg this works for contraction of products of fractional powers
((1 + I x)^(1/2)/(1 - I x)^(1/2)) /.
{HoldPattern[a_^Rational[b_, c_] d_^Rational[e_, c_]]
:> (a^b d^e)^(1/c)}
while this one does not work
(1 + I x)^(1/2)/(1 - I x)^(
1/2) /. {a_^(b_/c_) d_^(e_/c_) :> (a^b d^e)^(1/c)}
The reason is that fractions of patterns are represented by Times with
Power[#,-1]. Explicit integer fractions are represented by Rational. The
same problem arises with Complex. It is impossible to transform
explicitly complex expressions (expressions with I, Re, Im, Abs) without
inspection of FullForm.
--
Roland Franzius
Richard Fateman
....
The paper I wrote, previously mentioned in this thread, suggests and
implements an alternative rule matching process, and provides an
alternative syntax for it, namely
a =/. r
where r is a rule and a is an expression.
It fixes the bugs that appear to exist, to many users, when they use
a /. r
Thus it is not necessary to look at FullForm, nor is it necessary
to declare a bug a feature.
Now you may not like this alternative pattern matching process
either, but to declare that it is impossible to do this Sqrt[]->...
thing is obviously wrong.
Now DanL's view (restated somewhat) that this constitutes the
thin edge of the wedge of expecting Mathematica to "read my mind"
has some validity. How much more (beyond what is in that paper)
should be done? Is the treatment of a+b*I and negative powers
all that is needed? It would go a long way to eliminating the
frustration exhibited by people who took the effort to report their
problems to this newsgroup, and who were sophisticated enough to
actually report it. (Uh, maybe not so much these days, where
infants send text messages from cribs...)
Anyway, I would rather have the CAS do some simple guessing of what
I mean, as at least a fair trade for me having to guess what secret
things will happen in FullSimplify or Integrate or Solve, or ...
especially as versions change. I do recall that this community
experienced (at least once) a minor uprising of people who refused
to upgrade to the next higher version, on the grounds that the new
version introduced uh, bugs. or were they features.
Basically, explaining a bug does not make it into a feature, especially
when it can actually be fixed.
RJF
Richard Fateman
....
>
> Use rules like
>
> HoldPattern[x^Rational[a_,2]] :> G^a
>
> eg this works for contraction of products of fractional powers
>
> ((1 + I x)^(1/2)/(1 - I x)^(1/2)) /.
> {HoldPattern[a_^Rational[b_, c_] d_^Rational[e_, c_]]
> :> (a^b d^e)^(1/c)}
Not really. Consider the very similar example
((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
a_^Rational[b_, c_] d_^Rational[e_, c_]] :> (a^b d^e)^(1/c)}
where we have a/2 instead of 1/2
and the pattern does not match. Maybe you don't want it to match in
this case, but the problem persists even if you do. Like this pattern:
((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
a_^(b_/c_) d_^(e_/c_)] :> (a^b d^e)^(1/c)}
which fails.
or this pattern
((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
a_^(b_*Rational[-1, c_]) d_^(e_*Rational[-1, c] _)] :> (a^b d^
e)^(1/c)}
which fails too.
Now try this (note, the rule must be delayed... :> )
aa^(rr/ss)*bb^(qq/ss) /. (
a_^r_*b_^s_ /; Denominator[r] == Denominator[s] :>
(a^Numerator[r]*b^Numerator[s])^(1/Denominator[r]))
and then it works. you get (aa^rr*b^qq)^(1/ss).
really you probably want to take out something like the
greatest multiple of r and s, not 1/Denominator[s], but
that's up to you.,
Basically, if the rules for your pattern matching reflect
the SEMANTICS of what you are doing, e.g. "denominator" and
"numerator", rather than the SYNTAX of FullForm, being
Rational or maybe Times or ..., then you have a better chance of
winning.
Each time someone defends Mathematica via "you have to look
at FullForm" he/she is essentially saying, "Mathematica is now too
stupid to do what you want, and the programmers of the system
are too resistant to making it smarter. Thus the burden falls on
you to look at the data representation underlying the abstraction
to make your program work."
It's not so hard to make the system smarter. But you pay for what
you get.
RJF
Daniel Lichtblau
> [...]
> Each time someone defends Mathematica via "you have to look
> at FullForm" he/she is essentially saying, "Mathematica is now too
> stupid to do what you want,
A more accurate translation would be "Mathematica is to stupid to read
your mind and figure out what you really want."
> and the programmers of the system
> are too resistant to making it smarter.
I cannot speak for all of the programmers here. For myself, I'll say
I've been doing this stuff a long time, and I recognize a fool's errand
in what you propose here.
> Thus the burden falls on
> you to look at the data representation underlying the abstraction
> to make your program work."
I'd change "abstraction" to "representation". At which point I would
agree, regarding the burden.
> It's not so hard to make the system smarter.
I'll indicate below why I am not convinced what you want equates to
smarter software.
> But you pay for what
> you get.
Here I agree.
Actually one of the things I really appreciate about Mathematica, and
for which, alas, I can take no credit, is that rule replacement works so
reliably well. When I get frustrated with it failing to do what I intend
(about once every month or two), there is the inevitable session with
MatchQ to sort things out.
> RJF
I think any nonsyntactic rule replacement will need very clear
semantics. The notion "replace it if it shows up visually" is not
terribly clear. It relies, among other things, on specifics of the
format settings, vagaries of e.g. StandardForm, and other details.
To give an idea of what is meant by the formatting vagaries, consider
that we could represent 1/Sqrt[x+1] explicitly as (x+1)^(-1/2) (mentally
format that so it looks pretty, with the exponent raised, no caret,
etc.) So the substitution semantics being proposed would depend on
formatting?! Or should it apply to any power of (x+1) when that power
visually has a 2 in the denominator? (Does it then apply to
(x+1)^(a/2+b/4)? Or only to the equivalent (x+1)^(1/2*(a+b/2))?)
These are the questions that would need to be answered before even
embarking on this journey.
I will add that about the last thing anyone wants is that StandardForm
formatting be influenced by the desire to avoid any possibility of
showing "misleading" expression structure. I don't think you are
proposing otherwise, but it would be a natural outcome to any effort to
try to curtail this misunderstanding.
I have not raised the I->3*I issue. I do wonder what should be the
outcome of Sin[x] /. I->3*I . Maybe the trig equivalent of
(Exp[3*I*x] - Exp[-3*I*x]) / (6*I), which is Sin[3*x]/3? (Maybe we
should make it case insensitive, and return S3in[x]?)
Daniel Lichtblau
Wolfram Research
Richard Fateman
...
snip
...
I hesitate to follow up on my own posting, but..
Here's a much nicer rule with LCM, that you might like.
qq = (a_^r_ b_^s_ /; (lcm =
PolynomialLCM[Denominator[s], Denominator[r]]) =!= 1 :> (a^(
lcm r) b^(lcm s))^(1/lcm))
although it uses a global variable lcm, which, in a better
formulation might be put inside a module, but I don't know how
this would work inside a pattern in Mathematica.
a^(a_^r_ b_^s_ /; (lcm =
PolynomialLCM[Denominator[s], Denominator[r]]) =!= 1 :> (a^(
lcm r) b^(lcm s))^(1/lcm)
a^(r/s)*b^(p/3/s) /. qq
comes out as
(a^(3 r) * b^p) ^(1/(3 s))
and
Sqrt[u]*Sqrt[v^3]^5 /. qq
comes out as Sqrt[u*v^15].
Again, that is assuming you want to make that transformation.
Notice the distinct lack of "FullForm" or "Rational"
RJF
Bill Rowe
wrote:
>Anyway, I would rather have the CAS do some simple guessing of what
>I mean, as at least a fair trade for me having to guess what secret
>things will happen in FullSimplify or Integrate or Solve, or ...
>especially as versions change.
I definitely do not want Mathematica to do any guessing as to
what I mean. I very strongly dislike software that behaves in
that manner. This leads to unpredictability and often
significant difficulty in stopping the "guessing" to have
exactly what I inputed executed as I want. Word is a good
example of software that implements this "guessing" which is one
reason I very much dislike Word.
I also see a very significant difference between how replacement
rules operate and changes in things like FullSimplify,
Integrate, Solve ... These functions are not "guessing" as to
what I want. Yes, they involve complex algorithms that may
change from version to version and may mean results change from
version to version. Unlike these functions, operation of
replacement rules is truly easy to predict once you realize the
operate on the FullForm of an expression. There is no ambiguity.
And since replacement is a literal replacement, the behavior is
consistent from version to version.
>Basically, explaining a bug does not make it into a feature,
When an aspect of software works as designed it is inappropriate
to refer to that aspect as a bug. The fact replacement rules
operate on the FullForm of an expression but what is displayed
is not the FullForm does mean inexperienced users of Mathematica
will encounter some difficulties with replacement rules. But,
that simply doesn't equate to being a bug.
Roland Franzius
> On 12/2/2010 2:43 AM, Roland Franzius wrote:
> ....
>
>>
>> Use rules like
>>
>> HoldPattern[x^Rational[a_,2]] :> G^a
>>
>> eg this works for contraction of products of fractional powers
>>
>> ((1 + I x)^(1/2)/(1 - I x)^(1/2)) /.
>> {HoldPattern[a_^Rational[b_, c_] d_^Rational[e_, c_]]
>> :> (a^b d^e)^(1/c)}
>
> Not really. Consider the very similar example
>
> ((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
> a_^Rational[b_, c_] d_^Rational[e_, c_]] :> (a^b d^e)^(1/c)}
>
> where we have a/2 instead of 1/2
>
> and the pattern does not match. Maybe you don't want it to match in
> this case, but the problem persists even if you do. Like this pattern:
>
> ((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
> a_^(b_/c_) d_^(e_/c_)] :> (a^b d^e)^(1/c)}
>
> which fails.
It seems you have not yet recognized that pattern matching in
Mathematica fails by construction if the symbol name of pattern, here a_
concides with a symbol in the expression.
The rest of these kind of problems - different typisation of numbers and
expressions, real number rules failing in complex cases, comlex
multivaluedness in fractional powers logarithms and contour integrals,
pattern evaluation precedence and rule noncommutativity of rule
application in real time and many different problems of this kind are
deeply knitted into the design of a pattern replacement language like
Mathematica.
So the alternatives are to write an alternative language or to learn
mastering the of use it. The same alternative holds for all of
mathematics.
--
Roland Franzius
Richard Fateman
>>
>> and the pattern does not match. Maybe you don't want it to match in
>> this case, but the problem persists even if you do. Like this pattern:
>>
>> ((1 + I x)^(a/2)/(1 - I x)^(a/2)) /. {HoldPattern[
>> a_^(b_/c_) d_^(e_/c_)] :> (a^b d^e)^(1/c)}
>>
>> which fails.
>
> It seems you have not yet recognized that pattern matching in
> Mathematica fails by construction if the symbol name of pattern, here a_
> concides with a symbol in the expression.
Uh, no, I think you have it wrong.
Sin[a] + Sin[b] /. Sin[a_] -> h[a]
is perfectly happy to return h[a]+h[b]
Sin[a] + Sin[a + b] /. Sin[a_] -> h[a]
is perfectly happy to return h[a]+h[a+b].
...
>
> So the alternatives are to write an alternative language
... and possibly implement it in Mathematica...
> or to learn
> mastering the of use it. The same alternative holds for all of
> mathematics.
Actually this is obviously not correct, since Mathematica can (and does)
change. I don't know if "mathematics" changes, but certainly the
language of mathematics evolves.
RJF
Richard Fateman
>> (RJF wrote) Thus the burden falls on
>> you to look at the data representation underlying the abstraction
>> to make your program work."
>
> (DanL wrote) I'd change "abstraction" to "representation". At which point I would
> agree, regarding the burden.
No, I think the abstraction is something like "a/b" or possibly
"a^(-n)". Or "An expression x such that Numerator[x]==a, Denominator[x]==b.
Of course the representation, deep down, is using electrons and stuff.
But one layer down the representation can be Rational[a,b] if a,b, are
numbers, and gcd(a,b)=1 and a>0. Or it can be Times[a,Power[b,-1]] or
yet other options.
The fact that Mathematica requires you to deal with this representation
layer is the problem.
>
>
>> It's not so hard to make the system smarter.
>
> I'll indicate below why I am not convinced what you want equates to
> smarter software.
>
>
>> But you pay for what
>> you get.
>
> Here I agree.
>
> Actually one of the things I really appreciate about Mathematica, and
> for which, alas, I can take no credit, is that rule replacement works so
> reliably well. When I get frustrated with it failing to do what I intend
> (about once every month or two), there is the inevitable session with
> MatchQ to sort things out.
You see, the abstraction (in your mind) and the representation are
different. I too find the pattern issues occasionally frustrating, and
I have the advantage of (reverse engineering) the Mathematica pattern
matcher (version 3.0) or so, in Lisp. So there were things I had to
figure out so I could program them. Things I would not have ever tried,
and probably no one had ever used.
>
>
>> RJF
>
> I think any nonsyntactic rule replacement will need very clear
> semantics.
Yes, I agree.
The notion "replace it if it shows up visually" is not
> terribly clear. It relies, among other things, on specifics of the
> format settings, vagaries of e.g. StandardForm, and other details.
I agree. That's why notions like
"coefficient of I" and "numerator of X" are needed.
>
> To give an idea of what is meant by the formatting vagaries, consider
> that we could represent 1/Sqrt[x+1] explicitly as (x+1)^(-1/2) (mentally
> format that so it looks pretty, with the exponent raised, no caret,
> etc.) So the substitution semantics being proposed would depend on
> formatting?!
Not really. The notion of sqrt(x) is fairly clear, and it seems to
include the denominator of 1/sqrt(x). This is not, I think, rocket science.
Or should it apply to any power of (x+1) when that power
> visually has a 2 in the denominator? (Does it then apply to
> (x+1)^(a/2+b/4)? Or only to the equivalent (x+1)^(1/2*(a+b/2))?)
Possibly. It seems to me that this is kind of like "Simplify" vs
"FullSimplify".
>
> These are the questions that would need to be answered before even
> embarking on this journey.
Note that I have shown that the improved pattern matching can be built
using syntactic pattern matching plus some other programs. I am not
requiring that the syntactic pattern matching be removed.
>
> I will add that about the last thing anyone wants is that StandardForm
> formatting be influenced by the desire to avoid any possibility of
> showing "misleading" expression structure. I don't think you are
> proposing otherwise, but it would be a natural outcome to any effort to
> try to curtail this misunderstanding.
I am not proposing altering the display.
>
> I have not raised the I->3*I issue. I do wonder what should be the
> outcome of Sin[x] /. I->3*I .
Well, you could also claim that -1/. I->x should be x^2. This
kind of issue can be thought through by fairly simple means.
If you can divide an expression H by P to compute Q,R in H=Q*P+R, then
replacing P by M results in the expression Q*M+R. Done.
So we are talking about division. (This does not quite cover all
the cases, but it is close).
Maybe the trig equivalent of
> (Exp[3*I*x] - Exp[-3*I*x]) / (6*I), which is Sin[3*x]/3? (Maybe we
> should make it case insensitive, and return S3in[x]?)
String substitution and regular expressions and the like are of course
a different matter. :)
RJF
Richard Fateman
> On 12/3/10 at 5:19 AM, fat...@cs.berkeley.edu (Richard Fateman)
> wrote:
>
>> Anyway, I would rather have the CAS do some simple guessing of what
>> I mean, as at least a fair trade for me having to guess what secret
>> things will happen in FullSimplify or Integrate or Solve, or ...
>> especially as versions change.
>
> I definitely do not want Mathematica to do any guessing as to
> what I mean.
I was speaking loosely here; obviously Mathematica should be
deterministic (well, no less deterministic than it already is).
> I very strongly dislike software that behaves in
> that manner. This leads to unpredictability and often
> significant difficulty in stopping the "guessing" to have
> exactly what I inputed executed as I want. Word is a good
> example of software that implements this "guessing" which is one
> reason I very much dislike Word.
Microsoft (etc) would probably call this activity, done on behalf
of the user, as "user-friendly interface", which I (and now you)
refer to as guessing.
>
> I also see a very significant difference between how replacement
> rules operate and changes in things like FullSimplify,
> Integrate, Solve ... These functions are not "guessing" as to
> what I want. Yes, they involve complex algorithms that may
> change from version to version and may mean results change from
> version to version.
You miss my point. It is unfortunately necessary for the human
to guess what these programs do. I write a program, and it no
longer works. Why? Because Solve or Reduce has changed, and I
have to guess why, and do some testing.
> Unlike these functions, operation of
> replacement rules is truly easy to predict once you realize the
> operate on the FullForm of an expression.
Obviously not for DanL or for me, at least when we try something a
little out of the ordinary.
> There is no ambiguity.
Actually, there is some ambiguity about order in which things are done
or matched.
> And since replacement is a literal replacement, the behavior is
> consistent from version to version.
I disagree, since predicates are
part of matching and the predicates can depend on anything in
Mathematica, including things that change in version "updates".
>
>> Basically, explaining a bug does not make it into a feature,
>
> When an aspect of software works as designed it is inappropriate
> to refer to that aspect as a bug.
OK, I say
"Dressing up a bug as a feature does not fix the bug."
You say, in effect,
If a designer writes a program that does exactly what the designer
intended, then it is not a bug.
OK, then, what term do you wish to use to refer to the result of
design and programming that results from an error in the design that
causes mathematical computations to proceed in a way that is
internally inconsistent, and is generally considered mathematical
nonsense?
A feature? I would call it a bug (in the design). And I think
I am being generous.
> The fact replacement rules
> operate on the FullForm of an expression but what is displayed
> is not the FullForm does mean inexperienced users of Mathematica
> will encounter some difficulties with replacement rules. But,
> that simply doesn't equate to being a bug.
No, I think the error is that users need to have another kind
of pattern matching, and that when too many people stumble over
the same feature, the correct response is NOT, "the customer is wrong,
yet again."
It might be , Oh, you want the semantic pattern matcher. Maybe, Here's
how we can set it up to be your default command pattern
matcher...
RJF
>
>
Bill Rowe
wrote:
>On 12/4/2010 3:14 AM, Bill Rowe wrote:
>>When an aspect of software works as designed it is inappropriate to
>>refer to that aspect as a bug.
>OK, I say "Dressing up a bug as a feature does not fix the bug."
And I agree.
>You say, in effect,
>If a designer writes a program that does exactly what the designer
>intended, then it is not a bug.
Yes.
>OK, then, what term do you wish to use to refer to the result of
>design and programming that results from an error in the design
I don't agree the behavior of replacement rules reflects an
error in design.
>that causes mathematical computations to proceed in a way that is
>internally inconsistent, and is generally considered mathematical
>nonsense?
Since replacement rules are not doing mathematics there should
be no requirement for the result to make mathematical sense.
That is a replacement rule such as 2->1 is perfectly valid but
clearly doesn't make 2 equal to 1.
>>The fact replacement rules operate on the FullForm of an expression
>>but what is displayed is not the FullForm does mean inexperienced
>>users of Mathematica will encounter some difficulties with
>>replacement rules. But, that simply doesn't equate to being a bug.
>No, I think the error is that users need to have another kind of
>pattern matching, and that when too many people stumble over the
>same feature, the correct response is NOT, "the customer is wrong,
>yet again."
>It might be , Oh, you want the semantic pattern matcher.
>Maybe, Here's how we can set it up to be your default command pattern
>matcher...
In another post Daniel Lichtblau described the issues with
trying to make replacement rules work on what is displayed
rather than full form.
Richard Fateman
...
>
>> (RJF, putting words in Bill Rowe's mouth)...
>>
If a designer writes a program that does exactly what the designer
>> intended, then it is not a bug.
>
> (Bill Rowe) Yes.
>
>> OK, then, what term do you wish to use to refer to the result of
>> design and programming that results from an error in the design
>
> I don't agree the behavior of replacement rules reflects an
> error in design.
Aha, but you don't answer the question. Let us say that the designer
put in something you truly thought was wrong, for example the
designer truly thought that Cot[x] could be simplified to 1/x*Tan[x].
If this is not a bug, perhaps you would call it a BLUNDER?
>
>> that causes mathematical computations to proceed in a way that is
>> internally inconsistent, and is generally considered mathematical
>> nonsense?
Mathematica does not restrict its blunders to matching and rules.
>
> Since replacement rules are not doing mathematics there should
> be no requirement for the result to make mathematical sense.
I don't require rules to be applications of identities. I think that
it is mathematically inconsistent to match "I" in a+b*I but not
match "I" in 3+4*I.
> That is a replacement rule such as 2->1 is perfectly valid but
> clearly doesn't make 2 equal to 1.
OK, It is perfectly valid, but it doesn't work consistently.
Example.
(a+b)^2 /. 2-> 1 returns a+b AS EXPECTED.
(a+b)^(1/2) /. 2->1 returns Sqrt[a+b] IS THIS EXPECTED??
2+a*I /. 2->1 returns 1+a*I AS EXPECTED.
2+3*I /. 2->1 ...
>
>>> The fact replacement rules operate on the FullForm of an expression
>>> but what is displayed is not the FullForm does mean inexperienced
>>> users of Mathematica will encounter some difficulties with
>>> replacement rules.
Actually, replacement rules operate on the internal representation of
the expression. FullForm is simply another output form that is an
alternative string representation ( or XML or whatever..) of the
internal representation. One that is somewhat more explicit in some ways
than the usual standard form.
Clearly FullForm doesn't work as you think it does, because
FullForm[Sqrt[a+b]] has a "2" in it, but the rules don't know it.
So you REALLY need to know that FullForm of a Rational is not an
accurate representation of the internal form, and is hiding something
that is the yet Fuller Form, that explains that although
Rational[1,2] is what you see, it is not REALLY an object with a
Head of Rational and two parts;
Example.
f= F[3,5] has Head F, f[[1]] is 3, f[[2]] is 5.
g=3/5 has Head Rational g[[1]] is not 3, but an error.
But, that simply doesn't equate to being a bug.
No, but it means that any program that traverses an expression
(say, to do a replacement 2->1), has to check for a subexpression
that has head Rational, and must decide NOT to do replacements
within it. Is this extra work to get the wrong answer? Of course
if the replacement were 2->x then replacing Rational[1,2] by
Rational[1,x] would be a bad idea... so it is a tradeoff of some
sort. In my view, the wrong tradeoff. That means I think it is
a bug or blunder. You may view it otherwise. I may view your
view as incorrect. That's the way it goes.
>
>> No, I think the error is that users need to have another kind of
>> pattern matching, and that when too many people stumble over the
>> same feature, the correct response is NOT, "the customer is wrong,
>> yet again."
>
>> It might be , Oh, you want the semantic pattern matcher.
>> Maybe, Here's how we can set it up to be your default command pattern
>> matcher...
>
> In another post Daniel Lichtblau described the issues with
> trying to make replacement rules work on what is displayed
> rather than full form.
You (and DanL?) seem to think that I am advocating making replacement
rules work on what is displayed. Yet in a/b, I see no occurrence of
Numerator[] or Denominator[], which encode the semantics. Semantics
is what I think should be used for patterns. It would be possible to
translate a_/b_ into "let x=a_/b_; consider Numerator[x] and
Denominator[x] ...."
The alternative which is
presented for consumption in this newsgroup is that patterns operate on
the syntax as depicted by FullForm.
But that too is a simplification, since it
does not work for Complex[], Rational[], or for that matter, other forms
that you may not know about (yet). Example. (is this a bug??)
Series[ x^5, {x,0, 10} ] /. 5-> 6 gives x^6 + O[x]^11
Series[1+x^5, {x,0, 10} ] /. 5-> 6 gives 1 + x^5 + O[x]^11
or is it a feature?
And do you know about SparseArray, for which replacements don't work either?
and who knows what else. Blame the customer for not knowing. That's
the ticket.
RJF
Andrzej Kozlowski
On 6 Dec 2010, at 12:14, Bill Rowe wrote:
>>> The fact replacement rules operate on the FullForm of an expression
>>> but what is displayed is not the FullForm does mean inexperienced
>>> users of Mathematica will encounter some difficulties with
>>> replacement rules. But, that simply doesn't equate to being a bug.
>
>> No, I think the error is that users need to have another kind of
>> pattern matching, and that when too many people stumble over the
>> same feature, the correct response is NOT, "the customer is wrong,
>> yet again."
>
>> It might be , Oh, you want the semantic pattern matcher.
>> Maybe, Here's how we can set it up to be your default command pattern
>> matcher...
>
> In another post Daniel Lichtblau described the issues with
> trying to make replacement rules work on what is displayed
> rather than full form.
Whether something is right or wrong, is a bug or a feature or whatever ultimately depends on consensus of "experts" or at least people who are sufficiently qualified to make an informed judgement. This is just as much true of design of computer programs, "correct" use of language etc. as of mathematics. In mathematics, of course, in most cases consensus is easy to reach, as in the case of whether two plus two is four or seven. No amount of stubborn insisting on the latter answer will win over the consensus of people familiar with basic arithmetic - at least not without additional incentives of the kind "That's not true! It's seven! Say it's seven or I'll hit you!"
(see Lem's story "Trul's Machine" here <http://www.scribd.com/doc/23580413/Lem-Stanislaw-The-Cyberiad> ).
In more advanced mathematics we too get situations that "qualitatively" resemble this. Sometimes someone, occasionally even a very good mathematician keeps insisting that he had proved something (usually a famous unsolved problem) while the majority of experts reject the claim. One of several such examples is Wu-Yi Hsiang and his alleged proof of the Kepler conjecture (see the article by T.C. Hales in "The Mathematical Intelligencer" in 1994). More common are the cases of individuals claiming that some well established theorem of theory is wrong. In all such situations the thing to remember that "consensus" is not a matter of numbers - it does not help to have on one's side any number of people who obviously do not understand what the whole thing is about. Expert's themselves are not equal - in many areas the judgement of a few individuals carries more weight than that of practically everyone else together.
My point here is this. Richard Fateman has been insisting for over a decade that this particular behaviour of Mathematica pattern matcher is some sort of "bug". He has posted the same arguments many times over, often in response to the same counter arguments from the same opponents. And, as far as I can recall, he has never succeeded in winning over to his side a single informed person. He does indeed receive some support but almost exclusively from people who are either Mathematica beginners or "perpetual beginners". He has certainly never got anything remotely resembling "the support of experts" on his side.
Most importantly, he has never managed to get Daniel to concede any ground at all on this point. Now, unless one assumes that Daniel is just plain stubborn, or unable to see the obvious, or just totally under the thumb of his "evil boss", this suggests that the case for a bug is a weak one, I would say rather weaker than Hsiang's claim to have proved the Kepler Conjecture (I am not even sure if it is much stronger than the claim of Trul's machine).
Andrzej Kozlowski
Noqsi
> this suggests that the case for a bug is a weak one, I would say rather weaker than
> Hsiang's claim to have proved the Kepler Conjecture (I am not even sure if it is much
> stronger than the claim of Trul's machine).
It is easy to see the kind of chaos the vague and ambiguous "rules
should be interpreted semantically in a way that makes mathematical
sense" would cause. How should
a + b I /. I->-I
be interpreted *semantically*. Is it
a - b I
or
Conjugate[a] - Conjugate[b] I
?
Either one, I think, depending on the (unknown) intention of the
"user". Whatever "user" means here: the main "user" of rules in a
system like this is the system itself, not a human.
Of course, Mathematica has a rich collection of tools for transforming
expressions in ways that make "mathematical sense". In this case,
Conjugate[] and possibly ComplexExpand[] are the tools of choice. But
what transformations make "mathematical sense" for a given expression
cannot generally be deduced from the expression itself. The "user"
must communicate that through other channels, e.g. by using tools like
ComplexExpand[].
Consider the simplicity of the above example, and the complexity of
the manipulations we do with Mathematica. There are very many more
complicated expressions where "mathematical sense" in transformations
is ambiguous. Clearly, the behavior of replacement rules must be
defined rigorously and syntactically: anything else would lead to
endless nonsense.
In a computer algebra system, rules are the raw material from which we
create "mathematical sense". They cannot themselves be interpreted
according to "mathematical sense".
Bill Rowe
wrote:
>On 12/6/2010 3:14 AM, Bill Rowe wrote: ...
>>I don't agree the behavior of replacement rules reflects an error
>>in design.
>Aha, but you don't answer the question. Let us say that the
>designer put in something you truly thought was wrong, for example
>the designer truly thought that Cot[x] could be simplified to
>1/x*Tan[x].
>If this is not a bug, perhaps you would call it a BLUNDER?
This is a meaningless strawman of your own making which has no
bearing on the discussion. Or is it you are arguing someone
designing software to do mathematics would intentionally create
a design to return 1/x*Tan[x] as a result for Cot[x]? I cannot
believe anyone designing software to do mathematics would argue
getting 1/x*Tan[x] as the result for Cot[x] was intentional design.
You have made it abundantly clear you do not like the current
design of Mathematica with respect to how replacement rules
work. And that is fine. You are clearly entitled to your own
preferences with respect to how anything in Mathematica works or
doesn't work for that matter. I merely point out your dislike of
the design that results in the behavior of replacement rules
does not make that behavior a bug nor a design error.
Daniel Lichtblau
> Most importantly, he has never managed to get Daniel to concede any
> ground at all on this point. Now, unless one assumes that Daniel is
> just plain stubborn, or unable to see the obvious, or just totally
> a bug is a weak one, I would say rather weaker than Hsiang's claim
> to have proved the Kepler Conjecture (I am not even sure if it is
> much stronger than the claim of Trul's machine).
>
Multiple choice! I was always fond of multiple choice. But where is "All
of the above"?
Daniel Lichtblau (totally worn out from the battle with the Evil Thumb)
Wolfram Research
PS On a different Usenet forum, not long ago, only the third option was
offered. Not much there for multiple guessers. So I gave up on that forum.
Richard Fateman
> On 12/7/10 at 6:45 AM, fat...@cs.berkeley.edu (Richard Fateman)
> wrote:
>
>> On 12/6/2010 3:14 AM, Bill Rowe wrote: ...
>
>>> I don't agree the behavior of replacement rules reflects an error
>>> in design.
>
>> Aha, but you don't answer the question. Let us say that the
>> designer put in something you truly thought was wrong, for example
>> the designer truly thought that Cot[x] could be simplified to
>> 1/x*Tan[x].
>
>> If this is not a bug, perhaps you would call it a BLUNDER?
>
> This is a meaningless strawman of your own making which has no
> bearing on the discussion.
OK, you want some examples that have occurred, and whose resolution has
changed, from version to version of Mathematica? How would you
characterize a situation in which version N replies True but version
N+1 replies False? Did version N+1 fix a bug? a blunder? or exhibit
just some chronologico-mathematical time warp?
If you want to argue about such things, just look at the brouhaha
regarding whether sqrt(x^2) is abs(x), or the difference between
0^0 and 0.0^0.0 . or whether integral of x^n is 1/(n+1)*x^(n+1),
which is arguably false if n=-1.
> Or is it you are arguing someone
> designing software to do mathematics would intentionally create
> a design to return 1/x*Tan[x] as a result for Cot[x]?
I set this up so that you and I would agree that the designer was
indeed mistaken, regardless of his sincerity in believing this.
I have no idea of your view of whether sqrt(x^2) is x, -x, {-x,x},
abs(x), rootof(), ...
I cannot
> believe anyone designing software to do mathematics would argue
> getting 1/x*Tan[x] as the result for Cot[x] was intentional design.
You can't? You cannot believe that anyone designing software might
have gotten some formula wrong? So much of computer algebra
system design includes a portion of "you might not like it but I have
my own reason for doing it this way."
>
> You have made it abundantly clear you do not like the current
> design of Mathematica with respect to how replacement rules
> work.
yep.
> And that is fine. You are clearly entitled to your own
> preferences with respect to how anything in Mathematica works or
> doesn't work for that matter.
yep.
I merely point out your dislike of
> the design that results in the behavior of replacement rules
> does not make that behavior a bug nor a design error.
nor does your apparent enjoyment of the behavior constitute a
proof that it is by some objective criterion, correct.
As for why this appears repeatedly -- as I have pointed out in
private mail to DanL, the history of questions on this newsgroup
is inaccessible to many newsreaders. Someone asks, the usual
crowd of hangers-on tell him that he is wrong to believe that
I->-I is an effective rule, etc. And some people tell him he
is right to complain.
Perhaps there should be a database , even a FAQ of some sort.
As for Andrzej's assertion that no one agrees with my perspective,
I suppose it is sufficient to point out that Andrzej would have
no way of knowing that. And to some extent it is pointless to
support my perspective (on this newsgroup) as long as I am willing to
do so myself.
So far as I know, Andrzej does not have access to my personal email,
though who knows what Wikileaks will release in the future.
I do agree that crowd-sourcing of mathematical theorems or
opinions on the design of Mathematica seems less useful than
using expert(s) in general.
I might point out that in almost all the reported problems, we have
a rule or sub-part of a rule, which has a constant, like 2, or I,
which fails to match an expression like -2 or or 1/2 or -I.
You, and others seem to thing that the
effects of allowing this match would be confusing, or inefficient, or
would break things. In my view it would be simple enough to completely
define the changes necessary, document them, and implement them.
I took the trouble to write a paper and a sample implementation.
It responds to certain customers' issues.
Your view, shared by some others, is that such a change is unthinkable,
and that the customer is wrong. But the argument you offer is
fundamentally is the Peewee Herman refrain .. "I meant to do that".
RJF
>
>
Sebastian
I am certainly not entitled to do so. I was always quite happy to
follow the rules and look at the FullForm in order to create the
correct pattern, until I learned (actually just by following this
thread) that this does not always produce the expected results. So
even though this may not be a bug, pattern matching can be very
confusing sometimes, and, in terms of usability, may seem to be poorly
implemented to some people.
Having said that, could somebody give me a little insight on how
pattern matching "really" works (I'm sure Daniel has done so many
times already, please feel free to refer me to previous posts!):
What set (or class) of expressions does pattern matching exclude from
its "normal" behavior (obviously there is Rational, Complex,
whatnot...)? Why? Are there different such classes? Why does 3/5[[1]]
fail (alternatively: Why does Rational behave differently then List,
say)?
TIA
Sebastian
Albert Retey
I think the reason is that Rational, Complex, SparseArray and some
others are atoms, which you can check by AtomQ (see also
tutorial/BasicObjects). Unfortunately there seems to be no
"PatternMatcherForm" which would allow users to look at the expression
as the pattern matcher actually sees it. Also I can see no obvious and
consistent pattern on what is treated as an atom and what not: while
SparseArray-objects are atoms (tested with AtomQ and even documented as
such) InterpolatingFunction-objects are not...
hth,
albert
Bill Thurston
Because of problems like those cited, I've often ended up just giving up on mathematica finding formal solutions even when I know in principle it can find them, and instead I attack them from other directions or by alternate tools. Mathematica has done many things well for me, but I've been tripped up miserably on others.
Bill Thurston
Richard Fateman
> I don't want to claim that pattern matching in Mathematica is bugged,
> I am certainly not entitled to do so. I was always quite happy to
> follow the rules and look at the FullForm in order to create the
> correct pattern, until I learned (actually just by following this
> thread) that this does not always produce the expected results. So
> even though this may not be a bug, pattern matching can be very
> confusing sometimes, and, in terms of usability, may seem to be poorly
> implemented to some people.
> Having said that, could somebody give me a little insight on how
> pattern matching "really" works (I'm sure Daniel has done so many
> times already, please feel free to refer me to previous posts!):
> What set (or class) of expressions does pattern matching exclude from
> its "normal" behavior (obviously there is Rational, Complex,
> whatnot...)?
Apparently these are called "Raw" objects, and there are others, like
SparseArray, and some Graphics thing/?/
Why? Are there different such classes? Why does 3/5[[1]]
> fail (alternatively: Why does Rational behave differently then List,
> say)?
While a+b is internally a list of 3 items, Plus, a, b ... I expect
that 3/4 is NOT a list of 3 items, Rational, 3, 4, but some primitive
encoded object. What FullForm claims is in fact false.
An analogy:
in other systems you have a floating-point number x=3.145. You do
not expect x[[3]] to be "1". Though of course you might allow that if
you interpret "parts" of floating point numbers to do a string
conversion etc.
This happens on some level for EVERYTHING. After all, an integer
in FullForm is a character string with decimal digits, but truly
internally an integer is some encoding in 32 or 64 or more bits.
I think that, given the FullForm appearance of something like 3/4, it
would not be much of a stretch to allow part extraction from Rationals,
and to do pattern-matching on their parts. It would make
FullForm more accurate in some sense.
WRI policy is to disagree.
RJF
AES
Noqsi <noqsiae...@gmail.com> wrote:
> It is easy to see the kind of chaos the vague and ambiguous "rules
> should be interpreted semantically in a way that makes mathematical
> sense" would cause. How should
>
> a + b I /. I->-I
>
> be interpreted *semantically*?
I do not possess anything like the depth of knowledge of symbolic
algebra or the understanding of the principles of semantics that would
embolden me to offer any answer to the preceding question.
But I will offer the following opinion: However the above rule is to be
interpreted, in any decent symbolic algebra system, assuming a and b
have not yet been assigned any values, the symbol I should be
interpreted (i.e., modified) identically -- i.e., in *exactly* the same
fashion -- for either of the inputs
a + b I /. I->-I OR a + 2 b I /. I->-I
This is NOT the case in Mathematica. This behavior is a "gotcha" that
can be responsible for large and hard to trace difficulties for many
users
Furthermore, I believe that Mathematica WILL interpret (i.e. , modify)
the two inputs above in exactly the same fashion if the character I in
thee two expressions is replaced by ANY OTHER single upper or lower case
letter in the alphabet. Does anyone else find this not to be true?
Bill Rowe
wrote:
>On 12/8/2010 3:40 AM, Bill Rowe wrote:
>>On 12/7/10 at 6:45 AM, fat...@cs.berkeley.edu (Richard Fateman)
>>wrote:
>>>On 12/6/2010 3:14 AM, Bill Rowe wrote: ...
>>>>I don't agree the behavior of replacement rules reflects an error
>>>>in design.
>>>Aha, but you don't answer the question. Let us say that the
>>>designer put in something you truly thought was wrong, for example
>>>the designer truly thought that Cot[x] could be simplified to
>>>1/x*Tan[x].
>>
>>>If this is not a bug, perhaps you would call it a BLUNDER?
>>This is a meaningless strawman of your own making which has no
>>bearing on the discussion.
>OK, you want some examples that have occurred, and whose resolution
>has changed, from version to version of Mathematica? How would you
>characterize a situation in which version N replies True but version
>N+1 replies False? Did version N+1 fix a bug? a blunder? or exhibit
>just some chronologico-mathematical time warp?
>If you want to argue about such things, just look at the brouhaha
>regarding whether sqrt(x^2) is abs(x), or the difference between
>0^0 and 0.0^0.0 . or whether integral of x^n is 1/(n+1)*x^(n+1),
>which is arguably false if n=-1.
None of the examples you give above are relevant to the
discussion at hand which is whether the behavior of replacement
rules with respect to 1/Sqrt[x] is a bug or not. None of my
remarks imply Matheamtica has no bugs. Nor do my remarks imply
there have not been changes from one version to the next that
have caused problems for people. These things certainly exsits,
and I can be much more specific than you have been above. But
none of these are relevant to a discussion of whether the
current behavior of replacement rules is a bug or not.
>>I cannot believe anyone designing software to do mathematics would
>>argue getting 1/x*Tan[x] as the result for Cot[x] was intentional
>>design.
>You can't? You cannot believe that anyone designing software might
>have gotten some formula wrong? So much of computer algebra system
>design includes a portion of "you might not like it but I have my
>own reason for doing it this way."
Do you understand the difference between getting some formula
wrong and claiming 1/x*Tan[x] is an intentional design result
for Cot[x]? If yes, you must realize your comments have no
relevance to mine. If not, there is little point in a discussion
of bugs with you.
Yes, I realize errors made were not seen as errors at the time
they were made and what was done was intentional at that time. I
also realize there are people who will claim any result obtained
is exactly what they intended. Neither of these things have
relevance. If these were relevant criteria no behavior could
ever qualify as being a bug.
>I do agree that crowd-sourcing of mathematical theorems or opinions
>on the design of Mathematica seems less useful than using expert(s)
>in general.
>I might point out that in almost all the reported problems, we have
>a rule or sub-part of a rule, which has a constant, like 2, or I,
>which fails to match an expression like -2 or or 1/2 or -I. You,
>and others seem to thing that the effects of allowing this match
>would be confusing, or inefficient, or would break things.
No. I merely claim the current behavior of replacement rules is
not a bug or a design error. It may well be possible to change
the behavior so that it is in some respect more user friendly
without causing other inefficiencies or breaking things. I don't
have access to the source code and simply do not know what it
would take to implement the changes you would like or what
impact it might have on other parts of Mathematica.
>In my view it would be simple enough to completely define the changes
>necessary, document them, and implement them. I took the trouble to
>write a paper and a sample implementation. It responds to certain
>customers' issues.
Suggesting a change that would respond to the needs of certain
users is one thing. Calling the current behavior of replacement
rules a bug or design error is quite another.
>Your view, shared by some others, is that such a change is
>unthinkable, and that the customer is wrong.
Not at all. I make no claim changes are unthinkable. Mathematica
has changed many times from version to version and will
undoubtedly do so in future versions. Some of those changes will
be ones I like while others will be ones I dislike for one
reason or another. But I do understand my like/dislike of any
past change or future change in no way determines whether those
changes are "bugs" or design errors.
Jack L Goldberg 1
a) Input as typed: 2<=x<=4. Look at its fullform. On my Mac
running ver. 7 of Mathematica, I get returned,
LessEqual[2,x,4].
b) Now type in Reduce[2<=x<=4]. You will get
Inequality[2,LessEqual,x,LessEqual,4].
These are are different expressions! How can one program replacement
rules when one can not be sure of the FullForm? These structures are
entirely different. Which fullform can one assume is the one Mathematica sees
in some complicated module wherein one step is a replacement rule?
Jack Goldberg
Mathematics
University of Michigan
Richard Fateman
>
>
>>> (Bill) I cannot believe anyone designing software to do mathematics would
>>> argue getting 1/x*Tan[x] as the result for Cot[x] was intentional
>>> design.
>
>> have gotten some formula wrong? So much of computer algebra system
>> design includes a portion of "you might not like it but I have my
>> own reason for doing it this way."
>
> wrong and claiming 1/x*Tan[x] is an intentional design result
> for Cot[x]?
Well, my point was, you could have hired some person who misunderstood
or misread or somehow got some formula wrong, but then accurately
transcribed that incorrect formula into a program. His intentional
design was to do the correct thing, and that is how the program was
designed. So how could it be a bug? (no, maybe it is something else.
perhaps a blunder?)
> If yes, you must realize your comments have no
> relevance to mine. If not, there is little point in a discussion
> of bugs with you.
I think you miss the point. You think there is no relevance, but
that is because you miss the point.
>
> Yes, I realize errors made were not seen as errors at the time
> they were made and what was done was intentional at that time.
Aha, that is the point. You just think it is inconceivable that
someone could "believe" an incorrect formula.
The Red Queen, in Alice in Wonderland, says that "...sometimes I've
beleived as many as six impossible things before breakfast"
> also realize there are people who will claim any result obtained
> is exactly what they intended.
Certainly. In the software "engineeering" world there are notions
like "requirements" "specifications" "design" "detailed design"
"implementation" etc. And there are people who "prove" that
programs are correct because they satisfy the specifications even
though they are terrible because the requirements are inadequate.
For example, a requirement might be "in all cases the result
of the manipulation should be the mathematically correct one,
(if the correct result is unambiguous, mathematically)"
Could you argue against that?
Neither of these things have
> relevance. If these were relevant criteria no behavior could
> ever qualify as being a bug.
Certainly. so how does one determine buggy?
>
>
> (Bill) No. I merely claim the current behavior of replacement rules is
> not a bug or a design error.
On what basis do you make this claim?
It may well be possible to change
> the behavior so that it is in some respect more user friendly
> without causing other inefficiencies or breaking things.
Aha, so you agree that there is some criterion, which you call
"user friendly". I might call it "mathematically consistent".
That is how one might make a useful distinction between a
"bug" and a "feature".
I don't
> have access to the source code and simply do not know what it
> would take to implement the changes
Neither do I. But I believe that for a careful design, the
changes would be minor. I have access to the source code for
a similar program.
> you would like or what
> impact it might have on other parts of Mathematica.
I find it hard to believe that any part of Mathematica REQUIRES the
behavior that
3+4I /. I->-I result in 3+4I unchanged but
3+bI /. I->-I result in 3+bI
What do you think?
>
>> In my view it would be simple enough to completely define the changes
>> necessary, document them, and implement them. I took the trouble to
>> write a paper and a sample implementation. It responds to certain
>> customers' issues.
>
> Suggesting a change that would respond to the needs of certain
> users is one thing. Calling the current behavior of replacement
> rules a bug or design error is quite another.
Um, it seems to me that we see messages on this newsgroup that look like
requests by users to change the behavior to correspond to what they
think should happen. So these are not quite different at all.
>
>> Your view, shared by some others, is that such a change is
>> unthinkable, and that the customer is wrong.
>
> Not at all. I make no claim changes are unthinkable. Mathematica
> has changed many times from version to version and will
> undoubtedly do so in future versions. Some of those changes will
> be ones I like while others will be ones I dislike for one
> reason or another. But I do understand my like/dislike of any
> past change or future change in no way determines whether those
> changes are "bugs" or design errors.
You are just being too solicitous of the views of WRI defenders.
It should be obvious to anyone that one determinant in whether
some change in a program is a "bug" or not is whether users dislike
those changes. It is not the only factor, but to say that your
view "in no way determines...[bughood]" is something that you,
and perhaps others, should reconsider.
Would you feel the same way about the provider of any other
good or service -- that the brewer's new beer formulation must
be better because he says so, even if you dislike it? That
the car steers better because the manufacturer says so?
etc. etc.
>
>
Noqsi
> In article <idnqq6$q5...@smc.vnet.net>,
>
> Noqsi <noqsiaerosp...@gmail.com> wrote:
> > It is easy to see the kind of chaos the vague and ambiguous "rules
> > should be interpreted semantically in a way that makes mathematical
> > sense" would cause. How should
>
> > a + b I /. I->-I
>
> > be interpreted *semantically*?
>
> I do not possess anything like the depth of knowledge of symbolic
> algebra or the understanding of the principles of semantics that would
> embolden me to offer any answer to the preceding question.
Oh, come on. This really isn't hard to understand.
>
> But I will offer the following opinion: However the above rule is to b=
e
> interpreted, in any decent symbolic algebra system, assuming a and b
> have not yet been assigned any values, the symbol I should be
> interpreted (i.e., modified) identically -- i.e., in *exactly* the same
> fashion -- for either of the inputs
>
> a + b I /. I->-I OR a + 2 b I /. I->-I
>
> This is NOT the case in Mathematica.
And this is trivially understandable by looking at FullForm. "I" is
part of the number in this case: it is not a separate symbol. As well
expect 22/.2->1 to yield 11.
> This behavior is a "gotcha" that
> can be responsible for large and hard to trace difficulties for many
> users
Sure. And if you use a power saw carelessly, you'll cut your fingers
off. That's a worse "gotcha", but it can't be helped in a foolproof
way without crippling the saw. Just as this can't be helped without
crippling Mathematica.
>
> Furthermore, I believe that Mathematica WILL interpret (i.e. , modify)
> the two inputs above in exactly the same fashion if the character I in
> thee two expressions is replaced by ANY OTHER single upper or lower case
> letter in the alphabet. Does anyone else find this not to be true?
It's a consequence of two very simple considerations:
1. Pattern matching works on FullForm.
2. Pattern matching can't split atoms.
What's so hard about this? There are only six kinds of atoms.
When using a tool, it's preferable to exploit the way it actually
works, rather than make up some impossible notion and complain that it
should work that way.
David Bevan
It seems to me that the reason rules seem counterintuitive to some na=EFve users is due to the difference between FullForm and StandardForm. Obviously rules can't be based on some nebulous concept of mathematical understanding and must be applied syntactically to a specific form of expressions; Mathematica implements rules against FullForm.
If it were possible to represent StandardForm as a 'tree structure' (rather than just as a visible display), then rules could be applied against that form. For example, we might have:
FullForm[x/Sqrt[5] + 1/z + I]
Plus[Times[Power[5, Rational[-1, 2]], x], Power[z, -1], Complex[0, 1]]
FullStandardForm[x/Sqrt[5] + 1/z + I]
Plus[Divide[x, Sqrt[5]], Divide[1, z], I]
Of course, this does not provide any more mathematical intuition than apply ing rules to FullForm, but the ability to apply rules to FullStandardForm would perhaps sometimes be a bit closer to what some users expect / want.
Maybe this is something Wolfram might consider.
David %^>
-----Original Message-----
From: AES [mailto:sie...@stanford.edu]
Sent: 10 December 2010 07:30
Subject: Re: Replacement Rule with Sqrt in denominator
In article <idnqq6$q5i$1...@smc.vnet.net>,
Noqsi <noqsiae...@gmail.com> wrote:
> It is easy to see the kind of chaos the vague and ambiguous "rules
> should be interpreted semantically in a way that makes mathematical
> sense" would cause. How should
>
> a + b I /. I->-I
>
> be interpreted *semantically*?
I do not possess anything like the depth of knowledge of symbolic
algebra or the understanding of the principles of semantics that would
embolden me to offer any answer to the preceding question.
But I will offer the following opinion: However the above rule is to be
interpreted, in any decent symbolic algebra system, assuming a and b
have not yet been assigned any values, the symbol I should be
interpreted (i.e., modified) identically -- i.e., in *exactly* the same
fashion -- for either of the inputs
a + b I /. I->-I OR a + 2 b I /. I->-I
This is NOT the case in Mathematica. This behavior is a "gotcha" that
can be responsible for large and hard to trace difficulties for many
users
Furthermore, I believe that Mathematica WILL interpret (i.e. , modify)
Bill Rowe
>I'd like to chime in that I appreciate Richard Fateman's analysis of
>the behavior of replacement rules. (See his paper
>www.cs.berkeley.edu/~fateman/papers/better-rules.pdf. I've been
>using mathematica since version 1 (or even before, when Steve
>Wolfram was still involved with SMP), and I've often been annoyed at
>the difficulties he's discussed. My interest in Mathematica is as a
>peripheral tool; I don't want to have to know too much about its
>quirks and its inner workings. I'm a mathematician, I don't want to
>be a mathematica-ologist. Usually if I start looking at
>FullForm[expression], I feel like I'm wading in more deeply than I
>want to or should. It quickly becomes very frustrating, since as
>Richard noted, FullForm doesn't tell the whole story, the whole
>story is not public and not documented, and the undocumented
>internal behavior can and does change from version to version --- so
>I'd prefer to have to think about it as little as possible.
With respect to replacement rules or any other behavior of
Mathematica you have a pretty limited choice for solving problems.
You can:
1) use different functions in Mathematica and ignore the
behavior you don't care for or don't want to take the time to
understand more thoroughly.
2) you can dig into the operation of the function until you do
understand how it behaves and can use it effectively
3) you can use something other than Mathematica to solve the problem.
There really isn't any other useful choice in terms of getting a
problem solved.
With respect to 2) above and replacement rules, it is not
correct to say the behavior is undocumented. Most of the posters
here are not WRI employees and have no access to the source
code. All they have access to is the same documentation you have
access to. And since it is clear some users do understand the
behavior of replacement rules it cannot be true the behavior is undocumente=
d.
>Because of problems like those cited, I've often ended up just
>giving up on mathematica finding formal solutions even when I know
>in principle it can find them, and instead I attack them from other
>directions or by alternate tools. Mathematica has done many things
>well for me, but I've been tripped up miserably on others.
Which is basically choice 3). For myself, I generally choose
option 2). The payoff for option 2) is as I increase my
understanding of how Mathematica behaves in some specific case,
I find I have more confidence in the results I get and I am
better able to predict behavior for other problems. In this
respect, Mathematica is like any other complex tool. The better
you understand a tool, the more effectively you can apply that
tool to a new problem.
Andrzej Kozlowski
Inequality[2, LessEqual, x, LessEqual, 3]
and
LessEqual[2, x, 3]
look exactly the same after evaluation while retaining different FullForms is a trap even for experienced users, and that it should be clearly documented, probably in more than one place. In fact Inequality is probably the worst documented function in Mathematica (not counting the undocumented ones). (I believe I myself found out about its existence on this forum several years ago.)
The lack of documentation is clearly indefensible and I am not going to attempt to defend it. I don't think, however, that the existence of these two forms necessarily constitutes bad design. In fact Inequality is a very convenient way to represent, in a compact form, complicated inequalities, like
Inequality[0, Less, x, LessEqual, y, Less, 2, LessEqual, z, Less, 4]
which otherwise have to be written as a clumsy conjunctions of expressions involving Less and LessEqual. Once you get used to Inequality you will find that it is a useful thing to have but of course if nobody tells you about it, it is worse than useless.
Andrzej Kozlowski
On 11 Dec 2010, at 19:52, Jack L Goldberg 1 wrote:
> Andrzej you're 100% correct and indeed in the application in which this came up I eventually realized the problem and worked around it in essentially the same way you suggested. Getting around it is one thing but why it happens is another. After all, such behavior is really poor design. Why should I have to spend hours on this "feature" until I discovered that the FullForm of input 2<==x<==4 is not the same as the FullForm of the output of Reduce[2<==x<==4]? The Reduce function was imbedded in 50 lines of code and the error did not immediately suggest itself because there were many references to other functions throughout the code which could have been the culprit. This suggests that EVERY functions that returns 2<==x<==4 as output must be examined to see its FullForm before it can be used further, especially if one wants Part of the expression. Andrzej keep in mind the surprise factor here. Two functions return 2<==x<==4 but their outputs have different FullForms!
>
> Well maybe I'm nuts but this is bad functionality IMO. I can't help wondering whether there are other examples of this kind and when they are going to bite me.
>
> Jack
>
>
>
> Quoting Andrzej Kozlowski <ak...@mimuw.edu.pl>:
>
>>
>> On 11 Dec 2010, at 07:52, Jack L Goldberg 1 wrote:
>>
>>>
>>> a) Input as typed: 2<==x<==4. Look at its fullform. On my Mac
>>> running ver. 7 of Mathematica, I get returned,
>>> LessEqual[2,x,4].
>>>
>>> b) Now type in Reduce[2<==x<==4]. You will get
>>> Inequality[2,LessEqual,x,LessEqual,4].
>>>
>>> These are are different expressions! How can one program replacement
>>> rules when one can not be sure of the FullForm? These structures are
>>> entirely different. Which fullform can one assume is the one Mathematica sees
>>> in some complicated module wherein one step is a replacement rule?
>>>
>>> Jack Goldberg
>>> Mathematics
>>> University of Michigan
>>>
>>
>> O.K. but I don't see anything here that in any way contradicts anything that has been said about the need for
>> for looking at FullForm before trying pattern matching. Actually, it is also an argument against using Copy and Paste. To see that, evaluate Reduce[2<==x<==4]. Now, copy the output and paste it into another cell and wrap FullForm around it, then evaluate. You will get LessEqual[2,x,4].
>>
>> I don't see this as a problem, do you? You can certainly match both forms with a single pattern:
>>
>> {2 <== x <== 4, Reduce[2 <== x <== 4]} /.
>> (a_) <== x <== (b_) | Inequality[a_, LessEqual, x, LessEqual, b_] :> {a, b}
>>
>> {{2, 4}, {2, 4}}
>>
>>
>> Andrzej Kozlowski
>>
>>
>>
>>
>>
>
>
Themis Matsoukas
>
> 1. Pattern matching works on FullForm.
>
> 2. Pattern matching can't split atoms.
>
> What's so hard about this?
Of course there's nothing hard about it. Except that it took 30+ messages in this thread to clarify this point. Nowhere in ref/ReplaceAll or in tutorial/ApplyingTransformationRules is there any mention of FullForm.
Themis
Daniel Lichtblau
----- Original Message -----
> From: "Jack L Goldberg 1" <jack...@umich.edu>
> To: math...@smc.vnet.net
> Sent: Saturday, December 11, 2010 12:52:23 AM
> Subject: Re: Replacement Rule with Sqrt in denominator
> a) Input as typed: 2<=x<=4. Look at its fullform. On my Mac
> running ver. 7 of Mathematica, I get returned,
> LessEqual[2,x,4].
>
> b) Now type in Reduce[2<=x<=4]. You will get
> Inequality[2,LessEqual,x,LessEqual,4].
>
> These are are different expressions! How can one program replacement
> rules when one can not be sure of the FullForm? These structures are
> entirely different. Which fullform can one assume is the one
> Mathematica sees
> in some complicated module wherein one step is a replacement rule?
>
> Jack Goldberg
> Mathematics
> University of Michigan
The FullForm seen is the one you would obtain by printing FullForm[expression] at the point of computation where you are about to do the replacement.
The example above is troublesome because it shows an ambiguity in StandardForm. The InputForms are different, though, with the one for Inequality being identical to its FullForm.
In other examples that have appeared in this thread, the StandardForm and InputForm views of expressions are not in general ambiguous so much as misleading as to the actual structure. (You probably knew that.)
Daniel Lichtblau
Wolfram Research
Daniel Lichtblau
> > also realize there are people who will claim any result obtained
> > is exactly what they intended.
>
> Certainly. In the software "engineeering" world there are notions
> like "requirements" "specifications" "design" "detailed design"
> "implementation" etc. And there are people who "prove" that
> programs are correct because they satisfy the specifications even
> though they are terrible because the requirements are inadequate.
>
> For example, a requirement might be "in all cases the result
> of the manipulation should be the mathematically correct one,
> (if the correct result is unambiguous, mathematically)"
>
> Could you argue against that?
Yes, if it means guessing user intent.
I'll add that it is not generally a good idea to punch holes in the "usual" behavior to get some exceptional cases to "work" in some different way. It should be done sometimes, but it is a slippery slope. A major problem is that there are often unintended side effects. This may not be an issue if you take an academic view. But if you are charged with maintaining or marketing the software then it becomes a different matter.
I recently dug a big hole, and jumped inside it, in an attempt to make some rational function algebra (e.g. Together and friends) do the "obvious" thing with inputs containing approximate number coefficients. Not yet sure if I am climbing out, or still digging.
> > (Bill) No. I merely claim the current behavior of replacement rules
> > is
> > not a bug or a design error.
>
> On what basis do you make this claim?
One reasonable basis would be that the designers claim it is neither a bug nor a design error. You, as a user, are then quite entitled to opine that it was a bad design. That would be okay as an opinion. It is not the same thing as a design error (as I understand the meaning) and it is quite far from a bug.
> It may well be possible to change
> > the behavior so that it is in some respect more user friendly
> > without causing other inefficiencies or breaking things.
>
> Aha, so you agree that there is some criterion, which you call
> "user friendly". I might call it "mathematically consistent".
> That is how one might make a useful distinction between a
> "bug" and a "feature".
That would involve a redefinition ofthe term "bug", as opposed to e.g. a bad design.
> I find it hard to believe that any part of Mathematica REQUIRES the
> behavior that
> 3+4I /. I->-I result in 3+4I unchanged but
> 3+bI /. I->-I result in 3+bI
>
> What do you think?
It was asked of someone else, but I think the developer who makes the change would need to take care that nothing else of importance changed as a side effect. It would also be desirable to check by some means whether the change went sufficiently far as to capture what many users expect, without leaving loose ends.
> >> In my view it would be simple enough to completely define the
> >> changes
> >> necessary, document them, and implement them. I took the trouble to
> >> write a paper and a sample implementation. It responds to certain
> >> customers' issues.
What is there is not necessarily what would be required for maintaining a commercial product.
> > Suggesting a change that would respond to the needs of certain
> > users is one thing. Calling the current behavior of replacement
> > rules a bug or design error is quite another.
>
> Um, it seems to me that we see messages on this newsgroup that look
> like
> requests by users to change the behavior to correspond to what they
> think should happen. So these are not quite different at all.
They are indeed quite different.
> >> Your view, shared by some others, is that such a change is
> >> unthinkable, and that the customer is wrong.
> >
> > Not at all. I make no claim changes are unthinkable. Mathematica
> > has changed many times from version to version and will
> > undoubtedly do so in future versions. Some of those changes will
> > be ones I like while others will be ones I dislike for one
> > reason or another. But I do understand my like/dislike of any
> > past change or future change in no way determines whether those
> > changes are "bugs" or design errors.
>
> You are just being too solicitous of the views of WRI defenders.
>
> It should be obvious to anyone that one determinant in whether
> some change in a program is a "bug" or not is whether users dislike
> those changes. It is not the only factor, but to say that your
> view "in no way determines...[bughood]" is something that you,
> and perhaps others, should reconsider.
These opinions do not determine the quality of being a bug. They may help to point to cases of bad design of some functionality. I do not think the examples in question qualify as such a case, but clearly others disagree.
If you wish to change, by extension, the meaning of "bug", then it behooves you to distinguish carefully what you are doing. Else you are likely to cheapen your own currency.
Daniel Lichtblau
Wolfram Research
Andrzej Kozlowski
On 11 Dec 2010, at 07:52, Jack L Goldberg 1 wrote:
>
> a) Input as typed: 2<==x<==4. Look at its fullform. On my Mac
> running ver. 7 of Mathematica, I get returned,
> LessEqual[2,x,4].
>
> b) Now type in Reduce[2<==x<==4]. You will get
> Inequality[2,LessEqual,x,LessEqual,4].
>
> These are are different expressions! How can one program replacement
> rules when one can not be sure of the FullForm? These structures are
> entirely different. Which fullform can one assume is the one Mathematica sees
> in some complicated module wherein one step is a replacement rule?
>
> Jack Goldberg
> Mathematics
> University of Michigan
>
O.K. but I don't see anything here that in any way contradicts anything that has been said about the need for
Jack L Goldberg 1
this came up I eventually realized the problem and worked around it in
essentially the same way you suggested. Getting around it is one
thing but why it happens is another. After all, such behavior is
really poor design. Why should I have to spend hours on this "feature"
as the FullForm of the output of Reduce[2<=x<=4]? The Reduce function
suggest itself because there were many references to other functions
throughout the code which could have been the culprit. This suggests
wants Part of the expression. Andrzej keep in mind the surprise
different FullForms!
Well maybe I'm nuts but this is bad functionality IMO. I can't help
wondering whether there are other examples of this kind and when they
are going to bite me.
Jack
Quoting Andrzej Kozlowski <ak...@mimuw.edu.pl>:
>
> On 11 Dec 2010, at 07:52, Jack L Goldberg 1 wrote:
>
>>
>> a) Input as typed: 2<=x<=4. Look at its fullform. On my Mac
>> running ver. 7 of Mathematica, I get returned,
>> LessEqual[2,x,4].
>>
>> b) Now type in Reduce[2<=x<=4]. You will get
>> Inequality[2,LessEqual,x,LessEqual,4].
>>
>> These are are different expressions! How can one program replacement
>> rules when one can not be sure of the FullForm? These structures are
>> entirely different. Which fullform can one assume is the one
>> Mathematica sees
>> in some complicated module wherein one step is a replacement rule?
>>
>> Jack Goldberg
>> Mathematics
>> University of Michigan
>>
>
> O.K. but I don't see anything here that in any way contradicts
> anything that has been said about the need for
> for looking at FullForm before trying pattern matching. Actually, it
> is also an argument against using Copy and Paste. To see that,
> evaluate Reduce[2<=x<=4]. Now, copy the output and paste it into
> another cell and wrap FullForm around it, then evaluate. You will
> get LessEqual[2,x,4].
>
> I don't see this as a problem, do you? You can certainly match both
> forms with a single pattern:
>
> {2 <= x <= 4, Reduce[2 <= x <= 4]} /.
> (a_) <= x <= (b_) | Inequality[a_, LessEqual, x, LessEqual, b_] :> {a, b}
Richard Fateman
....
>
> With respect to replacement rules or any other behavior of
> Mathematica you have a pretty limited choice for solving problems.
>
> You can:
>
> 1) use different functions in Mathematica and ignore the
> behavior you don't care for or don't want to take the time to
> understand more thoroughly.
>
> 2) you can dig into the operation of the function until you do
> understand how it behaves and can use it effectively
>
> 3) you can use something other than Mathematica to solve the problem.
4. You can request that the tool be modified by the vendor. The vendor
will almost certainly do this if there is enough money at stake.
5. You can build you own tools (after all, Mathematica is programmable).
This is what I suggest in my paper, and which is done in a much more
elaborate fashion by Harris' Semantica program.
6. You can ask another person to write a suitable tool. (E.g. a student
who can get credit for designing/writing/testing a program.)
>
> There really isn't any other useful choice in terms of getting a
> problem solved.
>
> With respect to 2) above and replacement rules, it is not
> correct to say the behavior is undocumented.
Um, some of it is documented. Some of it is not documented.
Try to find discussion of "raw objects" that are not handled by matching.
There is also the contradiction that if Rational[] is an atom,
how can it be decomposed via the pattern Rational[n_,m_]?
Most of the posters
> here are not WRI employees and have no access to the source
> code. All they have access to is the same documentation you have
> access to.
You give the documentation too much credit. Most of the posters also
have access to the program, and they determine its behavior by trial
and error. I certainly do.
And since it is clear some users do understand the
> behavior of replacement rules it cannot be true the behavior is undocumente
> d.
There's lots of stuff that does not come with documentation, and
yet people eventually understand the behavior, more or less.
...
>. For myself, I generally choose
> option 2). The payoff for option 2) is as I increase my
> understanding of how Mathematica behaves in some specific case,
> I find I have more confidence in the results I get and I am
> better able to predict behavior for other problems. In this
> respect, Mathematica is like any other complex tool. The better
> you understand a tool, the more effectively you can apply that
> tool to a new problem.
For some tools, yes. But programs are different from (say) chainsaws
in a very important respect. A chainsaw is a physical object that
is fundamentally limited by its physical properties. A purchaser of
a chainsaw probably cannot use it as (for example) a belt sander,
or a bicycle, or a water pump.
BUT
Software in a general-purpose programmable language running on a
digital computer with sufficient memory etc is almost infinitely
mutable into other software. If you are sufficiently clever,
you can change it: you can write a Lisp system in Mathematica,
or vice versa. For you to say that you have to learn to use it
as is, is to deny the nature of software.
E.g. "Semantica" tried to fix the matching in Mathematica.
RJF
Bill Rowe
wrote:
>On 12/9/2010 11:31 PM, Bill Rowe wrote:
>>(Bill) No. I merely claim the current behavior of replacement rules
>>is not a bug or a design error.
>On what basis do you make this claim?
Several posters who work for WRI have stated the behavior is not
a bug and the behavior is consistent with the documentation.
>>I don't have access to the source code and simply do not know what it
>>would take to implement the changes
>Neither do I. But I believe that for a careful design, the changes
>would be minor. I have access to the source code for a similar
>program.
Access to the source code of a similar program cannot tell you
how easy/difficult something is to implement in Mathematica.
You've no basis for assuming the code in Mathematica is
partitioned in the same manner, uses the same approaches etc as
your similar program. All access to source code for a similar
program does is tell you how easy it would be to change that
similar program, not Mathematica. So, your belief the changes
needed to implement what you would prefer to see as the behavior
of replacement rules has no factual support.
>>you would like or what impact it might have on other parts of
>>Mathematica.
>I find it hard to believe that any part of Mathematica REQUIRES the
>behavior that 3+4I /. I->-I result in 3+4I unchanged but 3+bI /.
>I->-I result in 3+bI
>What do you think?
The current design requires this behavior. 3+4I/.I->-1 yields
3+4I for the same reason 2.345/.2->1 yields 2.345. That is,
despite the way it appears on screen, to Mathematica 3+4I is a
single entity with no parts. You can replace the entire entity
but not part of it.
In contrast a+b*I is an expression with constituent parts that
can be operated on by replacement rules. The fact that 3+4I and
a+b*I get displayed in the same manner does not make these the same.
Now, I agree, the current design of Mathematica is not
immutable. And for some a change in the design might be highly
desirable. But I don't know how difficult such a change would be
or what the impact of such a change would be. However, it does
seem to me making changes to the representation of complex
numbers so that replacement rules could work as you seem to want
isn't likely to be a minor change.
>>Not at all. I make no claim changes are unthinkable. Mathematica
>>has changed many times from version to version and will undoubtedly
>>do so in future versions. Some of those changes will be ones I like
>>while others will be ones I dislike for one reason or another. But
>>I do understand my like/dislike of any past change or future change
>>in no way determines whether those changes are "bugs" or design
>>errors.
>It should be obvious to anyone that one determinant in whether some
>change in a program is a "bug" or not is whether users dislike those
>changes. It is not the only factor, but to say that your view "in
>no way determines...[bughood]" is something that you, and perhaps
>others, should reconsider.
>Would you feel the same way about the provider of any other good or
>service -- that the brewer's new beer formulation must be better
>because he says so, even if you dislike it? That the car steers
>better because the manufacturer says so? etc. etc.
If the brewer's new beer formulation wasn't to my liking, I
wouldn't buy it again from him. Instead I would get beer from
another brewer. But my dislike of one brewer's formulation
doesn't equate to that formulation being a design error/flaw or bug.
In the same fashion, a users dislike of some behavior in
Mathematica in no way makes that behavior a bug or design error.
If there are enough users that want the behavior changed, then
possibly WRI will implement the change. If WRI becomes totally
unresponsive to users, then there is opportunity for competitors
to WRI. Eventually, being totally unresponsive to your user base
will mean you have no users.
My experience is software developers react much better to
reasoned requests for changes then they do claims behavior that
is precisely as they intended is a bug and must be changed. In
fact, repeated claims of such behavior being a bug tends to get
the same response as outlined in the parable of the boy who
cried "Wolf" when there was none.
Richard Fateman
>> It's a consequence of two very simple considerations:
>>
>> 1. Pattern matching works on FullForm.
>>
>> 2. Pattern matching can't split atoms.
>>
>> What's so hard about this?
being right 50% of the time suggests that maybe it is hard.
You can write a pattern like Rational[n_,m_]-> f[n,m]
So your item 2. is wrong.
and probably your item 1 is overly simplified for tricky cases.
RJF
Andrzej Kozlowski
On 12 Dec 2010, at 18:02, Richard Fateman wrote:
> I find it remarkable that you can claim this is a solution. First of all, the original poster said that he was taken by surprise that there
> are two rather simple expressions where both are simplified, and which print the same, and both have the same meaning, but don't
> match. Your response is to write a pattern that matches them both by including each as a separate pattern.
>
> This is a bug, in my opinion. And there is a way around it, which is to
> always parse an inequality or equality of more than 2 arguments as
> inequality. e.g. a==b==c is Inequality(a,Equal,b,Equal,c). I recall doing this when I implemented my parser in Mockmma.
>
> Note that one can
> construct such things in Mathematica, e.g.
> a<b<=c /. LessEqual-> Less
> which has FullForm Inequality[a,Less,b,Less,c].
>
> But if you type it in as a<b<c, it is Less[a,b,c].
> So you have two items whose 'difference' does not simplify to zero,
> and which is not simplified by FullSimplify[] to zero.
>
> (parenthetically, (3<4) - (5<6) DOES simplify to zero. )
>
> I would be surprised to find other people so accepting of this "solution".
>
> RJF
>
Do you mean a user should not be allowed to enter Less[2,x,3] but always required to use the form Inequality[2,Less,x,Less,3]? Or should Less[2,x,3] always evaluate to Inequality[2,Less,x,Less,3]? (In that case you would still have the same problem if, for some reason, you prevented evaluation). What about expressions such as
x > 2 && x < 3? Should you now be allowed to enter them and required always to enter Inequality[2, Less, x, Less, 3] instead? Or should they always be converted to that form? Even if that was feasible, what about its effect on performance?
Personally, your idea does not make much sense to me.
I also don't understand however why you seem to consider a<b<c as equivalent to a<b<c. If you really think they are equivalent, I don't think you will find many who agree with you. But then probably you meant something else.
There is, by the way, another "solution", that I am sure you will also not like (so I am mentioning it only for general information). One can always get rid of all "Inequalities" in an expression expr by means of the pattern:
expr/.y__Inequality :> LogicalExpand[y]
Once you do that, all inequalities in the expr will involve (conjunctions ) of Less, LessEqual etc, and can be matched without any ambiguity.
By the way, I see that in another thread you argued that a bug is anything that a user dislikes (maybe I am misrepresenting you again but if so you make it terribly easy). Do you mean any user or many users or perhaps just one very important user (Fields medal winner?) I had the impressions that bugs were things that were generally disliked by almost all users. I honestly don't know of any "bug" in ordinary sense of the word about which most or even a significant number of users would say "I like it just fine the way it is now". So I get a distinct impression that, like Humpty Dumpty, you believe that words mean exactly what you want them to mean.
Andrzej Kozlowski
Richard Fateman
> On 12/11/10 at 1:52 AM, fat...@cs.berkeley.edu (Richard Fateman)
> wrote:
>
>> On 12/9/2010 11:31 PM, Bill Rowe wrote:
>
>>> (Bill) No. I merely claim the current behavior of replacement rules
>>> is not a bug or a design error.
>
>> On what basis do you make this claim?
>
> a bug and the behavior is consistent with the documentation.
I have said that too. That WRI says "[we] meant to do that".
That does not, however, mean they are correct. All it means is that
do not have a stated current intention to change the program or the
documentation.
>
>>> I don't have access to the source code and simply do not know what it
>>> would take to implement the changes
>
>> Neither do I. But I believe that for a careful design, the changes
>> would be minor. I have access to the source code for a similar
>> program.
>
> Access to the source code of a similar program cannot tell you
> how easy/difficult something is to implement in Mathematica.
Sure it can. Not in all cases, but in some cases the requirements
of a program provide a fairly clear basis on which to design
an implementation. There are several open-source pattern match
programs similar to Mathematica's (e.g. mine, Kevin McIsaac's
http://www.reduce-algebra.com/docs/pm.pdf, matheclipse, ...)
> You've no basis for assuming the code in Mathematica is
> partitioned in the same manner, uses the same approaches etc as
> your similar program.
Actually, you are wrong. There is a basis for assuming the code
is similar. (a) Its behavior (including misfeatures) is predictable
based on some assumptions of similarity. (b) Sometimes there
are not really so many reasonable ways of doing something.
> All access to source code for a similar
> program does is tell you how easy it would be to change that
> similar program, not Mathematica.
Again, wrong.
> So, your belief the changes
> needed to implement what you would prefer to see as the behavior
> of replacement rules has no factual support.
In your opinion, but you are being mislead by your incorrect assumptions.
>
>>> you would like or what impact it might have on other parts of
>>> Mathematica.
>
>> I find it hard to believe that any part of Mathematica REQUIRES the
>> behavior that 3+4I /. I->-I result in 3+4I unchanged but 3+bI /.
>> I->-I result in 3+bI
>
>> What do you think?
>
> The current design requires this behavior.
No, the program simply implements the design. Do you think there
is a program already in existence [not written for illustrating this
bug/feature] that relies on this behavior to get a correct answer?
3+4I/.I->-1 yields
> 3+4I for the same reason 2.345/.2->1 yields 2.345.
2.345/.2->1 does not yield 2.345.
It yields
11.725 -> 1
And for an entirely different reason, which is that Mathematica
parser requires a space after "/." when the next token is
a number.
Personally, I would have no problem if Mathematica implemented
"2.345" /. "2"->"1" to yield "1.345"
instead it requires
StringReplace["2.345", "2" -> "1"]
so the "reason" your (repaired) example doesn't work is that the
example doesn't indicate to the system that you are apparently
concerned with the character representation of "2.345" not its
numerical value, which has many possible representations, and
internally it is presumably a binary number of some sort, and
as a binary number it does not have any "2" in it.
That is,
> despite the way it appears on screen, to Mathematica 3+4I is a
> single entity with no parts. You can replace the entire entity
> but not part of it.
Well, is that a good thing or a bad thing? Does it HAVE to be that way?
>
> In contrast a+b*I is an expression with constituent parts that
> can be operated on by replacement rules. The fact that 3+4I and
> a+b*I get displayed in the same manner does not make these the same.
Again, it doesn't have to be that way. Not every computer algebra
system has the same restrictions.
>
> Now, I agree, the current design of Mathematica is not
> immutable. And for some a change in the design might be highly
> desirable. But I don't know how difficult such a change would be
> or what the impact of such a change would be.
It seems to me that we are discussing what the impact of such a
change would be. I say it would be beneficial. You seem to have
claimed either it shouldn't be done, or can't be done. Now you
are claiming that you don't know what the impact would be.
So now you have no opinion?
> However, it does
> seem to me making changes to the representation of complex
> numbers so that replacement rules could work as you seem to want
> isn't likely to be a minor change.
Why do you think it requires a change in the representation? As I
have said previously, the change could be made in ReplaceAll and
ReplaceAllDelayed.
It is, I think, not too hard to change (vanishingly rare) case of
"expression is Complex" + "pattern is number" from "DONT DO IT"
to "DO IT".
I say this, once again, from having written such a program. You
seem to think it would be somehow wrong based on not "know[ing] how
difficult such a change would be".
.. snip..
> If the brewer's new beer formulation wasn't to my liking, I
> wouldn't buy it again from him. Instead I would get beer from
> another brewer.
It is a harder to change from one software system to
another, than to choose a different beer, at least in most
countries. Imagine if there were only one brand of beer.
> But my dislike of one brewer's formulation
> doesn't equate to that formulation being a design error/flaw or bug.
Tell that to the people who designed "New Coke"
http://en.wikipedia.org/wiki/New_Coke
>
> In the same fashion, a users dislike of some behavior in
> Mathematica in no way makes that behavior a bug or design error.
no, it does make it an error, in some way.
> If there are enough users that want the behavior changed, then
> possibly WRI will implement the change.
well, it could be enough users, or a strong enough argument, which
would include "it does not harm anyone and makes the system
easier to document".
If WRI becomes totally
> unresponsive to users, then there is opportunity for competitors
> to WRI. Eventually, being totally unresponsive to your user base
> will mean you have no users.
Really? Consider industrial monopolies. Consider totalitarian regimes.
Consider software operating system "lock-ins".
>
> My experience is software developers react much better to
> reasoned requests for changes then they do claims behavior that
> is precisely as they intended is a bug and must be changed.
Oh, so now you want me to be polite. That costs extra.
> In
> fact, repeated claims of such behavior being a bug tends to get
> the same response as outlined in the parable of the boy who
> cried "Wolf" when there was none.
Except, of course, I've reported plenty of acknowledged bugs, and
whether (whatever you are defending) is a bug or not, has been
raised, repeatedly, by various posters.
RJF
Daniel Lichtblau
----- Original Message -----
> From: "Jack L Goldberg 1" <jack...@umich.edu>
> To: math...@smc.vnet.net
> Sent: Sunday, December 12, 2010 4:47:32 AM
> Subject: Re: Replacement Rule with Sqrt in denominator
> this came up I eventually realized the problem and worked around it in
> essentially the same way you suggested. Getting around it is one
> thing but why it happens is another. After all, such behavior is
> really poor design. Why should I have to spend hours on this "feature"
> until I discovered that the FullForm of input 2<=x<=4 is not the same
> as the FullForm of the output of Reduce[2<=x<=4]? The Reduce function
> was imbedded in 50 lines of code and the error did not immediately
> suggest itself because there were many references to other functions
> throughout the code which could have been the culprit. This suggests
> that EVERY functions that returns 2<=x<=4 as output must be examined
> to see its FullForm before it can be used further, especially if one
> wants Part of the expression. Andrzej keep in mind the surprise
> factor here. Two functions return 2<=x<=4 but their outputs have
> different FullForms!
>
> Well maybe I'm nuts but this is bad functionality IMO. I can't help
> wondering whether there are other examples of this kind and when they
> are going to bite me.
>
> Jack
Andrzej Kozlowski responded to this. Let me add or emphasize a few points.
(1) The documentation of Inequality is lacking. I will file a suggestion report that it be improved, and better linked to LessEqual et al.
(2) There are good reasons to have both Inequality and chaining of e.g. LessEqual. It is advantageous to have a general form that handles intricacies the special cases do not (e.g. a<b<=c). But there is the drawback that we then have a general form that overlaps with the specialized forms. Of course having results returned (e.g. by Reduce) using that general form makes some sense, but then leads to the confusion you report.
I do not know if this extends to many functions beyond Reduce, or whether it might be changed therein. I will ask about that.
(3) In the overlap cases of general vs. specialized inequality chains, both have the same StandardForm. I think this is appropriate at least from the point of view that StandardForm should reflect "reasonable" typography. But it subverts the notion that StandardForm should be unambiguous. These competing needs have clashed in other places in StandardForm, and I believe that resolutions have gone in both directions on a case-by-case basis. I'm giving my onw impression here; it's not an area in which I have much knowledge.
I will mention that neither InputForm nor FullForm are ambiguous in regards to Inequality vs. the specialized inequalities. So the situation is "What you see is not necessarily what you get, but if you change settings to "squint" mode then it will be." Or something to that effect.
> Quoting Andrzej Kozlowski <ak...@mimuw.edu.pl>:
>
> >
> > On 11 Dec 2010, at 07:52, Jack L Goldberg 1 wrote:
> >
> >>
> >> a) Input as typed: 2<=x<=4. Look at its fullform. On my Mac
> >> running ver. 7 of Mathematica, I get returned,
> >> LessEqual[2,x,4].
> >>
> >> b) Now type in Reduce[2<=x<=4]. You will get
> >> Inequality[2,LessEqual,x,LessEqual,4].
> >>
> >> These are are different expressions! How can one program
> >> replacement
> >> rules when one can not be sure of the FullForm? These structures
> >> are
> >> entirely different. Which fullform can one assume is the one
> >> Mathematica sees
> >> in some complicated module wherein one step is a replacement rule?
> >>
> >> Jack Goldberg
> >> Mathematics
> >> University of Michigan
> >>
> >
> > O.K. but I don't see anything here that in any way contradicts
> > anything that has been said about the need for
> > for looking at FullForm before trying pattern matching. Actually, it
> > is also an argument against using Copy and Paste. To see that,
> > evaluate Reduce[2<=x<=4]. Now, copy the output and paste it into
> > another cell and wrap FullForm around it, then evaluate. You will
> > get LessEqual[2,x,4].
> >
> > I don't see this as a problem, do you? You can certainly match both
> > forms with a single pattern:
> >
> > {2 <= x <= 4, Reduce[2 <= x <= 4]} /.
> > (a_) <= x <= (b_) | Inequality[a_, LessEqual, x, LessEqual, b_]
> > :> {a, b}
> >
> > {{2, 4}, {2, 4}}
> >
> >
> > Andrzej Kozlowski
Richard Fateman
>>> also realize there are people who will claim any result obtained
>>> is exactly what they intended.
>>
>> Certainly. In the software "engineeering" world there are notions
>> like "requirements" "specifications" "design" "detailed design"
>> "implementation" etc. And there are people who "prove" that
>> programs are correct because they satisfy the specifications even
>> though they are terrible because the requirements are inadequate.
>>
>> of the manipulation should be the mathematically correct one,
>> (if the correct result is unambiguous, mathematically)"
>>
>
> Yes, if it means guessing user intent.
I take that to be, "No, there is no argument if the correct result in
unambiguous, mathematically".
>
> I'll add that it is not generally a good idea to punch holes in the "usual"
> behavior to get some exceptional cases to "work" in some different way.
I am not sure about "punching holes", but if you take a standard
well-accepted and tested algorithm which has some error exits, and
replace those error exits with new facilities, it is a fairly
well accepted mode of operating, especially in computer algebra.
e.g. version n of a program gives an error message that says
sorry, you cannot use command X except on machine floating-point numbers.
version n+1 allows arbitrary precision numbers.
version n+2 allows symbolic input.
version n+3 allows files, graphics, web pages, whatever.
> It should be done sometimes, but it is a slippery slope.
occasionally.
>A major problem is that there are often unintended side effects.
yes, but replacing an error exit with an answer is a good heuristic.
There are certainly some kinds of unintended problems. For example,
you can define a function of 3 arguments
f3 = Function[{a, b, c}, a + b + c]
perhaps it should signal an error if you invoke it with 4 arguments
like f3[1,2,3,4]. In Mathematica those extra arguments are evaluated
but then discarded, no error message. It can be a useful debugging tool
to get a "wrong number of arguments" message, sometimes.
>This may not be an issue if you take an academic view.
> But if you are charged with maintaining or marketing the software then it becomes a different matter.
>
> I recently dug a big hole, and jumped inside it, in an attempt to make some rational
function algebra (e.g. Together and friends) do the "obvious" thing with
inputs containing
approximate number coefficients. Not yet sure if I am climbing out, or
still digging.
>
>
>>> (Bill) No. I merely claim the current behavior of replacement rules
>>> is
>>> not a bug or a design error.
>>
>> (RJF) On what basis do you make this claim?
>
> (DanL) One reasonable basis would be that the designers claim it is neither a bug nor a design error.
> You, as a user, are then quite entitled to opine that it was a bad
design.
> > That would be okay as an opinion. It is not the same thing as a
design error
> (as I understand the meaning) and it is quite far from a bug.
I think that a developer's opinion on design/implementation vis a vis
bugginess is a worthwhile consideration because the developer/designer
has probably had the advantage of carefully considering some
alternatives, perhaps implementing them, testing them, and found them
lacking in some significant way. I do not expect that the developer's
opinion is the sole determining factor. In big companies, such
important decisions are sometimes made, sad to say, by marketing
people.
>
>
>>> Bill? It may well be possible to change
>>> the behavior so that it is in some respect more user friendly
>>> without causing other inefficiencies or breaking things.
>>
>> (RJF) Aha, so you agree that there is some criterion, which you call
>> "user friendly". I might call it "mathematically consistent".
>> That is how one might make a useful distinction between a
>> "bug" and a "feature".
>
> (DanL That would involve a redefinition ofthe term "bug", as opposed to e.g. a bad design.
Perhaps sometimes. If I report what I believe to be a mathematical
inconsistency to (whoever), it sometimes gets acknowledged and perhaps
fixed with a small patch to some program. Sometimes it gets
acknowledged and remains unfixed because it does not seem to be easily
repaired. Maybe because it is embedded in the design? But it is
a mathematical inconsistency. I do not always know which category
it fits into, and so I call it a bug. If I report it to WRI,
my bug report could be categorized as "documentation error" , "user
error", "we meant to do that", ...
>
>
>> I find it hard to believe that any part of Mathematica REQUIRES the
>> behavior that
>> 3+4I /. I->-I result in 3+4I unchanged but
>> 3+bI /. I->-I result in 3+bI
>>
>> What do you think?
>
> It was asked of someone else, but I think the developer who makes the
>change would need to take care that nothing else of importance changed
as a side effect.
>It would also be desirable to check by some means whether the change
went sufficiently
> far as to capture what many users expect, without leaving loose ends.
Yep. I heard from somewhere that WRI has testing suites that take
days to run.
>
>
>>>> In my view it would be simple enough to completely define the
>>>> changes
>>>> necessary, document them, and implement them. I took the trouble to
>>>> write a paper and a sample implementation. It responds to certain
>>>> customers' issues.
>
> What is there is not necessarily what would be required for maintaining a commercial product.
Yep. I would have to convince someone at WRI to look at it.
Jason Harris is apparently not at WRI.
>
>
>>> Suggesting a change that would respond to the needs of certain
>>> users is one thing. Calling the current behavior of replacement
>>> rules a bug or design error is quite another.
>>
>> Um, it seems to me that we see messages on this newsgroup that look
>> like
>> requests by users to change the behavior to correspond to what they
>> think should happen. So these are not quite different at all.
>
> They are indeed quite different.
Some people are shy about saying "I found a bug in Mathematica".
Some people are, not shy about saying that.
Some shy people find bugs, some non-shy people haven't really
found bugs.
Some people want Mathematica changed for good reason. You could
call this a bug fix or a, um, product enhancement??
>
...snip ...
ders.
>>
>> (RJF) It should be obvious to anyone that one determinant in whether
>> some change in a program is a "bug" or not is whether users dislike
>> those changes. It is not the only factor, but to say that your
>> view "in no way determines...[bughood]" is something that you,
>> and perhaps others, should reconsider.
>
> These opinions do not determine the quality of being a bug.
>They may help to point to cases of bad design of some functionality.
>I do not think the examples in question qualify as such a case, but
clearly others disagree.
No, but such opinions should be one factor in determining bughood.
>
> If you wish to change, by extension, the meaning of "bug",
> then it behooves you to distinguish carefully what you are doing.
> Else you are likely to cheapen your own currency.
http://www.linfo.org/bug.html starts with
A bug, also referred to as a software bug, is an error or flaw in a
computer program that may prevent it from working correctly or produce
an incorrect or unintended result.
...
this leaves for further explanation, "error", "flaw", "incorrect" and
"unintended".
But when one reads stuff like (e.g. in documentation for Assumptions,
version 7.0)
"Mathematica normally makes as few assumptions as possible about the
objects you ask it to manipulate. This means that the results it gives
are as general as possible."
it means Mathematica is a wide target.
RJF
>
> Daniel Lichtblau
> Wolfram Research
>
Bill Rowe
wrote:
>On 12/10/2010 10:55 PM, Bill Rowe wrote: ....
>>With respect to replacement rules or any other behavior of
>>Mathematica you have a pretty limited choice for solving problems.
>>You can:
>>1) use different functions in Mathematica and ignore the behavior
>>you don't care for or don't want to take the time to understand
>>more thoroughly.
>>2) you can dig into the operation of the function until you do
>>understand how it behaves and can use it effectively
>>3) you can use something other than Mathematica to solve the
>>problem.
>4. You can request that the tool be modified by the vendor. The
>vendor will almost certainly do this if there is enough money at
>stake.
>5. You can build you own tools (after all, Mathematica is
>programmable). This is what I suggest in my paper, and which is done
>in a much more elaborate fashion by Harris' Semantica program.
>6. You can ask another person to write a suitable tool. (E.g. a
>student who can get credit for designing/writing/testing a program.)
Your 4) and 6) aren't very effective techniques for solving
problems. As for 5), it is what I had in mind with my 2). I had
not meant by 2) that you are limited to built-in functions even
though I can see the way I wrote it could be construed that way.
>>Most of the posters here are not WRI employees and have no access to
>>the source code. All they have access to is the same documentation you
>>have access to.
>You give the documentation too much credit. Most of the posters
>also have access to the program, and they determine its behavior by
>trial and error. I certainly do.
I also use "trial and error". But those "trials" are guided by
the documentation and are of the nature of understanding what
the documentation is saying. To me, this kind of "trial and
error" is expected with any software as complex as Mathematica.
>>For myself, I generally choose option 2). The payoff for option 2) is
>>as I increase my understanding of how Mathematica behaves in some
>>specific case, I find I have more confidence in the results I get and
>>I am better able to predict behavior for other problems. In this
>>respect, Mathematica is like any other complex tool. The better you
>>understand a tool, the more effectively you can apply that tool to a
>>new problem.
>For some tools, yes. But programs are different from (say)
>chainsaws in a very important respect. A chainsaw is a physical
>object that is fundamentally limited by its physical properties. A
>purchaser of a chainsaw probably cannot use it as (for example) a
>belt sander, or a bicycle, or a water pump.
>BUT
>Software in a general-purpose programmable language running on a
>digital computer with sufficient memory etc is almost infinitely
>mutable into other software. If you are sufficiently clever, you can
>change it: you can write a Lisp system in Mathematica, or vice
>versa. For you to say that you have to learn to use it as is, is to
>deny the nature of software.
You seem to have rather extreme interpretations of my remarks. I
really don't see how anything I said can be taken to "deny the
nature of software". Yes, physical tools are different than
software. Yes, I can view Mathematica as a general purpose
programming environment and use it to create any other software
I care to use. Of course, while it may be technically possible
to create something that looks and behaves like say Microsoft's
Excel using Mathematica, the end result is unlikely to be worth
the time and effort needed to achieve it. There are more
efficient ways to achieve such a result.
The only point I was attempting to make about learning
Mathematica "as it is", is that doing so enables you to more
efficiently create other things with it. Create the functions
needed to solve a problem or to use the existing functions to
solve a problem.
Richard Fateman
> On 12 Dec 2010, at 18:02, Richard Fateman wrote:
>
>> On 12/12/2010 2:46 AM, Andrzej Kozlowski wrote:
>> are two rather simple expressions where both are simplified, and which print the same, and both have the same meaning, but don't
>> match. Your response is to write a pattern that matches them both by including each as a separate pattern.
>>
>> This is a bug, in my opinion. And there is a way around it, which is to
>> always parse an inequality or equality of more than 2 arguments as
>> inequality. e.g. a==b==c is Inequality(a,Equal,b,Equal,c). I recall doing this when I implemented my parser in Mockmma.
>>
>> Note that one can
>> construct such things in Mathematica, e.g.
>> a<b<=c /. LessEqual-> Less
>> which has FullForm Inequality[a,Less,b,Less,c].
>>
>> But if you type it in as a<b<c, it is Less[a,b,c].
>> So you have two items whose 'difference' does not simplify to zero,
>> and which is not simplified by FullSimplify[] to zero.
>>
>> (parenthetically, (3<4) - (5<6) DOES simplify to zero. )
>>
>> I would be surprised to find other people so accepting of this "solution".
>>
>> RJF
>>
> Do you mean a user should not be allowed to enter Less[2,x,3] but always required to use the form Inequality[2,Less,x,Less,3]?
> Or should Less[2,x,3] always evaluate to Inequality[2,Less,x,Less,3]?
simplified to Inequality[x,Less,y]
> (In that case you would still have the same problem if, for some reason, you prevented evaluation).
much of anything to work.
I can' t think of a reason.
> What about expressions such as
> x> 2&& x< 3? Should you now be allowed to enter them
sure. resulting in And [ Inequality[x,Greater,2], Inequality[x, Less,3]]
> and required always to enter Inequality[2, Less, x, Less, 3] instead?
no, of course not.
> Or should they always be converted to that form?
not necessarily.
> Even if that was feasible, what about its effect on performance?
Depending on the nature of the inequalities, a subset of the problems
can be simplified.
(e.g. linear, or even polynomials over the reals)
It would be a judgment call as to whether to try this by default, by
invoking Simplify or
invoking FullSimplify or setting some options. It might make an
interesting project,
but there is certainly a (huge) literature on this.
> Personally, your idea does not make much sense to me.
Odd, since you seem to have figured out how to make it work.
> I also don't understand however why you seem to consider a<b<=c as equivalent to a<b<c.
I don't.
> If you really think they are equivalent,
of course not.
> I don't think you will find many who agree with you. But then probably you meant something else.
No, if one applies a rule Less->Equal, that does not usually result in
an identity-preserving transformation.
> There is, by the way, another "solution", that I am sure you will also not like (so I am mentioning it only for general information).
> One can always get rid of all "Inequalities" in an expression expr by means of the pattern:
>
> expr/.y__Inequality :> LogicalExpand[y]
>
> Once you do that, all inequalities in the expr will involve (conjunctions ) of Less, LessEqual etc, and can be matched without any ambiguity.
It's not a terrible solution if it solves the problem of canonical
simplifications of inequality constraints, which it might,
if computing (say) disjunctive normal form does the job. The description
of LogicalExpand, and the examples,
suggest that for the intended target domain it might not be canonical.
I don't have the patience to explore what
it really does, and since I have version 7.0, it might not even do the
same thing in version 8.0. So all I can say is
I think it doesn't solve the problem, but it might.
> By the way, I see that in another thread you argued that a bug is anything that a user dislikes (maybe I am misrepresenting you again but if so you make it terribly easy).
No, I said that if a user (or many users) say that they would prefer a
different answer from the one that is
delivered by the software, (indeed the bold ones might call the answer a
bug) that is a factor in whether
something is indeed something should be changed (that is, should the
alleged bug be treated as
an actual bug and be fixed. ). There are other contributory factors in
determining whether something
should be fixed. (And I don't really distinguish between fixing a
"feature" and fixing a "bug" if it needs
to be fixed.)
> Do you mean any user
Well, in principle, any user can find (what I would consider) a bug.
Many user-reported "bugs" may not qualify, in
my judgment. But a bug tends to stand on its own feet, regardless of
who reports it.
> or many users
many users reporting the same bug would be more supportive, but not
determinative. As I have pointed out,
WRI does not operate on the principle of "the customer is always right".
> or perhaps just one very important user (Fields medal winner?)
I think that depends on whether he (or she) has found a bug. Maybe a
bug report from a famous person would
get faster attention from higher-up in the food chain at WRI. As I said
previously, I think this is some marketing
decision too. If there were some company that paid a large license fee
each year and the contact point for
that contract complained (and maybe threatened to cancel), then that
person can define a bug in any way
he (or she) wants.
> I had the impressions that bugs were things that were generally disliked by almost all users.
No, that would be great because you could then find all the bugs in a
system just by asking almost anyone.
In fact, most users are quite unaware of most bugs.
> I honestly don't know of any "bug" in ordinary sense of the word about which most or even a significant number of users would say "I like it just fine the way it is now".
I am not sure what your point is. Obviously if a particular user
identifies a particular behavior as a bug that can be
fixed, he/she would ordinarily prefer that it be fixed. I think that is
what you are saying.
As I said, most users don't even know of most bugs, so they have no
opinion about them. If they are given an example
of a situation in which Mathematica gives a subtlely wrong answer, they
might say, Oh, that looks fine.
But if they are shown why it is wrong, and what the right answer, they
might say "Oh, that would be better".
Andrzej Kozlowski
On 12 Dec 2010, at 23:48, Richard Fateman wrote:
>>>
>> Do you mean a user should not be allowed to enter Less[2,x,3] but
always required to use the form Inequality[2,Less,x,Less,3]?
> I did not propose to tie the user's hands in this way.
>> Or should Less[2,x,3] always evaluate to
Inequality[2,Less,x,Less,3]?
> That would be my solution,. Is my solution. Indeed, Less[x,y] is
simplified to Inequality[x,Less,y]
>> (In that case you would still have the same problem if, for some
reason, you prevented evaluation).
> If I prevented simplification/evaluation, I would presumably not
expect much of anything to work.
> I can' t think of a reason.
First in Mathematica, there are often functions that have attributes
HoldAll or Hold First etc, which means that the act on unevaluated
arguments. So if an argument was written as Less[x,y] it would not be
converted to Inequality[x,Less,y] before pattern matching was applied to
it (most Mathematica "functions" are just local pattern matching rules).
But much more importantly and, in my opinion, crucially (that was the
main point of my reply, but somehow you managed to skirt around so I
will now try to make it as explicit as I can):
if Less[x,y] was always automatically converted to Inequality[x,Less,y]
than clearly LogicalExpand[Inequality[x, Less, y]] would not longer
work, and what's worse LogicalExpand[Inequality[x, Less, y, LessEqual,
z]] etc. would not work.
But that would make it vastly harder to get expressions involving
inequalities into a canonical form.
As it is now, an expression involve both Inequality[x, Less, y,
LessEqual, z] and And[Less[x,y],LessEqual[y,z]] (which is simply
x<y&&y<=z). Both of these are equivalent and obviously you would want
any patterns to apply to both. As things work now, all you need to do is
to use LogicalExpand to replace all expressions with Inequality by
canonical forms and you can do unambiguous pattern matching. If your
approach were adopted this would not be possible. Instead you would have
to pick out all the different x<y and y<=z in your expression, and
"simplify" them to a canonical form involving Inequality. But this
clearly would a great deal more complex than just applying
LogicalExpand. For a start, the expression could involve many
conjunctions and disjunctions so that x<y and y<=z would not
necessarily appear next to each other, i.e. it could be something like
x<y&&...various relations ...y<=z&&... . I think my point should now
be clear - what you are proposing would probably greatly increase the
complexity of working with inequalities and may well be impracticable.
Thus implementing your idea would probably amount to introducing a
terrible bug into Mathematica, in your own terminology.
Andrzej Kozlowski
Richard Fateman
I find it remarkable that you can claim this is a solution. First of
Andrzej Kozlowski
On 13 Dec 2010, at 17:11, Richard Fateman wrote:
> On 12/13/2010 12:52 AM, Andrzej Kozlowski wrote:
>> On 12 Dec 2010, at 23:48, Richard Fateman wrote:
>>
>>>>>
>>>> Do you mean a user should not be allowed to enter Less[2,x,3] but
>> always required to use the form Inequality[2,Less,x,Less,3]?
>>> I did not propose to tie the user's hands in this way.
>>>> Or should Less[2,x,3] always evaluate to
>> Inequality[2,Less,x,Less,3]?
>>> That would be my solution,. Is my solution. Indeed, Less[x,y] is
>> simplified to Inequality[x,Less,y]
>>>> (In that case you would still have the same problem if, for some
>> reason, you prevented evaluation).
>>> If I prevented simplification/evaluation, I would presumably not
>> expect much of anything to work.
>>> I can' t think of a reason.
>>
>> First in Mathematica, there are often functions that have attributes
>> HoldAll or Hold First etc, which means that the act on unevaluated
>> arguments. So if an argument was written as Less[x,y] it would not be
>> converted to Inequality[x,Less,y] before pattern matching was applied =
to
>> it (most Mathematica "functions" are just local pattern matching =
rules).
>
> Um, I think this is irrelevant. Consider the "function" in =
Mathematica
> Divide. It exists in Mathematica.
>
> Divide[a,b] is immediately transformed to Times[a,Power[b,-1].
>
> Divide[a,b] /. Times-> Foo results in Foo[a,Power[b,-1]].
>
> Divide has attributes Protected, Listable, NumericFunction.
>
> It's not that different from Less, in some senses:
> (a). Divide can always be rewritten as Times[Power ..] or as Rational.
> (a') Less can always be rewritten as Inequality[ ..], at least if
> Mathematica didn't insist on rewriting in the opposite direction,
> namely making Inequality[a,Less,b] into Less[a,b].
> (b). Divide does not have attributes Hold, HoldFirst, etc etc
> (b') Neither does Less.
>
> So now we have set the stage for DanL and friends.
> 1. Remove Less. and always replace it with Inequality ...
> 2. Same for Greater, etc etc.
> 3. (suggestion) Rename Inequality with Comparison.
> 4. modify the rest of the programs, like Compile, Display, as =
necessary.
> 5. Change the documentation.
>
>
> There may still be work to do for dealing with the elements in
> Mathematica that do not obey the "law of trichotomy", which states
> that a<b, a==b, or a>b. But this is not true for objects that are
> not comparable. Like Complex numbers, various undefined objects,
> Indeterminate, NaN.
>
>
Yes, this seems plausible, but of course it would require a fundamental
re-write of Mathematica for a very minor gain (though I admit that there
would be some gain). But I would much rather Wolfram employed its
resources on developing many new functions and algorithms that I
actually use and that are important to me, so I would strenuously object
to any idea of diverting these resources to anything of this kind. As I
have pointed out to you many times, I consider these sort of things that
seem to excite you so much as essentially of very little practical
interest to the "working mathematician". I would certainly not pay any
money to get this sort of improvement and I doubt many users would.
>
> Note that LogicalExpand does not distinguish between Less[x,y,z] and
Inequality[x,Less,y,Less, z].
What do you mean by note? I pointed this out to you, LogicalExpand
reduces both to the same canonical form.
I am curious if you really believe your own words when you write stuff
like this and whether I really like to imagine you discovered it all by
yourself or knew it anyway.
>
> FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
> does not reduce to zero, as it should. So Mathematica, dare
> I say, exhibits a bug.
No, these expressions are not equal but logically equivalent. The way to
show that is
In[103]:= Refine[Less[x, y, z], Inequality[x, Less, y, Less, z]]
Out[103]= True
In[104]:= Refine[Inequality[x, Less, y, Less, z], Less[x, y, z]]
Out[104]= True
or by using LogicalExpand (as you noticed below)
>
> Oh, LogicalExpand[Inequality[x,Less,y,Less,z]] is x<y&&y<z
> as is LogicalExpand[x<y<z].
>
>
> Actually, you appear to be wrong, since
> LogicalExpand[x<y<z] and LogicalExpand[z>y>x] are different.
Again,
In[107]:= Refine[x < y < z, z > y > x]
Out[107]= True
In[108]:= Refine[z > y > x, x < y < z]
Out[108]= True
Actually, it would be good to have a function that checked both
implications at once (Refine performs the job of ImpliesQ in older
versions of Mathematica).
>
> You appear to be proposing some
> kind of alternative to disjunctive normal form (or conjunctive normal
> form), both of which are quite well studied. Re-grouping of logical
> terms for logic synthesis is also quite well studied, (see circuit
> minimization). The general circuit minimization problem is believed to
be intractable. Apparently there are advantages to a computer science
> education :)
I am certainly not proposing this, as should have been quite clear from
what I wrote. I had assumed, I admit mistakenly, that that was what you
were proposing as it did not come to my mind that you were instead
proposing a massive re-write of Mathematica that would, in effect,
eliminate Greater, Less etc. Thank you for confirming that the approach
I thought you had proposed is intractable, as I had expected.
I agree that there are some advantages to a computer science education -
I do actually teach mathematics, and Mathematica, to some excellent
computer science students (among the best in the world). But I think
there are even more advantages to a mathematics education. For one, one
is less inclined to keep eternally circling the same basic issues rather
than getting to some interesting problems.
Andrzej Kozlowski
Andrzej Kozlowski
On 13 Dec 2010, at 17:53, Andrzej Kozlowski wrote:
>>
>> FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
>> does not reduce to zero, as it should. So Mathematica, dare
>> I say, exhibits a bug.
>
In fact, I am (almost) amazed to see you claim that. There are certainly
advantages to having a mathematics education for I am sure that nobody
with that would ever expect this to work. What sort of algebraic
structure is this subtraction taking place in, according to you? What
sort of algebraic transformations is FullSimplify supposed to use here?
Good grief!
As I already pointed out:
Refine[Less[x, y, z], Inequality[x, Less, y, Less, z]] &&
Refine[Inequality[x, Less, y, Less, z], Less[x, y, z]]
True
This simply means that truth of each expression implies the truth of the
other - which is all that you could expect Mathematica to tell you.
And please do not point out that
(2 < 3) - (5 < 7)
0
for you surely know that what is going on here has is an entirely
different thing.
Andrzej Kozlowski
Richard Fateman
> On 13 Dec 2010, at 17:53, Andrzej Kozlowski wrote:
>
>>> FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
>>> does not reduce to zero, as it should. So Mathematica, dare
>>> I say, exhibits a bug.
> In fact, I am (almost) amazed to see you claim that. There are certainly advantages to having a mathematics education for I am sure that nobody with that would ever expect this to work. What sort of algebraic structure is this subtraction taking place in, according to you? What sort of algebraic transformations is FullSimplify supposed to use here?
is, in Mathematica, True - True is zero.
You may argue that truth values do not support subtraction as an
operation, but then you are imposing either
an algebraic structure (mathematically speaking) or a type system
(programming-language speaking -- or
perhaps mathematically, a category theory), on Mathematica. There is
very little evidence of such sensitivity
in Mathematica, and I, for one, am not a keen fan of imposing such a
structure in a computer algebra system
that is kind of open ended.
The algebraic transformation that FullSimplify can, and I think should,
apply, is <object X> - <object X> --> 0.
This is ordinarily, but not universally true
. e.g. Indeterminate - Indeterminate is not zero.
Nor is it zero for X= Interval[{-1,1}].
But True - True seems to me kind of OK to simplify to 0.
After all, if someone has asked you to do subtraction on these things, he
might know what he is doing. Maybe he is just a physicist, and not
particularly educated in modern algebra or programming language types.
(I could also suggest circumstances in which True-True is not a great idea,
and what should be used is TautologyQ[p==q] rather than p-q. But in this
case, especially because it means that I disagree with you, I will defend
the usage FullSimplify[p-q], which could be interpreted as
Tautology[p==q].)
> Good grief!
>
> As I already pointed out:
>
>
> Refine[Less[x, y, z], Inequality[x, Less, y, Less, z]]&&
> Refine[Inequality[x, Less, y, Less, z], Less[x, y, z]]
>
> True
>
> This simply means that truth of each expression implies the truth of the other - which is all that you could expect Mathematica to tell you.
I don't understand why you think that. I can expect Mathematica, when
asked, to convert each of these expressions to
a canonical form. I would prefer, at the moment, to have the
simplification be Less[x,y,z] --> Inequality[x,Less,y,Less,z] or
perhaps Comparison[x,Less,y,Less,z] or even
And[Comparison[x,Less,y],Comparison[y,Less,z]].
Comparisons, especially inequality, of more than 2 items is tricky. 1
!= 2 != 1 is, by convention, false, and is not the
same as not[1==2==1].
> And please do not point out that
>
> (2< 3) - (5< 7)
>
> 0
>
> for you surely know that what is going on here has is an entirely different thing.
Not at all. It means exactly what I intend it to mean, which is True -
True, which is a simple way of comparing two objects
to see if they are isomorphic.
Mathematica also can subtract strings, "abc" -"abc" is 0.
Mathematica also can subtract Graphics objects. Plot[Sin[x],{x,-1,1}] -
Plot[Sin[x],{x,-1,1}] is 0.
If you don't like this behavior, I suggest you report it as a bug.
RJF
Richard Fateman
> On 13 Dec 2010, at 17:11, Richard Fateman wrote:
>
> ....
>>
>> So now we have set the stage for DanL and friends.
>> 1. Remove Less. and always replace it with Inequality ...
>> 2. Same for Greater, etc etc.
>> 3. (suggestion) Rename Inequality with Comparison.
>> 4. modify the rest of the programs, like Compile, Display, as necessary.
>> 5. Change the documentation.
>>
>>
>> There may still be work to do for dealing with the elements in
>> Mathematica that do not obey the "law of trichotomy", which states
>> that a<b, a==b, or a>b. But this is not true for objects that are
>> not comparable. Like Complex numbers, various undefined objects,
>> Indeterminate, NaN.
>>
>>
> Yes, this seems plausible, but of course it would require a fundamental re-write of Mathematica for a very minor gain (though I admit that there would be some gain).
I'm not so convinced it would be a fundamental rewrite. I have made
other suggestions that
would be more of a challenge, some of which were implemented. I think
it might be incompatible
with some existing programs that depend on the syntactic property of the
Heads of Less, etc.
But those program which perhaps would not operate on
Inequality[a,Less,b,Less,c], but require Less[a,b,c]
might be, as one says, "in error" even if that error is not exhibited.
> But I would much rather Wolfram employed its resources on developing many new functions and algorithms that I actually use and that are important to me, so I would strenuously object to any idea of diverting these resources to anything of this kind.
I think WRI can allocate resources without your pre- (or post-)
censoring the list to exclude things not of interest to you personally.
> As I have pointed out to you many times, I consider these sort of things that seem to excite you so much as essentially of very little practical interest to the "working mathematician". I would certainly not pay any money to get this sort of improvement and I doubt many users would.
My objections to the way small things are handled has to do with the
hierarchical nature
of a computer algebra system. That is, if you get some of the little
things "just a little wrong"
(maybe something a physicist might not notice), then it is harder to
build on top of
that foundation. That's why I feel strongly about (say) arithmetic. Or
returning answers
that are right except at a few (unstated) places. (few= something like
a space of lower dimension).
>> Note that LogicalExpand does not distinguish between Less[x,y,z] and Inequality[x,Less,y,Less, z].
> What do you mean by note? I pointed this out to you, LogicalExpand reduces both to the same canonical form.
It is not a canonical form.
If it were, LogicalExpand[a<b<c] would be the same as
LogicalExpand[c>b>a]
> I am curious if you really believe your own words when you write stuff
Generally, except when I make a typo, or are being sarcastic, yes.
Occasionally I may mis-read or misinterpret something.
> like this and whether I really like to imagine you discovered it all by yourself or knew it anyway.
>
>> FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
>> does not reduce to zero, as it should. So Mathematica, dare
>> I say, exhibits a bug.
> No, these expressions are not equal but logically equivalent. The way to show that is
>
> In[103]:= Refine[Less[x, y, z], Inequality[x, Less, y, Less, z]]
>
> Out[103]= True
>
> In[104]:= Refine[Inequality[x, Less, y, Less, z], Less[x, y, z]]
>
> Out[104]= True
>
> or by using LogicalExpand (as you noticed below)
>
>> Oh, LogicalExpand[Inequality[x,Less,y,Less,z]] is x<y&&y<z
>> as is LogicalExpand[x<y<z].
>>
>>
>> Actually, you appear to be wrong, since
>> LogicalExpand[x<y<z] and LogicalExpand[z>y>x] are different.
> Again,
>
> In[107]:= Refine[x< y< z, z> y> x]
>
> Out[107]= True
>
> In[108]:= Refine[z> y> x, x< y< z]
>
> Out[108]= True
All you have to do is print out LogicalExpand[x<y<z] and
LogicalExpand[z>y>x] to see that they are different.
That is the point of a canonical form.
You are asserting that "Refine" can be used. Thus Refine, in the
computer algebra terminology, is
a Zero Equivalence algorithm. (or a Logical Tautology algorithm, in
some sense).
> Actually, it would be good to have a function that checked both implications at once (Refine performs the job of ImpliesQ in older versions of Mathematica).
It would seem that something likeTautologyQ could do that, but it assumes
that the components are Boolean, and not, as here, something like numbers.
Note that you can
do this, in Mathematica:
E1 = 0<foo[]<2
E2 = LogicalExpand[E1]
x=1
foo[]:=x++
E1 is True, E2 is False.
Is it a bug? Well, in the world of programming languages, the expression
(0< foo[]) && (foo[]<2) is considered inefficient and maybe wrong because
of possible side effects, especially if what you really mean is (in
mathematica syntax...)
Module[{b=foo[]}, (0<b)&&(b<2)].
LogicalExpand and other things tend to fall apart when functions have
side effects.
Computer science students are occasionally taught about such things for
generating
code in compilation.
If Mathematica were to be considered as (say) comparable to Lisp, and
LogicalExpand
considered as some kind of optimization of code, then this would indeed
be an error.
(Big if, there.)
>> You appear to be proposing some
>> kind of alternative to disjunctive normal form (or conjunctive normal
>> form), both of which are quite well studied. Re-grouping of logical
>> terms for logic synthesis is also quite well studied, (see circuit
>> minimization). The general circuit minimization problem is believed to be intractable. Apparently there are advantages to a computer science
>> education :)
> I am certainly not proposing this, as should have been quite clear from what I wrote.
It wasn't, at least to me.
> I had assumed, I admit mistakenly, that that was what you were proposing as it did not come to my mind that you were instead proposing a massive re-write of Mathematica that would, in effect, eliminate Greater, Less etc.
You are assuming I am proposing that someone should do a massive
rewrite. I am assuming that
this alternative view of comparison would be educational to you, other
readers, and to WRI people
who may or may not have thought about it. WRI would presumably decide
whether this was
a good idea, and that would include consideration of how much of a
rewrite it would be. And whether
it would be exposed to the user or not. I suspect that defining
Greater, Less, etc.
in terms of a single operator, Inequality (or Comparison) would be
possible and advantageous,
but would possibly break existing programs that might refer explicitly
to Less and Greater and ...
Note that the same philosophy Just as if WRI had included Divide, but
only later decided to eliminate it in favor of
Times[ ..., Power[....,-1]]
I agree with the notion that it would be easier to adopt this strategy
early on in the design of a system.
So sometime in the future someone may write another system in which
Comparison takes the place
of Less,Greater,LessEqual,GreaterEqual,Equal,Unequal,SameQ,unSameq,
Equivalent,... ? any more??.
> Thank you for confirming that the approach I thought you had proposed is intractable, as I had expected.
Well, I thought it was your approach. But maybe it was your
misunderstanding of what I had written.
It certainly wasn't mine. And I hope it wasn't what I wrote.
> I agree that there are some advantages to a computer science education - I do actually teach mathematics, and Mathematica, to some excellent computer science students (among the best in the world).
> But I think there are even more advantages to a mathematics education.
I do not see these as mutually exclusive.
> For one, one is less inclined to keep eternally circling the same basic issues rather than getting to some interesting problems.
To each his own. I would hardly be one to deny you the opportunity to
make snarky comments about
computer science research.
RJF
Bill Rowe
wrote:
>On 12/12/2010 2:41 AM, Bill Rowe wrote:
>>On 12/11/10 at 1:52 AM, fat...@cs.berkeley.edu (Richard Fateman)
>>wrote:
>>Access to the source code of a similar program cannot tell you how
>>easy/difficult something is to implement in Mathematica.
>Sure it can. Not in all cases, but in some cases the requirements of
>a program provide a fairly clear basis on which to design an
>implementation. There are several open-source pattern match
>programs similar to Mathematica's (e.g. mine, Kevin McIsaac's
>http://www.reduce-algebra.com/docs/pm.pdf, matheclipse, ...)
>>You've no basis for assuming the code in Mathematica is partitioned
>>in the same manner, uses the same approaches etc as your similar
>>program.
>Actually, you are wrong. There is a basis for assuming the code is
>similar. (a) Its behavior (including misfeatures) is predictable
>based on some assumptions of similarity. (b) Sometimes there are not
>really so many reasonable ways of doing something.
Let me clarify. One can always say there is a basis for
assumptions. But, having a basis for assumptions doesn't make
the assumptions valid. In essence, to reason something will be
easy to implement in Mathematica because it is easy to do in a
similar program requires assumptions about how Mathematica is
coded which cannot be validated without access to the source
code for Mathematica. A different set of assumptions leads to
different conclusions about ease of implementation. Arguing
something is easy/hard with out access to the source code is
pointless. There is no way to determine which set of assumptions
is a better match to reality.
My only reason for making any comment in response to a claim
something is/should be easy to change in Mathematica is
invariably those claims are invoked as part of the reasons
someone at WRI should implement something. They are (in effect)
a put down to the developers at WRI who are the ones with access
to the source code and are the only ones that can truly
determine how easy/hard making some change to Mathematica will be.
>>3+4I for the same reason 2.345/.2->1 yields 2.345.
>2.345/.2->1 does not yield 2.345.
>
>It yields 11.725 -> 1
>And for an entirely different reason, which is that Mathematica
>parser requires a space after "/." when the next token is a number.
Yes, I should have written one of the following:
2.345/. 2->1
2.345/.(2->1)
2.345/.{2->1}
which all yield 2.345 since it is not possible to change part of
a real value using replacement rules. And for the same reason
3+4I/. I->-I has no effect.
>>That is, despite the way it appears on screen, to Mathematica 3+4I is
>>a single entity with no parts. You can replace the entire entity but
>>not part of it.
>Well, is that a good thing or a bad thing? Does it HAVE to be that
>way?
No it doesn't have to be that way. Mathematica could have been
designed differently. But, it doesn't matter one bit whether I
see the current design as good or bad. Perhaps, at some point
WRI will change this aspect of the design. Until then, it is
what it is. And this behavior certainly isn't a bug or design error.
>>If the brewer's new beer formulation wasn't to my liking, I
>>wouldn't buy it again from him. Instead I would get beer from
>>another brewer.
>It is a harder to change from one software system to another, than
>to choose a different beer, at least in most countries.
So? Harder to do doesn't mean it can't be done.
>Imagine if there were only one brand of beer.
Imagining things that don't match reality doesn't seem useful to me.
>>If WRI becomes totally unresponsive to users, then there is
>>opportunity for competitors to WRI. Eventually, being totally
>>unresponsive to your user base will mean you have no users.
>Really? Consider industrial monopolies. Consider totalitarian
>regimes. Consider software operating system "lock-ins".
And since when did WRI become a monopoly? Or comparable to a
totalitarian regime? And as far as operating system "lock-ins" I
use a Mac which arguably is one of the more "locked-in"
operating systems. Yet, I I choose, I could run Windows, Linux
or one of a variety of other flavors of Unix on my Mac. So, the
"lock-in" is really my choice.
>>My experience is software developers react much better to reasoned
>>requests for changes then they do claims behavior that is precisely
>>as they intended is a bug and must be changed.
>Oh, so now you want me to be polite. That costs extra.
I've not asked you to do anything. I merely point out being
polite is more effective at getting the desired response in my
experience. You are free to behave as you choose.
It appears this discussion is unlikely to produce anything
useful at this point. So, I likely won't respond further in this
thread. In fact, I probably should have stopped responding
several posts ago.
Richard Fateman
> On 12 Dec 2010, at 23:48, Richard Fateman wrote:
>
>>>>
>>> Do you mean a user should not be allowed to enter Less[2,x,3] but
> always required to use the form Inequality[2,Less,x,Less,3]?
>> I did not propose to tie the user's hands in this way.
>>> Or should Less[2,x,3] always evaluate to
> Inequality[2,Less,x,Less,3]?
>> That would be my solution,. Is my solution. Indeed, Less[x,y] is
> simplified to Inequality[x,Less,y]
>>> (In that case you would still have the same problem if, for some
> reason, you prevented evaluation).
>> If I prevented simplification/evaluation, I would presumably not
> expect much of anything to work.
>> I can' t think of a reason.
>
> First in Mathematica, there are often functions that have attributes
> HoldAll or Hold First etc, which means that the act on unevaluated
> arguments. So if an argument was written as Less[x,y] it would not be
> it (most Mathematica "functions" are just local pattern matching rules).
Um, I think this is irrelevant. Consider the "function" in Mathematica
Divide. It exists in Mathematica.
Divide[a,b] is immediately transformed to Times[a,Power[b,-1].
Divide[a,b] /. Times-> Foo results in Foo[a,Power[b,-1]].
Divide has attributes Protected, Listable, NumericFunction.
It's not that different from Less, in some senses:
(a). Divide can always be rewritten as Times[Power ..] or as Rational.
(a') Less can always be rewritten as Inequality[ ..], at least if
Mathematica didn't insist on rewriting in the opposite direction,
namely making Inequality[a,Less,b] into Less[a,b].
(b). Divide does not have attributes Hold, HoldFirst, etc etc
(b') Neither does Less.
So now we have set the stage for DanL and friends.
1. Remove Less. and always replace it with Inequality ...
2. Same for Greater, etc etc.
3. (suggestion) Rename Inequality with Comparison.
4. modify the rest of the programs, like Compile, Display, as necessary.
5. Change the documentation.
There may still be work to do for dealing with the elements in
Mathematica that do not obey the "law of trichotomy", which states
that a<b, a==b, or a>b. But this is not true for objects that are
not comparable. Like Complex numbers, various undefined objects,
Indeterminate, NaN.
> But much more importantly and, in my opinion, crucially (that was the
> main point of my reply, but somehow you managed to skirt around so I
> will now try to make it as explicit as I can):
>
> if Less[x,y] was always automatically converted to Inequality[x,Less,y]
> than clearly LogicalExpand[Inequality[x, Less, y]] would not longer
> work,
Huh? It would work the same way as Less[x,y] today, if Mathematica did
not pre-emptively convert Inequality[x,Less,y] into Less[x,y]. That is
LogicalExpand should just leave that alone, and I am sure it could be
convinced to do that.
Note that LogicalExpand does not distinguish between Less[x,y,z] and
Inequality[x,Less,y,Less, z].
and what's worse LogicalExpand[Inequality[x, Less, y, LessEqual,
> z]] etc. would not work.
Really? I don't know what you mean "wouldn't work". It works today
to produce
And[Less[x,y], LessEqual[y,z]
in my proposal it would presumably work to produce
And[ Compare[x,Less,y], Compare [y, LessEqual, z]]
> But that would make it vastly harder to get expressions involving
> inequalities into a canonical form.
I have no idea why you think this is the case. We have already seen
the reverse. Which is that Mathematica thinks that Less[x,y,z]
and Inequality[x,Less,y,Less,z] are both canonical forms.
Indeed
FullSimplify [Less[x,y,z]-Inequality[x,Less,y,Less,z] ]
does not reduce to zero, as it should. So Mathematica, dare
I say, exhibits a bug.
Oh, LogicalExpand[Inequality[x,Less,y,Less,z]] is x<y&&y<z
as is LogicalExpand[x<y<z].
>
> As it is now, an expression involve both Inequality[x, Less, y,
> LessEqual, z] and And[Less[x,y],LessEqual[y,z]] (which is simply
> x<y&&y<=z). Both of these are equivalent and obviously you would want
> any patterns to apply to both.
Lovely. You are now proposing some kind of semantic pattern match.
As things work now, all you need to do is
> to use LogicalExpand to replace all expressions with Inequality by
> canonical forms and you can do unambiguous pattern matching.
Actually, you appear to be wrong, since
LogicalExpand[x<y<z] and LogicalExpand[z>y>x] are different.
But I like your idea of improving on "syntactic pattern matching".
Note that whatever value your thought has is true if you replace all the
expressions involving Less, Equal, .... , with Comparison. E.g.
Less[x,y] becomes Comparison[x,Less,y] etc. You do have
to be careful with negation, e.g. is x<y the same as Not [x>=y]?
{not if x is ultimately Indeterminate.}
If your
> approach were adopted this would not be possible.
Actually, you have it quite wrong, and I don't see your point.
> Instead you would have
> to pick out all the different x<y and y<=z in your expression, and
> "simplify" them to a canonical form involving Inequality.
I am not proposing to simplify them any more than is requested.
Less[a_,b_] would look like Comparison[a_,Less,b_]. What could
be simpler to do? Note that we do not change
Less[x,y] in Mathematica today to Not[Greater[y,x]]
> But this
> clearly would a great deal more complex than just applying
> LogicalExpand.
I think I get it. You believe that Comparison[...] would be
a replacement for Disjunctive Normal Form, which is produced by
LogicalExpand. Of course it isn't. LogicalExpand should only produce
pairs, so in this new scheme, you would only use
Comparison[a_,Predicate_,b_] instead of Predicate_[a_,b_]
For a start, the expression could involve many
> conjunctions and disjunctions so that x<y and y<=z would not
> necessarily appear next to each other, i.e. it could be something like
> x<y&&...various relations ...y<=z&&... .
Uh, not at all.
I think my point should now
> be clear -
Yes, you misunderstand the proposal and its implications.
what you are proposing would probably greatly increase the
> complexity of working with inequalities and may well be impracticable.
You appear to be proposing some
kind of alternative to disjunctive normal form (or conjunctive normal
form), both of which are quite well studied. Re-grouping of logical
terms for logic synthesis is also quite well studied, (see circuit
minimization). The general circuit minimization problem is believed to
be intractable. Apparently there are advantages to a computer science
education :)
> Thus implementing your idea would probably amount to introducing a
> terrible bug into Mathematica, in your own terminology.
Nope. You miss my point. I hope I have clarified it for you and anyone
else reading this.
RJF
>
Charles Gillingham
forms that were both completely documented and completely reliable.
Programs written in Mathematica need to be able to pattern match
against expressions returned by these functions. Pattern matching code
is only reliable if it is matching against a reliable canonical form.
If Mathematica made more of an effort to produce well-documented
canonical forms, it would help us.
Andrzej Kozlowski
much. Your long post consist of a mixture of the obvious, which you seem
to believe is a revelation and other things that reveal your own
ignorance of Mathematica and even certain areas of algorithmic algebra.
I will point out just one:
>
> You are asserting that "Refine" can be used. Thus Refine, in the
computer algebra terminology, is
> a Zero Equivalence algorithm. (or a Logical Tautology algorithm, in
some sense).
>
Not at all. Refine does not deal with logical tautologies or booleans.
In fact Mathematica has EquivalentQ and Tautology for this purpose:
Equivalent[a && (b || c), a && b || a && c] // TautologyQ
True
What Refine does (Like Simplify and FullSimplify) is to perform
simplifications of what are called first order formulas in the language
of real fields with parameters in the real numbers. For example
x^2>y>z+1 is such a formula and so is
z<y-1<x^2-1. But (x^2>y>z+1) - (z<y-1<x^2-1) is not a forumla but a
meaningless construct, a kind of accidental consequence of the way
Mathematica language is constructed. It does not make sense to write
Simplify[x^2>y>z+1 - z<y-1<x^2-1]; even when this sort of thing seems to
work sometimes, it is by accident (it will work when the two expressions
that you are subtracting evaluate to the same thing but not otherwise
since Mathematica will not assign any meaning to the difference. On the
other hand
Refine[x^2 > y > z, z - 1 < y - 1 < x^2 - 1] &&
Refine[z - 1 < y - 1 < x^2 - 1, x^2 > y > z]
True
but it is certainly not a "logical tautology" algorithm. It belongs to
the same "field" as the Tarski-Seidneberg Theorem, Quantifier
Elimination, Cylindirical ALgebraic Decomposition etc. I am not sure if
this is "computer science" but there are advantages to an education that
includes such things which apparently you have not benefitted from.
Richard Fateman
> Well, you have worn me out, so basically I quit. Not that I agree with
> much. Your long post consist of a mixture of the obvious, which you seem
> to believe is a revelation and other things that reveal your own
> ignorance of Mathematica and even certain areas of algorithmic algebra.
> I will point out just one:
>>
>> You are asserting that "Refine" can be used. Thus Refine, in the
> computer algebra terminology, is
>> a Zero Equivalence algorithm. (or a Logical Tautology algorithm, in
> some sense).
>>
>
> Not at all.
No, just in some sense.
Refine does not deal with logical tautologies or booleans.
A zero-equivalence algorithm traditionally
tests to see if f1(x,y,..) - f2(x,y,...) is zero for all possible
values of x,y, ....
TautologyQ should be able to test to see if f1(x,y,...) == f2(x,y, ...)
is True for all possible values of x,y, ... in the set {True,False}.
Mathematica is somehow being more sensitive to types here in not
permitting a==b, but requiring the syntax Equivalent[a,b].
So TautologyQ[Equivalent[a,b]] is a zero equivalence algorithm, in some
sense, but for logical expressions. Which is what I said.
[It is trivial in some sense, since one can compute a table of 2^n
entries, where there are n variables. But clearly this method takes
time exponential in n.]
If you were familiar with the terminology of simplification, canonical
forms, zero-equivalence algorithms, the analogy might make sense to
you too.
In answer to another item: Quantifier elimination and cylindrical
algebraic decomposition are not usually part of the undergraduate
curriculum in computer science or mathematics. Depending on
specialization, they may or may not be part of graduate programs either.
A computer scientist studying computer algebra systems would probably
encounter these topics, but even so, might avoid them.
As for whether something is meaningless to Mathematica or not, or
whether Mathematica computes something "by accident", that is a
philosophical issue. My view is that nothing that is computed
deterministically is "by accident". And everything is
meaningless to Mathematica. It is just a program
that is pushing bits around.
Glad to hear I've worn you down. I was about to quit :)
RJF
> In fact Mathematica has EquivalentQ and Tautology for this purpose:
>
> Equivalent[a&& (b || c), a&& b || a&& c] // TautologyQ