@Alec Mihailovs Using the "normal equations" can be an unstable method for computing floating-point least squares solutions. It doesn't really matter that some random example, such as you showed, does ok. It's more a matter of how bad it can get, and how often. The normal equations A.A^%T approach is often faster, but less numerically stable than say, orthogonal decomposition such as QR. The SVD approach can be slower still, but also more stable.

That's pretty common knowledge, eg. see here.

People can eventually get disappointed by fast, numerically unstable methods (as a general rule, or so I've found).

In that last call, to LeastSquares, I believe that if you trace it through you'll find that LeastSquares is not using the thin SVD in Maple 14. But it ought to.

@otherworld314 So, is it then as simple as this?

> f:=sqrt(1+cos(x)*cos(y)*cos(x+y));
                                            (1/2)
              (1 + cos(x) cos(y) cos(x + y))     

> st:=time():
> evalf(Int(Int( f , y=0 .. x+1), x=0 ..1));
> time()-st;
                          1.674302577
                             0.062

Is there still a need for function approximation?

@otherworld314 So, is it then as simple as this?

> f:=sqrt(1+cos(x)*cos(y)*cos(x+y));
                                            (1/2)
              (1 + cos(x) cos(y) cos(x + y))     

> st:=time():
> evalf(Int(Int( f , y=0 .. x+1), x=0 ..1));
> time()-st;
                          1.674302577
                             0.062

Is there still a need for function approximation?

Thanks for replying, Andrew. The basic idea is that someone other than Maplesoft might develop some other useful tool with it, if there were an open API.

One thing that came to mind was the possibility of cooperative authorship of documents. I don't really mean real-time display of each participant's sheet. I mean more in terms of an applet that could show whether participant A's sheet was out-of-sync with B's last upload, and what the diffs were.

The details are not so important, but I could imagine a scheme in which participants each uploaded their copy of the sheet with a slight modification to the parent doc's name, according to a specified convention. Then the applet might periodically compare them and report or allow relevant reaction. The Worksheet, XMLTools, and Sockets packages might be used in the implementation, along with Maplets or Components and perhaps INTERFACE_WORKSHEET().

Of course there could be other interesting ideas from other people.

Does releasing information about how Maple talks to the MapleCloud server necessitate waiting until the next major release of Maple? Or are you suggesting that the mechanism would have to first be changed (for security of other patching), before it could be open knowledge?

Thanks for replying, Andrew. The basic idea is that someone other than Maplesoft might develop some other useful tool with it, if there were an open API.

One thing that came to mind was the possibility of cooperative authorship of documents. I don't really mean real-time display of each participant's sheet. I mean more in terms of an applet that could show whether participant A's sheet was out-of-sync with B's last upload, and what the diffs were.

The details are not so important, but I could imagine a scheme in which participants each uploaded their copy of the sheet with a slight modification to the parent doc's name, according to a specified convention. Then the applet might periodically compare them and report or allow relevant reaction. The Worksheet, XMLTools, and Sockets packages might be used in the implementation, along with Maplets or Components and perhaps INTERFACE_WORKSHEET().

Of course there could be other interesting ideas from other people.

Does releasing information about how Maple talks to the MapleCloud server necessitate waiting until the next major release of Maple? Or are you suggesting that the mechanism would have to first be changed (for security of other patching), before it could be open knowledge?

You wrote, "Pagan, with you I get the original matrix A."

But as you can see in my first reply, I did PDP^-1 and, yes, I deliberately showed that PDP^-1 is the same as A. But of course the answer is not A. The answer is P.

Just enter P; in Maple, to see the contents of P. I didn't do that above, but it's only a few keystrokes.

Look, in what I did in Maple, `e` is a Vector of eigenvalues (not sorted). `P` is the diagonalizing Matrix. DiagonalMatrix(e) makes a diagonal Matrix out of the Vector `e`. And P.DiagonalMatrix(e).P^(-1) is supposed to equal A.

Similarly, once you find P, you can do P^(-1).A.P and you should get a diagonal matrix containing the eigenvalues. Do you see how P allows you to transform A to DiagonalMatrix(e), or back again?

You wrote, "Pagan, with you I get the original matrix A."

But as you can see in my first reply, I did PDP^-1 and, yes, I deliberately showed that PDP^-1 is the same as A. But of course the answer is not A. The answer is P.

Just enter P; in Maple, to see the contents of P. I didn't do that above, but it's only a few keystrokes.

Look, in what I did in Maple, `e` is a Vector of eigenvalues (not sorted). `P` is the diagonalizing Matrix. DiagonalMatrix(e) makes a diagonal Matrix out of the Vector `e`. And P.DiagonalMatrix(e).P^(-1) is supposed to equal A.

Similarly, once you find P, you can do P^(-1).A.P and you should get a diagonal matrix containing the eigenvalues. Do you see how P allows you to transform A to DiagonalMatrix(e), or back again?

While not getting all the way there, I thought that there might be a chink of light in this response. You could get from the piecewise to Dirac, using convert/Heaviside. But I don't see any way to get `int` first to use the (possibly user-redefined) value of Heaviside(0), instead of 'undefined'.

So maybe that pretty much leaves Jakubi's applyrule suggestion below as best practical approach, given that we don't know more about the OP's multi-integrals?

While not getting all the way there, I thought that there might be a chink of light in this response. You could get from the piecewise to Dirac, using convert/Heaviside. But I don't see any way to get `int` first to use the (possibly user-redefined) value of Heaviside(0), instead of 'undefined'.

So maybe that pretty much leaves Jakubi's applyrule suggestion below as best practical approach, given that we don't know more about the OP's multi-integrals?

@Nick You have a multiplication in your call to run UpdateAllVelocities.

In Mapleprimes, your pasted code shows it as a star symbol, between the proc's name and the round-brackets.

It shows in your post as

     UpdateAllAccelerations*(i, accel, gravity);

Notice the `*` in there, making it a multiplication not an actual function call.

I am going to guess that in your worksheet you had a space, not an explicit star. That is called "implicit multiplication" and is a "feature" of 2DMath input mode. See also here.

I suggest that you make 1D Maple notation your default input mode, and Worksheets the default for new sheets, not Documents. You can configure both using the Tools->Options menus.

@Nick You have a multiplication in your call to run UpdateAllVelocities.

In Mapleprimes, your pasted code shows it as a star symbol, between the proc's name and the round-brackets.

It shows in your post as

     UpdateAllAccelerations*(i, accel, gravity);

Notice the `*` in there, making it a multiplication not an actual function call.

I am going to guess that in your worksheet you had a space, not an explicit star. That is called "implicit multiplication" and is a "feature" of 2DMath input mode. See also here.

I suggest that you make 1D Maple notation your default input mode, and Worksheets the default for new sheets, not Documents. You can configure both using the Tools->Options menus.

@Nick Maple uses the last line of code for the return value, if that is how the proc is exited (ie, not via some explicit return statement at some other branch in earlier code in the proc body). In Maple, NULL is... well, null. So returning NULL can be nicer than having it return whatever just happened to be the last operation's result. You routine acts inplace on vel, updating the actual Matrix that was passed in. So you don't need to have your proc return a Matrix (or anything else) for the purpsoe of assignment at the higher level. Ie, you don't need to assign the entire Matrix result of calling UpdateAllVelocities to some variable at the higher level, upon return, because the higher level Matrix was updated inplace.

I say that UpdateAllVelocities acts "inplace" because it updates its Matrix argument. The alternative, "copy semantics" might be for the proc to declare a local M, assign M as a Matrix container inside the proc body, write the results into M while in the proc body, then have the proc actually return M. Then you could call Result:=UpdateAllVelocities(...). Repeatedly doing this will cause a lot of temporary objects to be produce, which must then be memory managed. Your inplace scheme is much more efficient. Your scheme also works nicely with the Compiler:-Compile.

I thank the gods that the Compiler does not (really) support creation of new Matrices inside compiled procs. It leads to having to write in this efficient inplace way!

@Nick Maple uses the last line of code for the return value, if that is how the proc is exited (ie, not via some explicit return statement at some other branch in earlier code in the proc body). In Maple, NULL is... well, null. So returning NULL can be nicer than having it return whatever just happened to be the last operation's result. You routine acts inplace on vel, updating the actual Matrix that was passed in. So you don't need to have your proc return a Matrix (or anything else) for the purpsoe of assignment at the higher level. Ie, you don't need to assign the entire Matrix result of calling UpdateAllVelocities to some variable at the higher level, upon return, because the higher level Matrix was updated inplace.

I say that UpdateAllVelocities acts "inplace" because it updates its Matrix argument. The alternative, "copy semantics" might be for the proc to declare a local M, assign M as a Matrix container inside the proc body, write the results into M while in the proc body, then have the proc actually return M. Then you could call Result:=UpdateAllVelocities(...). Repeatedly doing this will cause a lot of temporary objects to be produce, which must then be memory managed. Your inplace scheme is much more efficient. Your scheme also works nicely with the Compiler:-Compile.

I thank the gods that the Compiler does not (really) support creation of new Matrices inside compiled procs. It leads to having to write in this efficient inplace way!

Where's the image from Erik's first attempt? I don't see it.

It would be great if we could insert 2DMath that looked great, had equivalent 1D notation alt tags, and could be obtained by pasting from maple directly without using the button. The third of those aspects is least important, but having the first two aspects, combined, is desirable.

Where's the image from Erik's first attempt? I don't see it.

It would be great if we could insert 2DMath that looked great, had equivalent 1D notation alt tags, and could be obtained by pasting from maple directly without using the button. The third of those aspects is least important, but having the first two aspects, combined, is desirable.