the intersection ('AndProp') of properties 'real' and 'infinity' should be "empty", ie 'BottomProp', but:

AndProp(real,infinity);
                       AndProp(real, infinity)

From these:

RealRange(-infinity,infinity);
                                 real

RealRange(Open(-infinity),Open(infinity));
                                 real

I think that the first is wrong. I do not find consistent either that something called 'realcons' include infinity.

I find that the graphical interfaces are currently not quite reliable and ocasional content loss occurs. I backup saved worksheets as frequently as possible.

I agree. To avoid repeating all this stuff and making easier to have a pointer, I have started this page where all the contributions on the subject could be collected.

I agree. To avoid repeating all this stuff and making easier to have a pointer, I have started this page where all the contributions on the subject could be collected.

Presumably, about type expressions vs property expressions, as:

map2(type,'Or'(Q>0,Q<0),[type,property]);
	[false, false]

map2(type,OrProp(Q>0,Q<0),[type,property]);
	[false, false]

If most types are properties, sounds like most type expressions are property expressions.

In particular, ?property states:

You can use Or as a synonym for OrProp

Presumably, about type expressions vs property expressions, as:

map2(type,'Or'(Q>0,Q<0),[type,property]);
	[false, false]

map2(type,OrProp(Q>0,Q<0),[type,property]);
	[false, false]

If most types are properties, sounds like most type expressions are property expressions.

In particular, ?property states:

You can use Or as a synonym for OrProp

As the time scale here is 1/H, small times imply Ht<<1. So, I would change to a new independent variable T=Ht and expand in powers of T, like:

with(PDEtools,dchange):
`H'` := diff(H(t), t);
`H''` := diff(diff(H(t), t), t);
d:=3*H(t)^2-1/24*mu^6*(6*H(t)^2*`H'`+3*`H'`^2+H(t)*`H''`+H(t)^4)/(H(t)^2*(`H'`+H(t)^2)^3) = 0;
dchange({t=T/h(T),H(t)=h(T)},d):
simplify(%):
d1:=collect(%,diff,factor);
Order:=3:
dsolve(d1,h(T),series);


                                        5        3
  h(T) = h(0) + D(h)(0) T + 1/2 (72 h(0)  D(h)(0)

                   7                            6            2   6
         + 216 h(0)  D(h)(0) - 6 h(0) D(h)(0) mu  - 5 D(h)(0)  mu

                   6        2          8       2   6    /         6
         + 216 h(0)  D(h)(0)  + 72 h(0)  - h(0)  mu )  /  (h(0) mu )
                                                      /

         2      3
        T  + O(T )

In particular, for h(0)<>0 and D(h)(0)=0 you have the deSitter solution.

As the time scale here is 1/H, small times imply Ht<<1. So, I would change to a new independent variable T=Ht and expand in powers of T, like:

with(PDEtools,dchange):
`H'` := diff(H(t), t);
`H''` := diff(diff(H(t), t), t);
d:=3*H(t)^2-1/24*mu^6*(6*H(t)^2*`H'`+3*`H'`^2+H(t)*`H''`+H(t)^4)/(H(t)^2*(`H'`+H(t)^2)^3) = 0;
dchange({t=T/h(T),H(t)=h(T)},d):
simplify(%):
d1:=collect(%,diff,factor);
Order:=3:
dsolve(d1,h(T),series);


                                        5        3
  h(T) = h(0) + D(h)(0) T + 1/2 (72 h(0)  D(h)(0)

                   7                            6            2   6
         + 216 h(0)  D(h)(0) - 6 h(0) D(h)(0) mu  - 5 D(h)(0)  mu

                   6        2          8       2   6    /         6
         + 216 h(0)  D(h)(0)  + 72 h(0)  - h(0)  mu )  /  (h(0) mu )
                                                      /

         2      3
        T  + O(T )

In particular, for h(0)<>0 and D(h)(0)=0 you have the deSitter solution.

As the method is somewhat involved and the notation a bit ambiguous, I wished first to check both the plausibility of this solution and get an understanding of what is involved, before  going to the proof.

Starting with the notations in the Patrick's version, for the equation:

ode:= diff(y(x),x)*y(x)-y(x) = f(x);

the first issue is the change of variables (x,y)->(t,r):

