I forgot to mention something that I was thinking about yesterday. The entries on the main diagonal don't have to be either zero or a zero Matrix. They could themselves be antisymmetric Matrices which do not happen to be all zero. Some sort of recursive type-check might work, to establish or allow the main diagonal entries to be antisymmetric Matrices (whose main diagonal entries in turn might be scalar zeros or antisymmetric Matrices... and so on). acer

Thanks for the encouragement, John. How's this?

`index/AntiSym` := proc(inds::[posint, posint], comps::Matrix, entry::list)
local row, col, sign;
    row, col, sign := inds[], 1;
    if nargs = 2 then
        return sign*comps[row, col];
    else
        if row = col then
            if type(procname, 'indexed') and type(op(1, procname), posint) then
               comps[row, col] := Matrix(op(1, procname));
            else
               comps[row, col] := 0;
            end if;
        else
           comps[row, col] := sign*op(entry);
        end if;
    end if;
end proc:

metric := Matrix(4,4,Vector([-1,1,1,1]),shape=diagonal):

generators := Matrix(4,4,
 (a,b) -> `if`(a=b,Matrix(4,4),
               metric . Matrix(4,4,
     (c,d) -> metric[a,c]*metric[b,d] -
              metric[b,c]*metric[a,d])),
 shape=AntiSym[4]);

I don't quite understand why Matrix(generators) doesn't automatically flatten it out. But here it is, flattened and with no indexing function.

Matrix(16,16,[seq([seq(generators[i,j],j=1..4)],i=1..4)]);

acer

I did something similar, wrapping an unapplied `ratio_f0` inside a proc. I then plotted x->evalf[10](ratio_f0(x)) . The purpose of this was to render irrelevant any evalhf use by the plotting routing. The resulting plot, which took a long time to produce, had a jaggedness, more pronounced at smaller f0 value, indicative of the expected roundoff error. acer

I did something similar, wrapping an unapplied `ratio_f0` inside a proc. I then plotted x->evalf[10](ratio_f0(x)) . The purpose of this was to render irrelevant any evalhf use by the plotting routing. The resulting plot, which took a long time to produce, had a jaggedness, more pronounced at smaller f0 value, indicative of the expected roundoff error. acer

No, it looks like the diagonal entries cannot be replaced by anything but zero while still maintaining the option shape=antisymmetric. > generators[1,1]:=Matrix(4,4); Error, attempt to assign non-zero to antisymmetric diagonal This seems wrong to me. Why couldn't the restriction on the diagonal elements instead be that a[i,j]=-a[i,j] ? That way, having rtables on the diagonal might be possible. Well probably still not, since evalb(a=-a) doesn't return true for zero-matrix `a`. But it would have been nice if you could have done, directly, generators := Matrix(4,4, (a,b) -> `if`(a=b,Matrix(4,4), metric . Matrix(4,4, (c,d) -> metric[a,c]*metric[b,d] - metric[b,c]*metric[a,d])), shape=antisymmetric); I don't see a `index/antisymmetric` or `index/skewsymmetric` routine, so the antisymmetric indexing function looks built-in. You could try creating your own Antisymmetric indexing function with something more sophisticated for handling the diagonal's qualities. acer

I second the idea of a longer (or expandable) list of "Recent comments". An exapandable "Active forum topics" would also be nice. And I don't mean like its current "more", which immediately leads to too many choices to scan. I mean just like the sidebar, but longer. A problem with the MaplePrimes Forums's pages is that it's only possible to see the whole thread, and it's not possible to get to just the last entry posted in each. So once an entry gets pushed off the main page and sidebars, it's difficult to access easily. Also, could someone please improve the tracking pages of each individual. Instead of just showing a single entry to each forum topic, perhaps it could list each entry separately. That way, one could get to the users posts directly. acer

