1) I guess the copying of some code from Maple IDE and pasting it here have to give the symbols, not the image

I guess it will be better to have after pasting

restart;

not

2) Besides that it would be great if you introduce a special tag for code presentation. A text presented within this tag should be specially formatted for better perseption.

3) I'd like to have a possibility to use browser spellchecker without opening html-form.

I guess you should create some rules for making posts and questions and present it here. Everyone creates his own rules (style) and it is not good.

You can take as a pattern a message system of http://stackoverflow.com

If Maple is working in default regime

(when created by me file maple.ini
c:\Program Files\Maple 17\Users\maple.ini
with the  string
libname := cat( kernelopts( homedir ), kernelopts( dirsep ), "MapleLib" ), libname:
is deleted)

then all works great. But if I am trying to use my MapleLib, then the application "The Cosmic Travel Planner" (and many others) cannot run some code automatically.

I have provided the full control over this folder for EVERYONE but it doesn't resolve the problem.

PS
Dear developers! I guess you should explain better how Maple community can vote for the applications upploaded for competition within the Mobius project. Is it like on facebook or dirrect e-mail are the only possible ways of votation? I fortuned the asterisk in the Maple cloud in IDE and pusshed it. It appeared to be my vote for the application! I guess, you should mention about this way of votation somewhere. If the vote through the IDE is not accepted then you should mention about it too.

@Carl Love 

it is a list of thread-safe functions while Physics is a package. Besides that `.` is thread-safe ( http://www.maplesoft.com/support/help/Maple/view.aspx?path=dot ) so I supposed that Physics:-`.` can be thread safe too. Very likely I was wrong.

The problem is solved in Maple 17.02

solved.mw

Hi ecterrab

Thank you for solutions.

Regarding the second problem only the end user knows what form of presentation of complex number is preferable in his case. Moreover, there are few situations when splitting of a complex number into Re + I Im is preferable to not splitting. Therefore, the decision to split or not to split indeed have to be strongly dependent on a particular task. For objective reasons Maple is unable to handle what form of complex number is simplifying for the end user. So, the correct behaviour of Simplify/conjugate is not to split a complex number at all. The compromise might be not splitting for conjugate command and splitting (in some sittuations) for Simplify command. Of couse it is only my oppinion.

Hi ecterrab

Thank you for solutions.

Regarding the second problem only the end user knows what form of presentation of complex number is preferable in his case. Moreover, there are few situations when splitting of a complex number into Re + I Im is preferable to not splitting. Therefore, the decision to split or not to split indeed have to be strongly dependent on a particular task. For objective reasons Maple is unable to handle what form of complex number is simplifying for the end user. So, the correct behaviour of Simplify/conjugate is not to split a complex number at all. The compromise might be not splitting for conjugate command and splitting (in some sittuations) for Simplify command. Of couse it is only my oppinion.

@ecterrab

Thank you for explaining the difference between `*` and `.` and for explaining presented in PhysicsUpdate.mw. They are really helpful.

One more observation. Physics:-Simplify cannot always simplify the elementary expressions with fermionic operators:

restart; 
with(Physics); Setup(mathematicalnotation = true); Setup(anticommutativeprefix = psi); 

for i to 4 do 
ap[i] := Creation(psi, i, notation = explicit); 
am[i] := Annihilation(psi, i, notation = explicit) 
end do; 

z := ap[1].am[2].am[2]; 
Simplify(z);

0

z := am[1].am[2].am[2]; 
Simplify(z);

Simplify_problem.mw

I suppose that some kind of defect appeared in Physics package.

notations.mw

@ecterrab

Thank you for explaining the difference between `*` and `.` and for explaining presented in PhysicsUpdate.mw. They are really helpful.

One more observation. Physics:-Simplify cannot always simplify the elementary expressions with fermionic operators:

restart; 
with(Physics); Setup(mathematicalnotation = true); Setup(anticommutativeprefix = psi); 

for i to 4 do 
ap[i] := Creation(psi, i, notation = explicit); 
am[i] := Annihilation(psi, i, notation = explicit) 
end do; 

z := ap[1].am[2].am[2]; 
Simplify(z);

0

z := am[1].am[2].am[2]; 
Simplify(z);

Simplify_problem.mw

I suppose that some kind of defect appeared in Physics package.

notations.mw

@ecterrab 

Some issues emerged with SortProducts and expand.

SortProduct_expand_problem.mw

@ecterrab 

Some issues emerged with SortProducts and expand.

SortProduct_expand_problem.mw

@ecterrab 

I will test the new version of Coefficients with great pleasure.

@ecterrab 

I will test the new version of Coefficients with great pleasure.

macro command solved the problem.

The procedure below

coeffuniversal := proc (z) 
local W, h; 
W := [seq(h*op(i, z), i = 1 .. nops(z))]; 
#W := [seq(select(type, W[i], commutative), i = 1 .. numelems(W))]; 
W := map(u->select(type, u, commutative), W);
map(u->u/h, W) 
end proc

gets the coefficients both operator expression and wave function expression. Internal variable 'h' is dynamically created at the procedure call so it doesn't interfere with the variable 'h' that may exist in the argument 'z'.

I'd prefer to multiply by 1 rather than 'h', namely to replace the first command of the procedure with the following one

W := [seq(`%*`(1, op(i, z)), i = 1 .. nops(z))]

but it doesn't give the desired result.

There is a short summary of this thread in the attached file.
coefficients.mw

The procedure below

coeffuniversal := proc (z) 
local W, h; 
W := [seq(h*op(i, z), i = 1 .. nops(z))]; 
#W := [seq(select(type, W[i], commutative), i = 1 .. numelems(W))]; 
W := map(u->select(type, u, commutative), W);
map(u->u/h, W) 
end proc

gets the coefficients both operator expression and wave function expression. Internal variable 'h' is dynamically created at the procedure call so it doesn't interfere with the variable 'h' that may exist in the argument 'z'.

I'd prefer to multiply by 1 rather than 'h', namely to replace the first command of the procedure with the following one

W := [seq(`%*`(1, op(i, z)), i = 1 .. nops(z))]

but it doesn't give the desired result.

There is a short summary of this thread in the attached file.
coefficients.mw