experimental meqp



> (%i3) is(equal(0,%i)) <-- reported bug
> (%o3) false

OK

> (%i4) is(equal(matrix([x]),rat(matrix([x])))) <-- reported bug
> (%o4) true

OK

> (%i5) is(equal([a],[a,b])) <--- reported bug
> (%o5) false

OK

> (%i6) assume(equal(a,aa))
> (%o6) [equal(a,aa)]
> (%i7) is(equal(f(a),f(aa)))
> (%o7) true <--- was error or unknown

I *think* this is OK ...

> (%i10) a[1]:1
> (%i11) b[1]:1
> (%i12) is(equal(a,b))
> (%o12) true

OK

> (%i13) a[2]:2
> (%i14) is(equal(a,b))
> (%o14) false

OK

> (%i15) f[i]:=i^2
> (%i16) g[k]:=k^2
> (%i17) is(equal(f,g))
> (%o17) true

OK. Is the new MEQP comparing lambda expressions?
That seems interesting. What does the new MEQP do for
other kinds of local variables, e.g. summation indices?

> What bugs in is(equal( ..)) might I have ignored? Except
> for test 48 in rtest6a, the new meqp code shows no
> errors. I think test 48 in rtest6a is semi-bogus:
>
> assume(not(equal(i,-1)));
> [not (equal(i,-1))]$
>
> Surely this should be (works with my meqp code)
>
> assume(not(equal(i,-1)));
> '[not (equal(i,-1))]$

OK.

Please send me the current version of MEQP.
Searching the bug tracker for "equal" turns up some
other bug reports. I don't know if the new code will
fix all of them but it is certainly an improvement.
I'll commit the new code and review the bug reports.

Btw what does the current version of the new code return
for is(equal(true, false)) ?

Thanks for working on this problem.
I think it is pretty important.

Robert