with(PDEtools,dchange):
dchange({x=exp(t)-2*A,y(x)=1/2*exp(t)*(r(t)+1/3)},ode,[t,r],known=f):
collect(4*%,diff,expand@(u->u/exp(t))):
d2:=subs(f(exp(t)-2*A)=f1(t),%);


                      /d      \       2                    4 f1(t)
   d2 := (r(t) + 1/3) |-- r(t)| + r(t)  - 4/3 r(t) - 5/9 = -------
                      \dt     /                            exp(t)

Ie we get another Abel equation for r(t), where f1(t)=f(x(t)). Now, r(t) is given as the real root(s) of the cubic:

eq:=r(t)^3+p(t)*r(t)+q(t);

where p(t) and q(t) are given functions (involving f1(t)), for which I use 'pt' and 'qt':

g:= ( ( t*sin(t) + cos(t) ) * Ci(t) + (cos(t))^(2)   ) * ( 4*t*Ci(t) + cos(t) )*exp(-t) / 
( 2*(2*t*Ci(t))^(3) )-2*f1(t);
pt:=3+4*(g+f1(t))*exp(-t)-16/3;
qt:=-4*(g+2*f1(t))*exp(-t)+4/3*(3+4*(g+f1(t))*exp(-t))-2*(4/3)^3;

Generically, there will be one or three families of real solutions (it may depend on t). So, my first check was to choose f1(t)=exp(t), solve for a real root of 'eq' at a "nice" point, use that as IC for 'd2' and compare its numerical solution with the solutions of 'eq' as functions of t.

d2a:=(simplify@subs)(f1(t)=exp(-t),d2);
subs(p(t)=pt,q(t)=qt,f1(t)=exp(-t),eq):
collect(%,r,u->collect(u,exp)):#to make it look nice
eqa:=evalindets(%,`^`,simplify);

I choose the IC at t=1

Digits:=14:
eqa1:=eval(eqa,t=1.):
r1q:=fsolve(subs(r(1.)=r1,eqa1),r1);

                        r1q := 1.5164414176292
rn:=dsolve({d2a,r(1.)=r1q},numeric);

And compare the plots of the curves, from 'eqa' with 'implicitplot' and from 'rn' with 'odeplot':

with(plots):
p1:=implicitplot(eqa,t=1..5,r=0..3, gridrefine=2,color=green):
p2:=odeplot(rn,1..5,view=-1..3):
display(p1,p2);

This is not a proof, and there are some discrepancies between the curves. But small discrepancies do not seem to me unexpected due to the numerical errors, mainly at solving the cubic and specially at the switch of its real branch. And that these curves match partially seem to me suggesting that the roots of the cubic are indeed solutions.

Apparently, there is not really a package implementating these set operations,  but  there are some workarounds, eg using properties representing real intervals. Ie a "property algebra" representation. See these threads:

RealRange union - is there a better way?

unions of ranges?

change the arguments of functions

In this example:

AndProp(RealRange(2,5), RealRange(3,7));

                           RealRange(3, 5)

OrProp(RealRange(2,5), RealRange(3,7));

                           RealRange(2, 7)

The Watcom readme.txt states:

Some Open Watcom tools currently do not function properly if installed in a directory with spaces in the name e.g. "C:\Program Files\WATCOM". Therefore choose a directory name like C:\WATCOM, D:\WATCOM etc. to install the tools in.

A similar statement appears at some point of the installation of Maple.

I have Watcom installed at the default directory "c:\watcom-1.3". And there are two subdirectories "maple11" and "maple12" with "include" and "lib" subdirectories each. Is this all the stuff that the compiler needs?

I prefer installing Maple (and other applications) in a directory without spaces, just to avoid problems (eg when I access the Win partition from Linux, without precautions a command may take a path name with spaces as multiple parameters, etc).

Then, which is the effective method to get the complete list of protected names?

You do overwrite assumptions by assigning a different value to 'a'. Ie 'assume(0<a)' assigns to 'a'  a second  variable 'a~' which is another index to the table `property /object`:

assume(a::real); 
`property/object`[a];
                                 real

assume(0<a);
`property/object`[a];
                     RealRange(Open(0), infinity)

to read this article, but saddly I have not access to it...