Trying to be tricky. unprotect(LinearAlgebra:-Multiply); Z:=copy(LinearAlgebra:-Multiply): LinearAlgebra:-Multiply:=proc() if args[1]=`#mo("∇")` or args[1]=`#mo("∇")` then args[1](args[2]); else Z(args); end if; end proc: `#mo("∇")`:=proc(V::Vector) map(sin,V); end proc: `#mo("∇")`:=`#mo("∇")`: Now insert the Del symbol from the palette, and toggle it as Atomic Identifier, and it can be used without the brackets. That is to say, I was able to do 2D things like, V V V I didn't check to see whether I'd broken LinearAlgebra:-Multiply. I could still do, V V There may be some simple way to customize it, which someone else can suggest. It might also be possible to use instead a module for the redefined multiplication, but I didn't try. acer

Trying to be tricky. unprotect(LinearAlgebra:-Multiply); Z:=copy(LinearAlgebra:-Multiply): LinearAlgebra:-Multiply:=proc() if args[1]=`#mo("∇")` or args[1]=`#mo("∇")` then args[1](args[2]); else Z(args); end if; end proc: `#mo("∇")`:=proc(V::Vector) map(sin,V); end proc: `#mo("∇")`:=`#mo("∇")`: Now insert the Del symbol from the palette, and toggle it as Atomic Identifier, and it can be used without the brackets. That is to say, I was able to do 2D things like, V V V I didn't check to see whether I'd broken LinearAlgebra:-Multiply. I could still do, V V There may be some simple way to customize it, which someone else can suggest. It might also be possible to use instead a module for the redefined multiplication, but I didn't try. acer

A quick peek at the code Library code of the depends() routine shows a bit of the logic. That is, by issuing, showstat(depends); It looks as if `depends` returns false if `has` returns false (modulo some indexed name funny business). The converse is the interesting question, I suppose. The routine `depends/internal` does further analysis, and you can see how it handles some special structures with another showstat() call on it. Having peeked, a little imagination can conjure up some cases that are missing. For example,

> a := SDMPolynom(t^3+5*t^2+11*t+15,t);
                                   3      2
                  a := SDMPolynom(t  + 5 t  + 11 t + 15, [t])
 
> has(a,t);
                                     true
 
> depends(a,t); # whoops
Error, (in depends/internal) invalid input: depends/internal uses a 2nd
argument, x, which is missing

I don't know whether you consider the `x` in a data structure like SDMPolynom -- which represents a polynomial -- to be a dummy variable or not. acer

A quick peek at the code Library code of the depends() routine shows a bit of the logic. That is, by issuing, showstat(depends); It looks as if `depends` returns false if `has` returns false (modulo some indexed name funny business). The converse is the interesting question, I suppose. The routine `depends/internal` does further analysis, and you can see how it handles some special structures with another showstat() call on it. Having peeked, a little imagination can conjure up some cases that are missing. For example,

> a := SDMPolynom(t^3+5*t^2+11*t+15,t);
                                   3      2
                  a := SDMPolynom(t  + 5 t  + 11 t + 15, [t])
 
> has(a,t);
                                     true
 
> depends(a,t); # whoops
Error, (in depends/internal) invalid input: depends/internal uses a 2nd
argument, x, which is missing

I don't know whether you consider the `x` in a data structure like SDMPolynom -- which represents a polynomial -- to be a dummy variable or not. acer

He was asking whether depends() and has() are equivalent, aside from cases using "dummy" variables like for Int and Sum, etc. acer

He was asking whether depends() and has() are equivalent, aside from cases using "dummy" variables like for Int and Sum, etc. acer

Well, yes. Exactly. For 2D input, the space between the function name and the brackets is parsed as a multiplication, while in 1D input it's parsed as a function call. Having different parsers behave in different ways on things like this is not good. acer

Well, yes. Exactly. For 2D input, the space between the function name and the brackets is parsed as a multiplication, while in 1D input it's parsed as a function call. Having different parsers behave in different ways on things like this is not good. acer

Another trap: If a space is inserted between the `int` and the open-bracket then the parsed meaning is different in 1D and 2D input. acer