Services & Resources / Wolfram Forums / MathGroup Archive
-----

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 smc.vnet.net
  • Subject: [mg114617] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • From: Bill Rowe <readnews at sbcglobal.net>
  • Date: Fri, 10 Dec 2010 02:31:13 -0500 (EST)

On 12/9/10 at 6:01 AM, fateman at cs.berkeley.edu (Richard Fateman)
wrote:

>On 12/8/2010 3:40 AM, Bill Rowe wrote:
>>On 12/7/10 at 6:45 AM, fateman at 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.



  • Prev by Date: Re: FileName Widget
  • Next by Date: Re: Replacement Rule with Sqrt in denominator
  • 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