Yes, the functional form for this simple case had been shown already by Alex above. However, even for a slight variation as x*diff(sin(x),x), I do not find the functional form of much advantage.

Yes, the functional form for this simple case had been shown already by Alex above. However, even for a slight variation as x*diff(sin(x),x), I do not find the functional form of much advantage.

This is probably the first useful example that I have seen about the usage of a preprocessor directive (?Preprocessor shows nothing).

So, are these macro definitions in a cache that "survives" to the execution of 'restart'? (I do not see any reference to this issue in ?Preprocessor either).

This is probably the first useful example that I have seen about the usage of a preprocessor directive (?Preprocessor shows nothing).

So, are these macro definitions in a cache that "survives" to the execution of 'restart'? (I do not see any reference to this issue in ?Preprocessor either).

This is a good question. There has been some threads on this subject listed here. And also:

bug-forum

An update on Maplesoft position is probably this blog.

The GRTensor package can help you to derive the field equations. Depending on these equations, Maple may be able to solve them.

I agree completely. Creating different objects, instead of displaying the same objects differently is, in my opinion, the basic flaw of the whole Typesetting scheme.

Even worst, changing e.g. its 'msemantics' attribute, and depending how, creates also different objects that display the same:

`#mi("c")`:
addressof(%);
                                  150525296
`#mi("c", Typesetting:-msemantics = "atomic")`:
addressof(%);
                                  150128208
`#mi("c", msemantics = "atomic")`:
addressof(%);
                                  150484044

I agree completely. Creating different objects, instead of displaying the same objects differently is, in my opinion, the basic flaw of the whole Typesetting scheme.

Even worst, changing e.g. its 'msemantics' attribute, and depending how, creates also different objects that display the same:

`#mi("c")`:
addressof(%);
                                  150525296
`#mi("c", Typesetting:-msemantics = "atomic")`:
addressof(%);
                                  150128208
`#mi("c", msemantics = "atomic")`:
addressof(%);
                                  150484044

Surely, it won't work in most cases as it is at most a starting point towards such an ideal command. For numbers you could do instead something like:

W:=[1, 2, 3] :
n:=x->Typesetting:-mn(convert(x,string), family = "Times", 
size = "18"):
map(n,W);

And for enlarging commas, you should probably use the 'mrow' form and adding to the sequence of entities something like:

Typesetting:-mo(",", family = "Times", size = "18")

Surely, it won't work in most cases as it is at most a starting point towards such an ideal command. For numbers you could do instead something like:

W:=[1, 2, 3] :
n:=x->Typesetting:-mn(convert(x,string), family = "Times", 
size = "18"):
map(n,W);

And for enlarging commas, you should probably use the 'mrow' form and adding to the sequence of entities something like:

Typesetting:-mo(",", family = "Times", size = "18")

You mean something like the output, in Standard GUI, of this command?:

Typesetting:-mrow(mi("[", family = "Times", size = "18"),
mi("A", family = "Times", size = "18"),mi("B", family = "Times", 
size = "18"),mi("C", family = "Times", size = "18"),mi("]", 
family = "Times", size = "18"));

Or shorter:

X:=[A, B, C]:
t:=x->Typesetting:-mi(x, family = "Times", size = "18"):
map(t,[A, B, C] );

You mean something like the output, in Standard GUI, of this command?:

Typesetting:-mrow(mi("[", family = "Times", size = "18"),
mi("A", family = "Times", size = "18"),mi("B", family = "Times", 
size = "18"),mi("C", family = "Times", size = "18"),mi("]", 
family = "Times", size = "18"));

Or shorter:

X:=[A, B, C]:
t:=x->Typesetting:-mi(x, family = "Times", size = "18"):
map(t,[A, B, C] );

If your problem is gravitation-like, and the source is bounded, then you may try a multipole expansion to check the asymptotic behavior of the potential at large distances.

If your problem is gravitation-like, and the source is bounded, then you may try a multipole expansion to check the asymptotic behavior of the potential at large distances.

It may depend on whether the source of the potential is bounded. For a matter source that extends to infinity, the gravitational potential does not vanish at infinity.