In Argentina it is called "pistolete", from the French term. So, likely, "French curve" does not come from France (though a French person might be involved). Its usage was/is standard for students of technical schools. To the point that there is a facebook group of pistolete haters.

@Joe Riel Mathematically there is no confusion, and the operation is clear and most elementary (any first year student should be able to do it). The orthonormal vectors of a non-cartesian basis, do depend on the coordinates of the root point (in this example on phi). Hence, in this example, the transformation of the components of a vector in such a basis to the cartesian basis involve the coordinates of the root point.

That the VectorCalculus package routines could get "confused" is a completely different story. I have to repeat that as it stands, this package is of little use for vectors in noncartesian basis, in my opinion.

@Joe Riel Mathematically there is no confusion, and the operation is clear and most elementary (any first year student should be able to do it). The orthonormal vectors of a non-cartesian basis, do depend on the coordinates of the root point (in this example on phi). Hence, in this example, the transformation of the components of a vector in such a basis to the cartesian basis involve the coordinates of the root point.

That the VectorCalculus package routines could get "confused" is a completely different story. I have to repeat that as it stands, this package is of little use for vectors in noncartesian basis, in my opinion.

@Joe Riel I have not mentioned bug, but warned about unexpected behavior and nonstandard design in the VectorCalculus package.

Technically, reporting a bug would require a clear specification of the expected behavior. Otherwise, deciding what is a bug becomes a subjective matter. As the available documentation of this package is quite confusing, at least to my taste, I would avoid it.

In particular, it is not clear to me how far the symbols r, phi, and z are being interpreted as names of the coordinates. In the context of the declaration 

SetCoordinates(cylindrical[r,phi,z]):

I would expect they were. But clearly, the value 0, say, at the slot for phi in the root vector is being used, though partially. And this partial use is the unexpected fact.

A vector field and a single vector rooted at an unspecified/partially specified point, or free vector are different mathematical concepts. And for a physical image, it is not the same a point particle moving with velocity v, than the movement of a fluid, described by a vector field v(r). So, I do not find that using VectorField is a desirable replacement for the representation of single vectors.

@Joe Riel I have not mentioned bug, but warned about unexpected behavior and nonstandard design in the VectorCalculus package.

Technically, reporting a bug would require a clear specification of the expected behavior. Otherwise, deciding what is a bug becomes a subjective matter. As the available documentation of this package is quite confusing, at least to my taste, I would avoid it.

In particular, it is not clear to me how far the symbols r, phi, and z are being interpreted as names of the coordinates. In the context of the declaration 

SetCoordinates(cylindrical[r,phi,z]):

I would expect they were. But clearly, the value 0, say, at the slot for phi in the root vector is being used, though partially. And this partial use is the unexpected fact.

A vector field and a single vector rooted at an unspecified/partially specified point, or free vector are different mathematical concepts. And for a physical image, it is not the same a point particle moving with velocity v, than the movement of a fluid, described by a vector field v(r). So, I do not find that using VectorField is a desirable replacement for the representation of single vectors.

@Joe Riel Thank you for noting the missing vector.

@Joe Riel Thank you for noting the missing vector.

Care is needed with the RootVector constructor as values of coordinates of the root point may not be properly handled. E.g. choosing a root point with angle phi=0:

with(VectorCalculus):
SetCoordinates(cylindrical[r,phi,z]):
RootedVector(root=<r,0,z>,[3*cos(phi),-2*r,5]):
MapToBasis(%,cartesian);
                                  [3 cos(phi)]
                                  [          ]
                                  [   -2 r   ]
                                  [          ]
                                  [    5     ]

A priory, it seems like phi=0 is used for simplifying sin(phi) and one factor cos(phi), but not the other one.

Also, parallel transport does not seems to be implemented, so that operations between rooted vectors with different root points are not available, e.g. suming two vectors based on different points of the same half-line phi=0:

RootedVector(root=<1,0,z>,[1,0,0])+RootedVector(root=<2,0,z>,[1,0,0]);
Error, (in VectorCalculus:-+) cannot combine two rooted vectors with different points of origin

It would be needed, say, when computing the total force on an extended body, by summing forces applied on different points.

Care is needed with the RootVector constructor as values of coordinates of the root point may not be properly handled. E.g. choosing a root point with angle phi=0:

with(VectorCalculus):
SetCoordinates(cylindrical[r,phi,z]):
RootedVector(root=<r,0,z>,[3*cos(phi),-2*r,5]):
MapToBasis(%,cartesian);
                                  [3 cos(phi)]
                                  [          ]
                                  [   -2 r   ]
                                  [          ]
                                  [    5     ]

