Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114690] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Mon, 13 Dec 2010 03:51:54 -0500 (EST)
- References: <ie2903$mn2$1@smc.vnet.net>
On 12/12/2010 2:43 AM, Daniel Lichtblau wrote:
>>> 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.
>>
>> (RJF) 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)"
>>
>> (RJF) Could you argue against that?
>
> 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
>