@Christopher2222 Indeed, save as text is not a good option but the less bad option, in my opinion. I would not expect an option for saving the page as a web archive any time soon.

Since this javascript include was deployed, I save threads as text files from the browser option. I prefer text files as they are much smaller and better for text search through my own archives. Years ago I have requested a save-as-text option for threads. I am still waiting it.

About the OP issue of running GRTensor in the Standard GUI, I have executed one of my Classic worksheets in Maple 14 Standard without any significant problem besides a printing quirk. This worksheet contains some calculations for a relatively simple metric. Problems for larger computations may occur, but they are likely not specific to the GRTensor package. In any case, using the CLI under 64 bit is always an option.

@PatrickT 

It seems like 10 years (at least). In the interview to Gaston Gonnet, dated 2005, p. 56, it is stated:

GONNET: Yes, that’s a possibility. Talking about open source, about three or four years ago, I mentioned this to Maple management. We had a sort of high-level discussion, and I was asked, “What would you do with Maple?” We were losing the battle with Mathematica. What should we do? I said, “Open source is your answer. Open source the programs, (the kernel, and the library) and sell the manuals, sell the consulting, sell the know-how for people that want to sell anything that is built on top on Maple. But get the open source energy…”

@PatrickT 

You may find also interesting Jacques' answers to my speculations about opensourcing the Classic GUI (optimist), and opensourcing the whole Maple (pesimist), as well as this comment about partial opensourcing.

@PatrickT 

Note though Jacques' answer to my comment about an alternative GUI for Maple in the style of wxMaxima. He qualified it as "quite feasible".  

@PatrickT No, Maple development is quite decentralized (and even disorganized). Roman used here the metaphor of an "organic ecosystem", and described this situation as an asset. His description may be representative of the "culture" within Maplesoft. Indeed, facts are consistent with his description.  

@Alex Smith You are forgetting Standard GUI typesetting standard/extended...

That is what I have have said in  June: a voting system would make sense only if useful for selecting the best items. As it stands, it is not. And expert refereing would help. But again, who would volunteer?

I do not like the voting system implemented in Primes2, nor consider it useful. And I have speculated about a refereeing system, soon after it started.

I do not agree, it may be the user who struggles here, not Maple...

In principle, trigsubs was intended to handle trigonometric identities. And indeed, it works for this particular expression:

trigsubs(sin(x)+sin(y));
                  [2 sin(x/2 + y/2) cos(x/2 - y/2)]

But there is not much joy, as  trigsubs is fragile and fails under a slight change:

trigsubs(-sin(x)-sin(y));
Error, (in trigsubs) expecting a sum or difference of two functions but got -sin(x)-sin(y)

I say that it is fragile because automatic function normalization "pulls out" the minus sign:

trigsubs(sin(-x)+sin(-y));
Error, (in trigsubs) expecting a sum or difference of two functions but got -sin(x)-sin(y)

trigsubs(sin(y-x)+sin(z-w));
Error, (in trigsubs) expecting a sum or difference of two functions but got -sin(-y+x)-sin(-z+w)

Likely, this error message arises because the normalization changes the type of the terms from function to `*`:

whattype(sin(-x));
                                  *

And the primitive pattern matcher of trigsubs seems unable to cope this with case.

I observe an error message arising already in Maple V Release 2 (the oldest version that I have installed):

readlib(trigsubs): 
trigsubs(-sin(a)-sin(b)); 
Error, (in trigsubs) sum or difference of two functions expected not , -sin 
(a)-sin(b) 

And I see that the code in Maple 14 and Maple V Release 2 is the same, besides cosmetic changes. Now, Maple V Release 2 was released in Nov. 1992 and trigsubs is copyrighted 1990. So, I find quite likely that the its code has not changed, basically, from its release, over 20 years ago. [Michael Komma should be credited for recently reminding elsewhere about this longstanding bug]

Trigonometric identities are a very basic subject. So, that the routine devoted to handling them, has not been really improved, and its bugs corrected, in about 20 years (2/3 of the lifetime of Maple) is a shame, in my opinion. Maple has a serious deficit in the critical area of pattern matching. But yet, better faciliies became available in the late 20 years.

Indeed, for about 15 years, rules like these ones have been lurking around my Maple initialization files:

trig_sumtoprod:=[
sin(a::algebraic)+sin(b::algebraic)=2*sin((a+b)/2)*cos((a-b)/2),
sin(a::algebraic)-sin(b::algebraic)=2*cos((a+b)/2)*sin((a-b)/2),
cos(a::algebraic)+cos(b::algebraic)=2*cos((a+b)/2)*cos((a-b)/2),
cos(a::algebraic)-cos(b::algebraic)=2*sin((a+b)/2)*sin((b-a)/2)
]:

So that

applyrule(trig_sumtoprod,sin(x)+sin(y));
                   2 sin(x/2 + y/2) cos(x/2 - y/2)

The first two rules may be combined and extended like this:

sin_sumtoprod:=conditional(A::algebraic*sin(a::algebraic)+B::algebraic*sin(b::algebraic)=
2*A*sin((a+signum(0,B/A,0)*b)/2)*cos((a-signum(0,B/A,0)*b)/2),A<>0 and _verify(B^2-A^2,0,equal)):