A priory, it seems like phi=0 is used for simplifying sin(phi) and one factor cos(phi), but not the other one.

Also, parallel transport does not seems to be implemented, so that operations between rooted vectors with different root points are not available, e.g. suming two vectors based on different points of the same half-line phi=0:

RootedVector(root=<1,0,z>,[1,0,0])+RootedVector(root=<2,0,z>,[1,0,0]);
Error, (in VectorCalculus:-+) cannot combine two rooted vectors with different points of origin

It would be needed, say, when computing the total force on an extended body, by summing forces applied on different points.

The VectorCalculus package "interprets" the coefficient -2*r for e[phi] as the "value" of the angle phi, and uses it for the projection into the cartesian basis of a vector with components along e[r] and e[z]. This nonstandard interpretation makes this package of little use for vectors in noncartesian basis, in my opinion.

@Joe Riel 

It seems that there is a difference between both versions for structured types:

restart:
TypeTools[AddType]( regexp,
 proc(sym, pat)
 local match;
     if type(sym, {symbol,string}) and type(pat, {symbol, string}) 
              and StringTools:-RegMatch(pat, sym, 'match')
     then
         if match = convert(sym, string) then
             return true;
         end if; 
     end if;
     return false;
 end proc );
 
type(my2FuncA01(x,y), typefunc(symbol, regexp(`[a-zA-Z]+A[0-9]+`)) );
                                false

type(f(my2FuncA01), specfunc(regexp(`[a-zA-Z]+A[0-9]+`),f) );
                                false

restart:
TypeTools:-AddType( regexp,
                     proc(sym, pat)
                         type(sym, '{symbol,string}')
                         and type(pat, '{symbol, string}')
                         and StringTools:-RegMatch(pat, sym)
                     end proc ):

type(my2FuncA01(x,y), typefunc(symbol, regexp(`[a-zA-Z]+A[0-9]+`)) );
                                 true

type(f(my2FuncA01), specfunc(regexp(`[a-zA-Z]+A[0-9]+`),f) );
                                 true

Apparently, an anchor is needed:

type(my2FuncA01(x,y), typefunc(symbol, regexp(`^[a-zA-Z]+A[0-9]+`)) );
                                false

type(f(my2FuncA01), specfunc(regexp(`^[a-zA-Z]+A[0-9]+`),f) );
                                false

The limitation of algsubs for multiple replacements can be somewhat worked around by using foldr like:

q1:=sin(a*b*k)+(a*b*k)^2:
foldr(algsubs,q1,k*c=d,a*b=c);
                              2
                             d  + sin(d)

Certainly, algsubs is a most important command for these symbolic computations, and it is a pitty that its development has been frozen (or so) for about 15 years.

@Axel Vogt 

The single argument signum is not reliable because of this "strange" property, after ?signum:

The value of signum(0) is controlled by the environment variable _Envsignum0. If _Envsignum0 is not assigned a value, then signum(0) is not defined, in that it can evaluate to anything.

Then, in my opinion, it is better to use the three argument version where the value is well defined:

signum(0,0,0), signum(0,0.0,0);
                                 0, 0

Indeed, it seems the form most frequently used in the library code.

I agree, a text form for input would be much more convenient than images, both for direct copy&paste and for reduced load time (so long for my taste, that I tend to avoid clicking on these blogs). Besides, the result is not so aesthetic anyway as the inline formulas appear misaligned with the surrounding text.

@rlopez 

The quadrant-dependence can be handled by conditional rules, like:

r:=[conditional(sin(x::algebraic) =sqrt((1-cos(2*x))*(1/2)), _is(sin(x)>=0)), 
conditional(sin(x::algebraic) =-sqrt((1-cos(2*x))*(1/2)), _is(sin(x)<0))]:

applyrule(r,sin(u)) assuming 0<u,u<Pi;
                                           1/2
                       1/2 (2 - 2 cos(2 u))

applyrule(r,sin(u)) assuming Pi<u,u<2*Pi;

                                            1/2
                       -1/2 (2 - 2 cos(2 u))

Indeed, there are here two weaknesses in Maple that need to be addressed:

1. Properties like the expression x in [2*k*Pi, (2*k+1)*Pi] when k is integer. A good representation of predicates and "abstract" sets in their terms is missing. This is why I am using instead a condition on the sign of sin(x) for the case of x a name.

2. Handling properties, like the sign, with nested functions:

is(sin((1/2)*arctan(v, u))>0) assuming v<0,u>0;
                                 FAIL

Meeting weakness 2 is a consequence of weakness 1. I have made some progress in a workaround for 2.

Answered privately as requested.