For sure, 'coeff' should work for polynomials. Hence, the idea is to get the differential operator for this ODE, that 'de2diffop' writes as a polynomial in 'Dx', which represents d/dx.

I would like very much to have such a thing implemented.

I wonder also about a graphical representation of this hierarchy, something like this one for Axiom.

For a property P, 'about(P)' informs about parents and children of P (and this information is stored in tables). It seems that there is nothing like that for types (the closest related thing seems 'subtype'). I wonder why a similar facility has not been implemented with types.

In Mathematica it is 'Identity', in Maxima 'identity', and in Axiom 'id'. All of them, though seem to work only for a single argument.

In a plot for Ea(alpha) (with the code below) I get that it diverges for alpha aprox 0.25, apparently a pole there (observe the change of sign in your results).

s:=solve({vF*F+vE*Ea+vC,hF*F+hE*Ea+hC},{Ea,F});
subs(s,vF=coeff(lhs(Sumfzasvert),F,1),vE=coeff(lhs(Sumfzasvert),Ea,1),vC=coeff(coeff(lhs(Sumfzasvert),Ea,0),F,0),
hF=coeff(lhs(Sumfzashor),F,1),hE=coeff(lhs(Sumfzashor),Ea,1),hC=coeff(coeff(lhs(Sumfzashor),Ea,0),F,0),Ea):
combine(%,units);
Ealpha:=%/(1000*Unit(kg/m));
plot(Ealpha,alpha=0..Pi/2,-500..500);

In a plot for Ea(alpha) (with the code below) I get that it diverges for alpha aprox 0.25, apparently a pole there (observe the change of sign in your results).

s:=solve({vF*F+vE*Ea+vC,hF*F+hE*Ea+hC},{Ea,F});
subs(s,vF=coeff(lhs(Sumfzasvert),F,1),vE=coeff(lhs(Sumfzasvert),Ea,1),vC=coeff(coeff(lhs(Sumfzasvert),Ea,0),F,0),
hF=coeff(lhs(Sumfzashor),F,1),hE=coeff(lhs(Sumfzashor),Ea,1),hC=coeff(coeff(lhs(Sumfzashor),Ea,0),F,0),Ea):
combine(%,units);
Ealpha:=%/(1000*Unit(kg/m));
plot(Ealpha,alpha=0..Pi/2,-500..500);

This simpler form is what I have shown above. I also dislike side effects. In fact, I think that the Maple library should be updated in this regard.

This simpler form is what I have shown above. I also dislike side effects. In fact, I think that the Maple library should be updated in this regard.

Worksheets were broken many times in the past because of syntax changes: quotes ( " ) was used for ditto and then changed to string delimiter, dot ( . ) was used for concatenation and nowadays is used for different products (so that a syntax that produced an error like '2.3.2' produces 4.6, which I think that is nonsense).

So, things sometimes change and some are broken. Nevertheless, it need not be the case here and you could add an enviroment variable switch or option or whatever to choose the orthodox behavior or the "demoniac"  behavior that I propose.

The relevant point is whether this change is useful for some users. I would find it very useful.

Worksheets were broken many times in the past because of syntax changes: quotes ( " ) was used for ditto and then changed to string delimiter, dot ( . ) was used for concatenation and nowadays is used for different products (so that a syntax that produced an error like '2.3.2' produces 4.6, which I think that is nonsense).

So, things sometimes change and some are broken. Nevertheless, it need not be the case here and you could add an enviroment variable switch or option or whatever to choose the orthodox behavior or the "demoniac"  behavior that I propose.

The relevant point is whether this change is useful for some users. I would find it very useful.

No, what I say is not "dramatic" but common sense. As far as well defined mathematical rules are followed, there should not be any inconsistency. Sure, for domains with a notion of order, similar considerations hold.

And properties should be more tightly integrated. I would find excelent if here

assume(a>b):
if a>b then boo else foo end if;

a call to a theorem prover (currently 'is') is made. It would be much better than issuing an error message inconsistent with the property information available by the system.

I agree, if mathematical simplification were also handled by default in if A=B then..., then there'd have to also be a syntax to deliberately avoid it.

And, doesn't it matter that the proposal is backwards incompatible and would break a lot of users' previously authored code?

This is not so dramatic either. Surely there are ways to make changes and keep backwards compatibility.In fact, if a piece of software shows that this is possible, Maple is that one.

In regards with speed, there are many speeds. I understand that you are primordially concerned with computational speed. But I am mostly concerned with the speed of the human-CAS combined system along an interactive session. For this purposes, forcing the user to deal with arcane ways of operation, makes much more waste of time that any little computational overhead that might be required to make the life of the user easier.

Comprenhensive documentation is good. But user-centered design is even better.

No, what I say is not "dramatic" but common sense. As far as well defined mathematical rules are followed, there should not be any inconsistency. Sure, for domains with a notion of order, similar considerations hold.

And properties should be more tightly integrated. I would find excelent if here

assume(a>b):
if a>b then boo else foo end if;

a call to a theorem prover (currently 'is') is made. It would be much better than issuing an error message inconsistent with the property information available by the system.

I agree, if mathematical simplification were also handled by default in if A=B then..., then there'd have to also be a syntax to deliberately avoid it.

And, doesn't it matter that the proposal is backwards incompatible and would break a lot of users' previously authored code?

This is not so dramatic either. Surely there are ways to make changes and keep backwards compatibility.In fact, if a piece of software shows that this is possible, Maple is that one.

In regards with speed, there are many speeds. I understand that you are primordially concerned with computational speed. But I am mostly concerned with the speed of the human-CAS combined system along an interactive session. For this purposes, forcing the user to deal with arcane ways of operation, makes much more waste of time that any little computational overhead that might be required to make the life of the user easier.

Comprenhensive documentation is good. But user-centered design is even better.

it works in Classic GUI also.

it works in Classic GUI also.

is quite different. At a normal user level, it makes much more sense to be able to look at identity in the mathematical (semantic) sense than at the the low level, memory sense. So, with your vectors:

x := Vector[row]([1,2]);
                                  x := [1, 2]
 
y := Vector[row]([1,2]);
                                  y := [1, 2]
 

The comparison,

if x = y then

should be true. It just requires that `=`, when recognizing that the operands are vectors, call 'LinearAlgebra:-Equal'. Presumably, another command or option should be added for use in development, checking identity at memory level.