applyrule(sin_sumtoprod,exp(x)*sin(x)+exp(x)*sin(y));
                2 exp(x) sin(x/2 + y/2) cos(x/2 - y/2)

applyrule(sin_sumtoprod,4*sin(y-x)+4*sin(z-w));
      -8 sin(- y/2 + x/2 - z/2 + w/2) cos(y/2 - x/2 - z/2 + w/2)

Certainly, some of the items that you have raised in this blog series are very useful in spotting at serious defficiences of Maple in the area of symbolic computations. Note, however, that I do not post comments to them for the purpose of my recipes beeing included in your red book (though it is fine for me if you do so with proper attribution). Rather, I post here for awakening the Maplesoft management about their priority and planning problems.

Indeed, "magic", the key word in the title, is very significative in describing the current status: if performing elementary symbolic operations with Maple require "magic recipes", and even a seasoned user as you needs collecting and keeping such recipes in a handwritten book, then something is very wrong with the design of the whole system.

And from a more practical point of view, frequently I tend to avoid answering to some of you items, even though they may deserve a comment, because I do edit and preview a lot. And your blogs, so loaded with gifs, makes that each preview cycle take 1-2 mins. Only exceptionally I can afford the extra time required by such an overhead.

@hirnyk By tracing the execution of the coulditbe statement, following the routines until the source of the failure appeared. You see, coulditbe calls  coulditbe/internal, and so on. Indeed, as most of the routines in the Maple system, property/LinearProgr is not documented.

@hirnyk By tracing the execution of the coulditbe statement, following the routines until the source of the failure appeared. You see, coulditbe calls  coulditbe/internal, and so on. Indeed, as most of the routines in the Maple system, property/LinearProgr is not documented.

@Joe Riel The exercise posed by the OP is about a single vector rooted at an unspecified point. Mathematically, this is different from a single vector rooted at a fixed point. And completely different to a vector field. That is why I do not agree with your suggestion to use VectorField as a workaround. And your suggestion that I am confused about a vector field is not correct.

I do not agree either with your generalization about Maple.The problems discussed in this thread are specific to the package VectorCalculus. There are several packages an routines in Maple handling vectors, with quite diverse approaches to the subject, and with their own quota of oddities and limitations. And, hopefuly, a better package will supersede them in the future.

Your explanation about the symbols for the coordinates, in this example r, phi, and z, not being recognized as such in a VectorCalculus object, even after being declared with the command SetCoordinates, if official, should better be added to the documentation. As it stands, it is not posible to deduce this fact. And indeed, such a behavior is quite odd and inconvenient, in my opinion.

In applications to physical sciences, single vectors rooted at a fixed point are used sometimes. But more frequently vectors rooted at an unspecified, or partially specified, root point are needed. An example may help. Consider the dynamics of a point particle. The formulation of the problem starts with its velocity and acceleration vectors rooted at the unspecified position of the particle (it may be partially specified if constraints hold). The coordinates of the particle become fixed only after the equations of motion are solved, as functions of time, the initial conditions, etc.

So, the fact that the VectorCalculus package cannot handle properly vectors rooted at  unspecified, or partially specified points, after your explanation, is a serious limitation.

I do not quite catch what do you mean with your last paragraph. You say that the root position was assigned [2*r, 0, 0] in cylindrical coordinates. So r=2*r, implying r=0. This corresponds to the axis of cylindrical symmetry. And at its points, the angular coordinate phi is undefined, so it cannot be set to zero.

@Joe Riel The exercise posed by the OP is about a single vector rooted at an unspecified point. Mathematically, this is different from a single vector rooted at a fixed point. And completely different to a vector field. That is why I do not agree with your suggestion to use VectorField as a workaround. And your suggestion that I am confused about a vector field is not correct.

I do not agree either with your generalization about Maple.The problems discussed in this thread are specific to the package VectorCalculus. There are several packages an routines in Maple handling vectors, with quite diverse approaches to the subject, and with their own quota of oddities and limitations. And, hopefuly, a better package will supersede them in the future.

Your explanation about the symbols for the coordinates, in this example r, phi, and z, not being recognized as such in a VectorCalculus object, even after being declared with the command SetCoordinates, if official, should better be added to the documentation. As it stands, it is not posible to deduce this fact. And indeed, such a behavior is quite odd and inconvenient, in my opinion.

In applications to physical sciences, single vectors rooted at a fixed point are used sometimes. But more frequently vectors rooted at an unspecified, or partially specified, root point are needed. An example may help. Consider the dynamics of a point particle. The formulation of the problem starts with its velocity and acceleration vectors rooted at the unspecified position of the particle (it may be partially specified if constraints hold). The coordinates of the particle become fixed only after the equations of motion are solved, as functions of time, the initial conditions, etc.

So, the fact that the VectorCalculus package cannot handle properly vectors rooted at  unspecified, or partially specified points, after your explanation, is a serious limitation.

I do not quite catch what do you mean with your last paragraph. You say that the root position was assigned [2*r, 0, 0] in cylindrical coordinates. So r=2*r, implying r=0. This corresponds to the axis of cylindrical symmetry. And at its points, the angular coordinate phi is undefined, so it cannot be set to zero.