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: [mg114657] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • From: Bill Rowe <readnews at>
  • Date: Sun, 12 Dec 2010 05:41:11 -0500 (EST)

On 12/11/10 at 1:52 AM, fateman at (Richard Fateman)

>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

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

>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

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

  • Prev by Date: 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