Ie there are things that are "remembered" across the execution of 'restart'. Eg. execute in a fresh (Windows) session:

currentdir("c:/");
restart:
currentdir();

This help page seems rather outdated. Thank you for looking at the code.

This help page seems rather outdated. Thank you for looking at the code.

May be also 'Cache[RemoveTemporary]' and 'Cache[RemovePermanent]'.

May be also 'Cache[RemoveTemporary]' and 'Cache[RemovePermanent]'.

That is a big issue...

Apparently, in the search of "efficiency" some commands are designed in such way that their output is session dependent (see eg this thead). There are also effects of cache that  change the output for reexecutions of a command.

In this particular case it should be looked in detail which is the issue. 

There are behaviors as designed (ie technically not a bug) that are wrong for me.

That is a big issue...

Apparently, in the search of "efficiency" some commands are designed in such way that their output is session dependent (see eg this thead). There are also effects of cache that  change the output for reexecutions of a command.

In this particular case it should be looked in detail which is the issue. 

There are behaviors as designed (ie technically not a bug) that are wrong for me.

Tried once in document mode I have got the same form of answer than in Classic worksheet: a 'cos' term from the homogeneous solution and one from the particular one. I do not beleive that the interface has an influence on the form of the output (beyond display bugs). Most probably there is some randomness at work in the simplification of this output.

Tried once in document mode I have got the same form of answer than in Classic worksheet: a 'cos' term from the homogeneous solution and one from the particular one. I do not beleive that the interface has an influence on the form of the output (beyond display bugs). Most probably there is some randomness at work in the simplification of this output.

Apparently it can be solved:

for u in B do
`property/object`[u]:=evaln(`property/object`[u]);
`property/OrigName`[u]:=evaln(`property/OrigName`[u]);
end do;

about(x);about(y);

x:
  nothing known about this object

y:
  nothing known about this object

Apparently it can be solved:

for u in B do
`property/object`[u]:=evaln(`property/object`[u]);
`property/OrigName`[u]:=evaln(`property/OrigName`[u]);
end do;

about(x);about(y);

x:
  nothing known about this object

y:
  nothing known about this object

In fact, the calculation of the integral over the interval (-1,1):

J:=Int(arccos(x)/(1+x^4),x=-1..1);

is quite simple using the symmetries of the integrand, ie its even denominator invariant under the change x=-u and the transformation of arccos(x) under this change:

with(IntegrationTools):
Change(J,x=-u);
Expand(%):
subsop(1=value(op(1,%)),%);
combine(%,ln);

                       /1                  
                      |   Pi - arccos(u)   
                      |   -------------- du
                      |        4           
                     /-1      u  + 1       
            /1  (1/2)      1  (1/2)   /     (1/2)\
         Pi |- 2      Pi - - 2      ln\2 - 2     /
            \4             8                      

              3  (1/2)   /     (1/2)\   1  (1/2)      \
            + - 2      ln\2 + 2     / - - 2      ln(2)|
              8                         8             /

              /  /1             \
              | |   arccos(u)   |
            - | |   --------- du|
              | |     4         |
              \/-1   u  + 1     /
       /          /    (1/2)      \\          /  /1             \
  1    |          |   2      - 2  ||  (1/2)   | |   arccos(u)   |
- - Pi |-2 Pi + ln|- -------------|| 2      - | |   --------- du|
  8    |          |          (1/2)||          | |     4         |
       \          \  10 + 7 2     //          \/-1   u  + 1     /

As the second term is -J, it turns out that the first term is 2*J. Ie the value of J is:

op(1,%)/2;
evalf(%);

2.723675968

Geometrically, the curve of arccos(x) divides the rectangle of height Pi and base on the interval (-1,1) in two halves. So, because of the even denominator, J the integral below the curve is equal to the integral above the curve up to Pi. This does not solve the original integral but it is nice and value(J) also produces a wrong and horrible sum of dilogs:

evalf(value(J));

-.7657561321-.4274644056*I

or 20 Digits I get an almost identical wrong answer in Maple 11.02. Eg:

Digits:=14:
chp14:=chebpade(f(x), x, [5,5]);
                                                        
                                             3                     5
-0.00010759544286396 x + 0.0020760361530642 x  + 0.21844054341650 x
--------------------------------------------------------------------
                                        2                     4
    1.1485395830035 - 0.39902328074461 x  + 0.13592548631674 x

evalf(eval(chp14,x=.1));

                                                      -5
                                  -0.56782396637635 10

What do you get? On the other hand, with Digits:=10 I get this error message:

chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]);

Error, (in numapprox:-chebpade) for this function the maximum approximation degree is 7 when Digits = 10

and

Digits:=12:
chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]);
Error, (in numapprox:-chebpade) for this function the maximum approximation degree is 9 when Digits = 12

On the other hand, yes this is fine:

Digits:=14:
chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]):
evalf(eval(chpp,x=.1));

                                                      -5
                                   0.20047765960983 10

I do not find in ?numapprox[chebpade] explanation and advice on these issues. Eg when it is better to use 'pade' and when 'chebpade' (or something else). Apparently, in this example, 'pade' is better (at least in the sense of less trouble).

or 20 Digits I get an almost identical wrong answer in Maple 11.02. Eg:

Digits:=14:
chp14:=chebpade(f(x), x, [5,5]);
                                                        
                                             3                     5
-0.00010759544286396 x + 0.0020760361530642 x  + 0.21844054341650 x
--------------------------------------------------------------------
                                        2                     4
    1.1485395830035 - 0.39902328074461 x  + 0.13592548631674 x

evalf(eval(chp14,x=.1));

                                                      -5
                                  -0.56782396637635 10

What do you get? On the other hand, with Digits:=10 I get this error message:

chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]);

Error, (in numapprox:-chebpade) for this function the maximum approximation degree is 7 when Digits = 10

and

Digits:=12:
chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]);
Error, (in numapprox:-chebpade) for this function the maximum approximation degree is 9 when Digits = 12

On the other hand, yes this is fine:

Digits:=14:
chpp:=chebpade(f(x), x=0 .. 1/3, [5,5]):
evalf(eval(chpp,x=.1));

                                                      -5
                                   0.20047765960983 10

I do not find in ?numapprox[chebpade] explanation and advice on these issues. Eg when it is better to use 'pade' and when 'chebpade' (or something else). Apparently, in this example, 'pade' is better (at least in the sense of less trouble).

For this related integral:

J:=Int(arccos(x)/(1+x^4),x=-1..1):evalf(%);
2.723675968

The result is quite simple in terms of the roots of the unity:

       /          1 + alpha1              1 + alpha2 \
1/4 Pi |alpha1 ln(----------) + alpha2 ln(----------)|
       \          alpha1 - 1              alpha2 - 1 /

evalf(eval(%,[alpha1=(1+I)/sqrt(2),alpha2=(-1+I)/sqrt(2)]));

2.723675968+0.*I

No hypergeometric, Lerch, etc. Details tomorrow.