Yes, exporting by plotsetup as a jpeg embeded into eps file (instead of vector format) is a degrading feature introduced in Maple 13 Standard GUI. The solution is using Classic GUI, a previous version of Maple, or something else. Depending on your platform, may be that you could run Classic.

Yes, exporting by plotsetup as a jpeg embeded into eps file (instead of vector format) is a degrading feature introduced in Maple 13 Standard GUI. The solution is using Classic GUI, a previous version of Maple, or something else. Depending on your platform, may be that you could run Classic.

By chance, are you aware of an updated review on multithreading for mathematical software?

It works, at least for x>1:

convert(arccosh(x),ln);
(simplify@convert)(%,arccosh) assuming x>1;
                                  1/2        1/2
                    ln(x + (x - 1)    (x + 1)   )

                              arccosh(x)

It works, at least for x>1:

convert(arccosh(x),ln);
(simplify@convert)(%,arccosh) assuming x>1;
                                  1/2        1/2
                    ln(x + (x - 1)    (x + 1)   )

                              arccosh(x)

Actually, anything inside the backquotes gets type name:

type(`#msqrt(mn("2"))`,name);
                                    true

Presumably, the numeral sign # as a first character of a name is used by the parser to identify exports of the Typesetting package, in this case:

Typesetting:-msqrt(mn("2"));

However, this is not documented.

Actually, anything inside the backquotes gets type name:

type(`#msqrt(mn("2"))`,name);
                                    true

Presumably, the numeral sign # as a first character of a name is used by the parser to identify exports of the Typesetting package, in this case:

Typesetting:-msqrt(mn("2"));

However, this is not documented.

I do not know as Re is builtin, but time and memory usage seem a bit different:

restart:
`tools/bench`(Re(Array([seq(i+I,i=1..10^5)])));
                            0.156, 2517617

restart:
`tools/bench`(Re~(Array([seq(i+I,i=1..10^5)])));
                            0.203, 3217872

I do not know as Re is builtin, but time and memory usage seem a bit different:

restart:
`tools/bench`(Re(Array([seq(i+I,i=1..10^5)])));
                            0.156, 2517617

restart:
`tools/bench`(Re~(Array([seq(i+I,i=1..10^5)])));
                            0.203, 3217872

Yes, elementwise operators were introduced in Maple 13. There are some differences between map and ~:

1. Syntax. See ?operators,elementwise:

Unlike map and zip, which usually apply to the operands of their given arguments, element-wise operations treat non-container data types as single elements.  For example, f~(a=b) evaluates to f(a=b), wheras map(f,a=b) breaks apart the equation applying f to each side of the equation resulting in f(x)=f(b).

2. Efficiency. See ?updates,Maple13,efficiency:

The elementwise operator syntax can be more efficient than zip or map in some cases. Specific operations have been optimized compared to the general code used by zip or map. In other cases, depending on the input, built-in hardware floating-point routines can be used directly.

If equivalent, I prefer this elementwise operator syntax as it allows typing less (important as I type slow) and have more compact input (hence visually more clear).

Yes, elementwise operators were introduced in Maple 13. There are some differences between map and ~:

1. Syntax. See ?operators,elementwise:

Unlike map and zip, which usually apply to the operands of their given arguments, element-wise operations treat non-container data types as single elements.  For example, f~(a=b) evaluates to f(a=b), wheras map(f,a=b) breaks apart the equation applying f to each side of the equation resulting in f(x)=f(b).

2. Efficiency. See ?updates,Maple13,efficiency:

The elementwise operator syntax can be more efficient than zip or map in some cases. Specific operations have been optimized compared to the general code used by zip or map. In other cases, depending on the input, built-in hardware floating-point routines can be used directly.

If equivalent, I prefer this elementwise operator syntax as it allows typing less (important as I type slow) and have more compact input (hence visually more clear).

After ?VectorCalculus[Divergence], the argument should be a vector field or a Vector valued procedure. So, actually it should produce an error message as in:

with(VectorCalculus):
sigma := Matrix(3, 3, {(1, 1) = A*x^2, (1, 2) = 2*A*x*y, (1, 3) = 0,
 (2, 1) = 0, (2, 2) = A*y^2, (2, 3) = 0, (3, 1) = 0, (3, 2) = 0, 
(3, 3) = 1}):

Divergence(sigma);
Error, invalid input: too many and/or wrong type of arguments 
passed to VectorCalculus:-Divergence; first unused argument 
is Matrix(3, 3, [[...],[...],[...]], datatype = anything)

After ?VectorCalculus[Divergence], the argument should be a vector field or a Vector valued procedure. So, actually it should produce an error message as in:

with(VectorCalculus):
sigma := Matrix(3, 3, {(1, 1) = A*x^2, (1, 2) = 2*A*x*y, (1, 3) = 0,
 (2, 1) = 0, (2, 2) = A*y^2, (2, 3) = 0, (3, 1) = 0, (3, 2) = 0, 
(3, 3) = 1}):

Divergence(sigma);
Error, invalid input: too many and/or wrong type of arguments 
passed to VectorCalculus:-Divergence; first unused argument 
is Matrix(3, 3, [[...],[...],[...]], datatype = anything)

Yes, you have not advanced much. There are several issues in your procedures to deal with. It might be better that you exercise geting right simpler operations and procedures first.

One issue is the arithmetic operations involving Quantity objects. For instance, you write

[...]
T := t+273.15;
[...] 

This will not work if t is a Quantity object:

Quantity(12.35, 1, relative)+273.15;
                   Quantity(12.35, 12.35) + 273.15

I.e., you do not get a Quantity object as output. A way to do it is by using combine/errors:

combine(Quantity(12.35, 1)+273.15,errors);
                         Quantity(285.50, 1.)

Yes, you have not advanced much. There are several issues in your procedures to deal with. It might be better that you exercise geting right simpler operations and procedures first.

One issue is the arithmetic operations involving Quantity objects. For instance, you write

[...]
T := t+273.15;
[...] 

This will not work if t is a Quantity object:

Quantity(12.35, 1, relative)+273.15;
                   Quantity(12.35, 12.35) + 273.15

I.e., you do not get a Quantity object as output. A way to do it is by using combine/errors:

combine(Quantity(12.35, 1)+273.15,errors);
                         Quantity(285.50, 1.)