Re: assumptions and simplifications [Re: Maple bugs are ubiquitous: A bug the long-liver in assuming (2001--2007--?)]


"Daniel Lichtblau" <danl@xxxxxxxxxxx> wrote in message
news:1182452357.732192.189520@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 21, 1:23 pm, Vladimir Bondarenko <v...@xxxxxxxxxxxxxxx> wrote:
.................................................................

If the same bugs exist through numerous software releases,
I think that is valuable public information.

It just should not happen.

-- Brad Cooper

As quotes go, this is at best out of context. For a start, it is not
clear whether the author has any perspective on the type of software
in question. I would strongly suspect not.

The attitude towards regression testing, exemplified by my statement above,
was the attitude I saw taken by the developers of the FORTRAN compiler for
the computers at Digital Equipment Corporation. They regression tested for
every bug fixed since the first version. I mentioned this in a posting in
2005 and Vladimir Bondarenko has recently quoted from it.

My expertise was in operating system code. This is much harder to regression
test, but very defensive code can be used to "try" to ensure that a bug,
once fixed, will not recur - a regression test of sorts.

I would characterise a CAS as more like the FORTRAN compiler. It would
appear to be more deterministic than an OS in that, if it failed to
correctly evaluate int(cos(x^2),x) and the bug is fixed so it produces the
correct result, it is a simple matter to ensure that bug remains fixed with
regression testing. It may be that a future version of the CAS produces a
correct output, but in a different form. The testers will be alerted to a
potential error, find that it is simply a case of a different form of the
output and modify that regression test to suit. This will also be in place
for testing of future releases.

If Digital could regression test for their compilers and the GEMM project
can do it for a range of CASs, so can the CAS developers.

Cheers,
Brad


.................................................................

Hello again from the VM machine...

.................................................................
BUG # XXXXX assuming: assuming <> assume

REGRESSION: NO

REPRODUCIBLE: ALWAYS
[...]
DESCRIPTION: According to Help, ?assuming

"The expression assuming property calling sequence
evaluates the expression under the assumption
property on all names in expression."

TEST CASE: restart; ln(2*a)-ln(a) assuming a > 0;

ACTUAL: ln(2*a)-ln(a)

EXPECTED: ln(2)

CHECKUP: assume(a > 0): simplify(ln(2*a)-ln(a));

ln(2)

What is the claimed bug? That the test case result did not do a
simplification? That's not a bug unless there is a claim to the effect
that one should have been done, and I see no such wording in the usage
message.

For comparison here is similar Mathematica in/out.

In[40]:= Assuming[a>0, Log[2*a]-Log[a]]

Out[40]= -Log[a] + Log[2 a]

In[42]:= Assuming[a>0, Simplify[Log[2*a]-Log[a]]]

Out[42]= Log[2]

.................................................................

Enjoy:

Maple 11> simplify(
ln(2222222222222222222222222222222222222222222222222222222)
- ln(1111111111111111111111111111111111111111111111111111111)
);

ln(2222222222222222222222222222222222222222222222222222222)-
ln(1111111111111111111111111111111111111111111111111111111)

instead of ln(2).
[...]

Best wishes,

Vladimir Bondarenko
[...]

I'm not sure if that last is claimed as a bug or just an example where
a simplification might be done but is not. Since that would involve
gcds but not factoring, it looks like a fairly unimportant missed
opportunity.


Daniel Lichtblau
Wolfram Research



.

Relevant Pages