John Fredsted

2243 Reputation

15 Badges

19 years, 180 days

MaplePrimes Activity

These are questions asked by John Fredsted

The keyboard shortcut sequence for executing an entire worksheet is Alt+e+e+w. Occasionally, I hit Alt+e+w+w by accidence. In that case, Maple sometimes, not always!?, gets completely stuck and can only be shut down through the job list window (Windows Ctrl+Alt+Del). Can anybody else replicate that? And if so, has this erratically odd behaviour been fixed in later versions of Maple?

This may be a silly question, but does there exist some simple way of (Taylor) expanding an expression of 'small' functions in terms of these functions.

A simple example: Assume that diff(f(x),x) and g(x) are two functions both with range, say, in [-a,+a], where a << 1, and consider the following expression:

sqrt(1 + diff(f(x),x)) * (2 + g(x));

Its expansion to first order in terms of diff(f(x),x) and g(x) should be 2 + diff(f(x),x) + g(x). My problem is that mtaylor does not accept functions as variables to expand on, and I would prefer not to have to substitute back and forth with some 'placeholders'.

As far as I can tell from the help pages, Maple 17, which I am using, can perform only one-dimensional Fourier transformations. Has that changed in latter versions?

I ask because I would like to find the 4D Fourier transformation of Heaviside(t^2 - x^2 - y^2 - z^2), the argument being the Minkowski line element. I have made quite some attempts with pen and paper, but the results are not stable. One calculational strategy of mine seems to depend on the order of integration: alongside some other part, a 4D Dirac delta function either appears or not. Another strategy produces an altogther differently looking expression.

It would therefore be nice to have some computational guidance.

When the Physics package is loaded, Maple returns the following error in connection with the simple statement 2*D[1]:

Error, (in TypeTools/ac_var_local) unable to determine the anticommutative character of D[1]

Why that? Although to no avail, for D[1] there is no problem. Note that the above error results even without having set up any anticommutative prefixes or the likes in Physics Setup.

PS: I am using Maple 17.

The expression (D[1]@D[2])(f) is equivalent to D[1,2](f). On grounds of that, I would naively have expected that (D[1]@D[1])(f) was equivalent to D[1,1](f). But it seems not to be, their lprint-versions being different:

expr1 := (D[1]@D[1])(f):
expr2 := D[1,1](f):
simplify(expr1 - expr2);
simplify(expr1 - expr2,`@`);

D[1, 1](f)

I am curious to know why it has been implemented this way? Have I fundamentally misunderstood something?

4 5 6 7 8 9 10 Page 6 of 12