There are terrible bugs in `define/multilinear`, `define/flat`, and `define/skeleton`
which prevent any serious use of the first two options. `define/skeleton` is an internal
procedure that `define/...` uses and it needs fixing too. Here are examples of these
bugs with our comments. At the end there is a fix that seems to work but it has not been
yet fully tested. Under a separate submission we will show another problem with
`define/multilinear` that makes adjusting it to the user’s needs extraordinarily and
unreasonably difficult.
Will be fixed with the next Maple version (see below).
Wrong output again: it should be`e1 &r e2`
Will be fixed with the next Maple version (see below).
Very bad: it should be just`-&r(e1)` but, instead, an extra tensor argument is
added.
Fixed in Maple 6 (see below).
> unassign('`&r`'); > define(`&r`,flat,multilinear); > > &r(-&r(e1),-&r(e2)); Error, (in &r) too many levels of recursion Error in code of option flat
Will be fixed with the next Maple version (see below).
Again error: it should be`-(e1 &r e2)` but instead an extra tensor argument is
added.
Fixed in Maple 6 (see below).
Again error: it should be`-&r(e1)` but instead TWO extra tensor arguments are
added.
Fixed in Maple 6 (see below).
Error should be-&r(e1) error in define/skeleton.
Fixed in Maple 6 (see below).
This error is caused by the miracoulous action of the for `Define_i in Definelook do‘
statement of the flat code: see below
> Define_look:=-&s(e3); # load one argument to Define_look > print("nops are : ", nops([Define_look])); # check what's loaded > for Define_i in Define_look do > print(Define_i); > od; Define_look := -&s(e3) "nops are : ", 1 -1 &s(e3)
&s(e3) and yields thus a wrong
result.
This problem can be fixed as follows
We have wasted a considerable amount of time when trying to use ‘define/multilinear‘ in our own programing before we realized that these bugs existed. See also our second "bug" submission on ‘define/multilinear‘. It is very unfortunate that not for the first time we have found that one cannot trust Maple code and that often it is better to write one’s own code to replace Maple’s built-in functions. This should not be the case though.On Fri, 9 Jun 2000, Rafal Ablamowicz wrote:
| > define(`&r`,flat,multilinear);
I got this error in Release 5.1, but Maple 6 returned (-&r(e1)) &r (-&r(e2))
| > &r(&r(e1,-e2));#again error: ...
Release 5.1 did this, but Maple 6 had -(e1 &r e2).
| > &r(&r(-e1));#again error: ...
Again, fixed in Maple 6.
Thank you for the bug report concerning the Maple procedure ‘define()’.
Most of the reported bugs you pointed out were already fixed in Maple 6, along with other known bugs at that time. One weakness you reported, concerning the failure to recognise some constants that could be removed from the arguments in a call to a multilinear function has also, since been fixed in the version of Maple currently under development. We now have:
> define( `&r`, 'multilinear' ); > &r( -e1, -e2, e3 ); &r(e1, e2, e3) > &r( -e1, -e2 ); # e.g., this is left unchanged in Maple 6 e1 &r e2 > &r( -e1 ); -&r(e1) > unassign( '`&r`' ); > define( `&r`, 'flat', 'multilinear' ); > &r( -&r( e1 ), -&r( e2 ) ); e1 &r e2 > &r( &r( -e1 ) ); -&r(e1) > &r( -e1 ); -&r(e1)