> restart:
> P:=15000:
> E:=proc(x) option remember;
>   -E(x-1)*(-11*P+10*E(x-1))/P;
> end proc:
> E(1):=1:
> kernelopts(printbytes=false):
> st:=time(): length(E(20)); time()-st;
                                    3348149

                                    92.177

> restart:
> P:=15000:
> E:=proc(x) option remember;
>   evalf( -E(x-1)*(-11*P+10*E(x-1))/P );
> end proc:
> E(1):=1:
> st:=time(): E(20); time()-st;
                                             17778
                             -0.5132751215 10

                                      0.

It may be worth noting, for the benefit of the understand of the OP, that the use of 10.0 will bring about floating-point arithmetic (similar to using evalf). Also, the use of [] table references will have pretty much the same effect as using procedure calls with option remember.

It may be worth noting, for the benefit of the understand of the OP, that the use of 10.0 will bring about floating-point arithmetic (similar to using evalf). Also, the use of [] table references will have pretty much the same effect as using procedure calls with option remember.

Copy the expression from where? What precisely is the notation for the derivatives in the source?

What does it mean, to paste an expression into Maple's eval? Does it mean to paste it as 2D Math or 1D Maple notation input into a worksheet and then to subsequently apply 2-parameter eval to it? Are Maple's right-click context-menus being used for this, in any way?

Could you post the problematic example? (It might help make fsolve better...)

There was no disparagement intended by the single word, "no", and I'm sorry if it appeared that way. I simply meant that I disagreed. I don't put much stock in the few words in a Subject line, since there's no much scope therein for accurate expressiveness. This is math and computer science, and only the truth should matter.

There can be no question of your great mathematical expertise, Alec, nor of your very strong understanding of calculus. But the posted statement wasn't just about calculus -- it was just as much about symbolic integration, symbolic expressions, and simplification. And, as stated, it was demonstrably wrong from the computer algebra side.

The examples I gave can be modified, to make the demonstration more clear. The point is not that F1 and F2 differ by a constant (no longer true below) but that they are distinct and different expressions which produce the same derivative result.

> F1 := sin(x)^2-cos(x)^2-1;
                                      2         2
                          F1 := sin(x)  - cos(x)  - 1
  
> F2 := -2*cos(x)^2;
                                              2
                               F2 := -2 cos(x)
  
> simplify(F2-F1);
                                       0
  
> diff(F1,x);
                                4 sin(x) cos(x)
  
> diff(F2,x);
                                4 sin(x) cos(x)

It is clear that the integral of 4*sin(x)*cos(x) cannot be both F2 and F1 above. It has to be one or the other. And F1 and F2 are most certainly different expressions. Yet the original claim was to the effect that int(diff(Z,x),x) should be the same expression as Z. This example demonstrates that that is logically impossible, in general.

The same holds for a minor modification by a constant of the other example I showed. The point is not that Q1 and Q2 differ by a constant (no longer true below) but that they are distinct and different expressions which produce the same derivative result.

> Q1:=arccot(x);
                                Q1 := arccot(x)
  
> Q2:=-arctan(x)+Pi/2;
                                   Pi
                            Q2 := ---- - arctan(x)
                                   2
  
> simplify(Q2-Q1);
                                       0
  
> diff(Q1,x);
                                       1
                                   - ------
                                          2
                                     1 + x
  
> diff(Q2,x);
                                       1
                                   - ------
                                          2
                                     1 + x

Here, the result of int(-1/(1+x^2),x) cannot be both expression Q1 and expression Q2, since Q1 and Q2 are different and distinct expressions.

The fact that F1 and F2 (or Q1 and Q2) may both represent the same mathematical quantity is quite beside the point of the original stated claim. And (this is key) the issue of simplification was indeed central to the original post. The original post did not state that the integral was wrong, and indeed it specifically mentioned that the result was not known at the time to be either right or wrong. There was something else objectionable about it -- that it was not the very same expression. So, the question of simplification or of alternate forms was quite germane. It was, in truth, what the post was all about.

I would agree that the form of the integration result for the original posted example is remarkably poor. I'm not claiming that it shouldn't be much, much simpler. For example, simple substitution of variables can help produce a much better result (in terms of expln, and much "closer" to the original expression when also converted to expln form). And there are likely much better ways, for that example.

