MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Replacement Rule with Sqrt in denominator. Also Bug in Series

  • To: mathgroup at
  • Subject: [mg114687] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • From: Richard Fateman <fateman at>
  • Date: Mon, 13 Dec 2010 03:51:21 -0500 (EST)
  • References: <ie28s3$mk0$>

On 12/12/2010 2:41 AM, Bill Rowe wrote:
> On 12/11/10 at 1:52 AM, fateman at (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?
> (Bill) Several posters who work for WRI have stated the behavior is not
> 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 
>>> 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, 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

  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"
> 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.


  • Prev by Date: Re: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in denominator
  • Next by Date: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • Previous by thread: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • Next by thread: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series