The number 0 is an scalar. The geometric character of a scalar is different to a vector, a form or any tensor (ie they transform differently under some group) . Addition makes sense only for magnitudes with the same geometrical character. The same, an equation makes sense if on both sides, this geometrical is the same.

In calculations by hand, one may abuse by using the number zero for the 0 vector, etc. But in a computer program with little intelligence, it seems wiser to keep consistency in the notations. Ie, if a "0" is added to a sum of two forms as the result from a calculation, say, and there is a routine to check that all the terms have the same geometrical character, better add it as a 0-two form. Otherwise the routine should be able to handle exceptional rules of interpretation for zeros and inconsistencies may arise.

This package provide a specific command for the representation of zeros: ?DifferentialGeometry:-Tools[DGzero] .

I do not see in the output of 'with(DifferentialGeometry)' an export for '*'. So, it may be using the top level '*' with its automatic simplifications at work.

This paper mentions a collection of 179 problems. It would be interesting to see a comparative review of provers built in CAS and these other ones, eg how they perform under such collection of problems.

This paper mentions a collection of 179 problems. It would be interesting to see a comparative review of provers built in CAS and these other ones, eg how they perform under such collection of problems.

Apparently this is the stated purpose of 'RealDomain'. From ?RealDomain:

The RealDomain package provides an environment in which computations are performed under the assumption that the basic underlying number system is the field of real numbers.

3. Results returned by procedures are postprocessed by discarding values containing any detectable non-real answers or replacing them with undefined where appropriate.

But not the fact:

with(RealDomain):
limit(sqrt(4 - x^2),x=2);
                                  0

By the way, I see its code:

showstat(RealDomain:-limit);
RealDomain:-limit := proc()
   1   _EnvSolveOverReals := true;
   2   NumericEventHandler(('real_to_complex') = r2c_handler);
   3   clean(`assuming`([limit(args)],['real']))
end proc

and I wonder what 'clean' does.

PS Whatever it does, it seems that there is a bug here in that 'RealDomain:-' is missing, cf:

showstat(RealDomain:-sqrt);
RealDomain:-sqrt := proc()
   1   _EnvSolveOverReals := true;
   2   NumericEventHandler(('real_to_complex') = RealDomain:-r2c_handler);
   3   RealDomain:-clean(`assuming`([sqrt(args)],['real']))
end proc

on the other hand, it works:

solve({((1-a)*(1-b))>=0, a<=1});

                  {a <= 1, b <= 1}, {a = 1, 1 <= b}

on the other hand, it works:

solve({((1-a)*(1-b))>=0, a<=1});

                  {a <= 1, b <= 1}, {a = 1, 1 <= b}

Some previous steps towards the automated proof are there:

is(a+b <= 2 ) assuming -1< a,a < 1,-1 < b,b <1;
                                    true

is(a*b <= 1 ) assuming -1< a,a < 1,-1 < b,b <1;
                                    true

But the next step fails:

is(a+b-a*b <= 1 ) assuming -1< a,a < 1,-1 < b,b <1;

                                    FAIL

'is' is a rather weak automated prover. This field of merging CAS with automated provers seems still experimental. Perhaps within another 28 years it will be ripe...

Some previous steps towards the automated proof are there:

is(a+b <= 2 ) assuming -1< a,a < 1,-1 < b,b <1;
                                    true

is(a*b <= 1 ) assuming -1< a,a < 1,-1 < b,b <1;
                                    true

But the next step fails:

is(a+b-a*b <= 1 ) assuming -1< a,a < 1,-1 < b,b <1;

                                    FAIL

'is' is a rather weak automated prover. This field of merging CAS with automated provers seems still experimental. Perhaps within another 28 years it will be ripe...

the original post I have got l.

the original post I have got l.

One observation is that 'with(CodeGeneration)' is not needed here. Second exponents like 1.5 are dangerous because of the design of Maple where any decimal representation of a fraction in the expression makes the system assume that a float number approximation is required and the expressions may become populated with unwanted floats. So, I am replacing it with 3/2.

So, I am rewriting the bcs as:

 b := ap/(l+si)^(3/2);
 q := proc (x) options operator, arrow; 
 ap/(x+si)^(3/2)-b end proc;
 bc1 := w(0) = 0;
 E*MI*(diff(w(x), `$`(x, 3)))/(A*G)+(diff(q(x), x))/(A*G)^2
+diff(w(x), x): convert(%, D): bc2:=eval(%, x = 0);
-E*MI*(diff(w(x), `$`(x, 3)))/(A*G)-E*MI*(diff(q(x), x))/(A*G)^2:
 convert(%, D): bc3:=eval(%, x = 1);
 diff(w(x), `$`(x, 2))+q(x)/(G*A): convert(%, D): 
 bc4:=eval(%, x = 1);

Now, yes, this:

dsolve({myode,bc1,bc2,bc3,bc4});

takes too long. So, I have interrupted and obtained first the general solution that arises quickly:

s:=dsolve(myode);


                              5/2                1/2
                16 ap (x + si)      4 ap (x + si)
  s := w(x) = - ----------------- + ----------------
                     15 E MI              A G

                      4               3        2
                  ap x           _C1 x    _C2 x
         - ------------------- + ------ + ------ + _C3 x + _C4
                      3/2          6        2
           24 (l + si)    E MI

