You seem to be thinking imperatively -- like in the old days of C and Fortran. If you are going to re-assign all the entries, why does this matter at all? Maple has many other sources of overhead that make the above disappear in the noise. If, on the other hand, what you really want is to re-assign just a small part of your Array, then it might be worth it. I would still avoid the explicit loop unless actual profiling showed that to be a problem.

Tent[1..4] := Array(1..4,  i->unapply(christoffel[i]+v^i,v));

would re-assign only parts of the entries. The overhead of the extra Array is negligible.

Long long ago, in the early plans for LinearAlgebra, was a parallel package for abstract linear algebra (ALA). Since computational linear algebra was (by far) linalg's weak point, that was what needed to be worked on for Maple 6. Not too surprisingly, VectorCalculus took priority over ALA. And then enough time had passed that somehow that earlier plan is still gathering dust. Maple has a lot of infrastructure to be able to deal with an ``algebra of properties'' (as is the way I prefer to think of ALA). But this is completely different than LinearAlgebra. In LinearAlgebra, a Matrix always has two fixed positive integer dimensons; in proper ALA, those would be abstract (ie symbols with assumptions). That is an enormous difference. As far as the underlying implementation goes, that is like night and day. It is only in the perception of the user that these things are related.

That site is definitely much more thorough, I will switch to using it.

Wolfram Research is marketing Mathematica 6 as a powerful new tool, involving new paradigms. Clearly they are appealing to the technically literate crowd. They are not playing up any substantial usability angle. With a reasonably similar feature set (in Maple 11), Maplesoft on the other hand is playing-up the usability angle, and getting close to ignoring the technically literate academic crowd (its base constituents). From what I can see, that is 90% marketing, on both sides. Either product could have been marketed the way the other one is! Technically, both products are solid, and generally comparable. Maple is superior in some respects, Mathematica in others. Note that both products are rather quirky too -- I have not yet used the Mathematica 6 interface, but just like Maple's Java interface, the Mathematica 5.3 interface was quite temperamental. I happen to really really like Wolfram's marketing. Probably because I get the feeling that I am in their target market, while I am completely out of the marketing target-market of Maplesoft. I love to read (and cringe!) at all the overblown B.S. about their new algorithms for this-and-that. I know that it is hot air -- but they choose to talk about algorithms as a selling-point! How cool is that? But consider this: it may well be that the technically literate market that is ready to embrace symbolic computation already has. So that there just might not be any real growth opportunity there, at least not without enormous efforts aimed at breaking in to adjacent markets that have been dominated by mostly numerical offerings. But techno-phobic people still need to do math, and they sure have not embraced products like Maple (or Mathematica). Actually, they mostly seem to have gone to MathCad, if they use software at all. So there may be a genuine growth opportunity there.

They can help you with that, since it deals with the license manager.

Trying again: select(x->max(op(convert(x[1..-1,3],list))), op(1, p2));

Trying again: select(x->max(op(convert(x[1..-1,3],list))), op(1, p2));

The results you get are indeed horrendously bad. For things like this which need direct interaction with Maplesoft (because this is not something the user community can really do much about), it is best to also tell support@maplesoft.com directly. If I were to make a guess, I would say that the font metrics for that one font are off, and Maple/Windows/Java gets all confused when printing with that font. But that really needs someone with deep access to Maple to verify that.

How did you generate that pdf? The rendering is quite awful. For example: sqrt(mu4)^4 (on last page) is missing parentheses, the amount of headspace between the overbar of the 'sqrt' sign and Variance is too much, in your inline integrals the 'infinity' actually touches the integral sign while the -infinity is too far away from it, the upper 'infinity' on all integrals is way lower than other (compare with F [about right height but too far to the left] and K_0 [too high]), the display of the unevalated-eval (ie evalat) has the evaluation equation too high, the -1/x^2 just looks funny, etc. Someone should really fire up LaTeX (or Scientific Workplace or MathType or sometimes even Maple Classic) to compare the rendering. Some real steps backwards in rendering quality are nicely highlighted by your worksheet.

Quite handy. And for the original poster, a little bit of

interface(verboseproc=3); kernelopts(opaquemodules=false);
print(HTTP[Get]);
print(HTTP[SendRequest]); 

gives a nice answer to the original query of how to use Sockets to get the task done.

If you put it into the /lib directory, then that is a 'global' init file for everyone on your computer (and all maple sessions). It is more usual to put the init file in your home directory (wherever that is, depending on your platform).

If you put it into the /lib directory, then that is a 'global' init file for everyone on your computer (and all maple sessions). It is more usual to put the init file in your home directory (wherever that is, depending on your platform).

While a lot of people here have found various hacks and workarounds to get Maple 11 (mostly) working on Vista, Maplesoft still has not officially launched a product that supports it. I am sure they will announce it loudly when they do!

Since, as far as I remember, the main reasons for this behaviour have to do with linalg, it may well (now) be possible to fix this. I suspect that fixing this would not break any recent Maple functionality -- but it may well break old packages (like linalg, liesymm, networks, difforms, powseries, etc; though it is entirely possible that as of Maple 11, there are modern replacements for all this functionality, or easy fixed for the remainder).

The Maple algorithms are expected to be exponential. This is due to expression size blow-up. See the paper Hierarchical representations with signatures for large expression management and Linear Algebra using Maple's LargeExpressions Package for some theory and some ways around this.