But let's face it, the original post was all about the desirability of particular forms. And it didn't merely state that the result was wildly off in terms of form. Rather, it made a very broad statement about round-tripping expressions through diff and int (to get back the very same expression) which is not logically tenable in general.

There is a great deal that is of interest in symbolic integration. And there is much that can be improved in Maple's implementations (eg. continuous antiderivatives, simplified forms, use of substitution of variables, careful and judicious short-circuiting of Risch or other algorithms in order to attain simpler forms for result, etc, etc).

Regardless of whether the result of that posted int call is true or not, that broad statement about expressions which represent integrals of derivatives is not true. It misses the key possibility of distinct expressions which may be mathematically equivalent and produce the same derivative. The integral of that common derivative can only be one of the distinct expressions.

In the example below, F1 and F2 are different (distinct) expressions, for both of which Maple produces the same expression as the derivative. The integral of 4*sin(x)*cos(x) is only going to be either F1 or F2, and not both expressions. (According to your statement, it is wrong behaviour if either is not returned.)

> F1 := sin(x)^2-cos(x)^2;
                                        2         2
                            F1 := sin(x)  - cos(x)
 
> diff(F1,x);
                                4 sin(x) cos(x)
 
> int(%,x);
                                           2
                                  -2 cos(x)

> F2:=%:
> diff(F2,x);
                                4 sin(x) cos(x)

Here's another example. Q1 and Q2 produce the same derivative. One of them has to get put aside, when integrating -1/(1+x^2). Note that Q1 and Q2 are different expressions.

> Q1:=arccot(x);
                                Q1 := arccot(x)
 
> Q2:=-arctan(x);
                               Q2 := -arctan(x)
 
> diff(Q1,x);
                                       1
                                   - ------
                                          2
                                     1 + x
 
> diff(Q2,x);
                                       1
                                   - ------
                                          2
                                     1 + x

You might have intended all sorts of qualifying aspects of the broad statement, about simplification (of both integral and derivative, perhaps). But if those were critical to the claim then it would only make sense to state such extra qualifying aspects explicitly.

You're welcome. But you should probably consider the following. It's a bit of a cheat to use surd(...,3) inside a cube-root procedure, even as a checking mechanism. I mean, if you have access to surd() then you don't need such a proc as yours at all.

So, instead, consider comparing x1 and x2 (before updating x1). Look at their difference, and use that as the error estimate `e` instead of x2-surd(evalf(x0),3).

You're welcome. But you should probably consider the following. It's a bit of a cheat to use surd(...,3) inside a cube-root procedure, even as a checking mechanism. I mean, if you have access to surd() then you don't need such a proc as yours at all.

So, instead, consider comparing x1 and x2 (before updating x1). Look at their difference, and use that as the error estimate `e` instead of x2-surd(evalf(x0),3).

Curious. `discont` gets {1,2}, so I'd have expected the integration to work.

> g:=piecewise(x<1,0,x>2,0,exp(-1/((x-1)*(x-2))^2));
                    {            0                      x < 1
                    {
                    {            0                      2 < x
               g := {
                    {               1
                    { exp(- -----------------)        otherwise
                    {              2        2
                    {       (x - 1)  (x - 2)
 
> discont(g,x);
                                    {1, 2}
 
> int(g,x=-infinity..infinity);
                                       0
 
> evalf(Int(g,x=-infinity..infinity));
                                              -7
                               0.1706450027 10
 
> plot(g,x=-infinity..infinity);

> int(g,x=5/4..7/4);
                                   undefined
 
> int(g,x=1.25..1.75);
                                              -7
                               0.1706449483 10

Using kernelopts(mapledir) instead of kernelopts(homedir) as the default location for saving a user's file is not good.

Using kernelopts(mapledir) instead of kernelopts(homedir) as the default location for saving a user's file is not good.

Are you hoping that the hypergeom will simplify to some other "more familiar" special function, or just to get a shorter length of the result?

Are you hoping that the hypergeom will simplify to some other "more familiar" special function, or just to get a shorter length of the result?

Is this a start?

ex1 := x*(1-G(x,y)/y*(1-G(x,y)))^2:
ex2 := y*(1-F(x,y)/y*(1-F(x,y)))^2:
conds := eval(F(x,y)=G(x,y),solve({F(x,y)=ex1,G(x,y)=ex2},{F(x,y),G(x,y)})):
solve(conds,{x,y});