solved for the integration constants:

ws:=unapply(rhs(s),x);
eq1:=eval(bc1,w=ws);eq2:=eval(bc2,w=ws);
eq3:=eval(bc3,w=ws);
eq4:=eval(bc4,w=ws);
Cs:=solve({eq1,eq2,eq3,eq4},{_C1,_C2,_C3,_C4});

and substituted to get the solution:

subs(s,Cs,w(x));

-16/15*ap/E/MI*(x+si)^(5/2)+4*ap/A/G*(x+si)^(1/2)-1/24*ap/(l+si)^(3/2)/E/MI*x^4+1/6*ap*(2*(l+si)^(3/2)+(1+si)^(1/2))/E/MI/(1+si)^(1/2)/(l+si)^(3/2)*x^3+1/4*ap*(4*A*G*(l+si)^(3/2)+8*A*G*(l+si)^(3/2)*si-A*G*(1+si)^(1/2)+2*E*MI*(1+si)^(1/2))/(l+si)^(3/2)/A/G/E/MI/(1+si)^(1/2)*x^2+1/6*ap*(-9*E^2*MI^2*(1+si)^(1/2)*(l+si)^(3/2)-12*E*MI*si^(5/2)*A*G*(l+si)^(3/2)-6*E*MI*si^(5/2)*A*G*(1+si)^(1/2)+9*E*MI*(1+si)^(1/2)*(l+si)^(3/2)+16*si^4*A^2*G^2*(1+si)^(1/2)*(l+si)^(3/2))/E/MI/si^(5/2)/A^2/G^2/(1+si)^(1/2)/(l+si)^(3/2)*x+4/15*ap*si^(1/2)*(4*G*A*si^2-15*E*MI)/A/G/E/MI

One observation is that 'with(CodeGeneration)' is not needed here. Second exponents like 1.5 are dangerous because of the design of Maple where any decimal representation of a fraction in the expression makes the system assume that a float number approximation is required and the expressions may become populated with unwanted floats. So, I am replacing it with 3/2.

So, I am rewriting the bcs as:

 b := ap/(l+si)^(3/2);
 q := proc (x) options operator, arrow; 
 ap/(x+si)^(3/2)-b end proc;
 bc1 := w(0) = 0;
 E*MI*(diff(w(x), `$`(x, 3)))/(A*G)+(diff(q(x), x))/(A*G)^2
+diff(w(x), x): convert(%, D): bc2:=eval(%, x = 0);
-E*MI*(diff(w(x), `$`(x, 3)))/(A*G)-E*MI*(diff(q(x), x))/(A*G)^2:
 convert(%, D): bc3:=eval(%, x = 1);
 diff(w(x), `$`(x, 2))+q(x)/(G*A): convert(%, D): 
 bc4:=eval(%, x = 1);

Now, yes, this:

dsolve({myode,bc1,bc2,bc3,bc4});

takes too long. So, I have interrupted and obtained first the general solution that arises quickly:

s:=dsolve(myode);


                              5/2                1/2
                16 ap (x + si)      4 ap (x + si)
  s := w(x) = - ----------------- + ----------------
                     15 E MI              A G

                      4               3        2
                  ap x           _C1 x    _C2 x
         - ------------------- + ------ + ------ + _C3 x + _C4
                      3/2          6        2
           24 (l + si)    E MI

solved for the integration constants:

ws:=unapply(rhs(s),x);
eq1:=eval(bc1,w=ws);eq2:=eval(bc2,w=ws);
eq3:=eval(bc3,w=ws);
eq4:=eval(bc4,w=ws);
Cs:=solve({eq1,eq2,eq3,eq4},{_C1,_C2,_C3,_C4});

and substituted to get the solution:

subs(s,Cs,w(x));

-16/15*ap/E/MI*(x+si)^(5/2)+4*ap/A/G*(x+si)^(1/2)-1/24*ap/(l+si)^(3/2)/E/MI*x^4+1/6*ap*(2*(l+si)^(3/2)+(1+si)^(1/2))/E/MI/(1+si)^(1/2)/(l+si)^(3/2)*x^3+1/4*ap*(4*A*G*(l+si)^(3/2)+8*A*G*(l+si)^(3/2)*si-A*G*(1+si)^(1/2)+2*E*MI*(1+si)^(1/2))/(l+si)^(3/2)/A/G/E/MI/(1+si)^(1/2)*x^2+1/6*ap*(-9*E^2*MI^2*(1+si)^(1/2)*(l+si)^(3/2)-12*E*MI*si^(5/2)*A*G*(l+si)^(3/2)-6*E*MI*si^(5/2)*A*G*(1+si)^(1/2)+9*E*MI*(1+si)^(1/2)*(l+si)^(3/2)+16*si^4*A^2*G^2*(1+si)^(1/2)*(l+si)^(3/2))/E/MI/si^(5/2)/A^2/G^2/(1+si)^(1/2)/(l+si)^(3/2)*x+4/15*ap*si^(1/2)*(4*G*A*si^2-15*E*MI)/A/G/E/MI

e[1] &wedge e[1] is the 0-two form, and this package represents it as 0 dx ^ dy.

e[1] &wedge e[1] is the 0-two form, and this package represents it as 0 dx ^ dy.