Something like this works, I think, to get a result for a and b as posints greater than or equal to 2. But I did it by hand.

> sol := Sum((-1)^i*binomial(b-1,i)*t^(a-1+i+1)/(a-1+i+1),i = 0 .. b):

> value(eval(sol,[a=3,b=4,t=2]));
                                     -4/5

acer

If only the floating point result is wanted, then evalf(f(x,a,b)) could also be OK, provided that f creates the inert Int() instead of int() , like John has done above.

Now, to the question about it being a bug. Would it not be better if int() could return a conditional result here?

I wasn't able to get anything out of int() under the following assumptions. Maybe someone else can see how. (Is there not a closed form answer in terms of binomials to expand (t-1)^(b-1)?)

> restart:
> _EnvAllSolutions:=true:

> f := Int( t^(a-1) * (1-t)^(b-1), t=0..x ):

> value(simplify(expand(f)))
>   assuming a::AndProp(integer,RealRange(2,infinity)),
>            b::AndProp(integer,RealRange(2,infinity)), x>0;

                              x
                             /
                         b  |    (a - 1)         (b - 1)
                    -(-1)   |   t        (-1 + t)        dt
                            |
                           /
                             0

acer

If only the floating point result is wanted, then evalf(f(x,a,b)) could also be OK, provided that f creates the inert Int() instead of int() , like John has done above.

Now, to the question about it being a bug. Would it not be better if int() could return a conditional result here?

I wasn't able to get anything out of int() under the following assumptions. Maybe someone else can see how. (Is there not a closed form answer in terms of binomials to expand (t-1)^(b-1)?)

> restart:
> _EnvAllSolutions:=true:

> f := Int( t^(a-1) * (1-t)^(b-1), t=0..x ):

> value(simplify(expand(f)))
>   assuming a::AndProp(integer,RealRange(2,infinity)),
>            b::AndProp(integer,RealRange(2,infinity)), x>0;

                              x
                             /
                         b  |    (a - 1)         (b - 1)
                    -(-1)   |   t        (-1 + t)        dt
                            |
                           /
                             0

acer

What Axel's trying to show is that LambertW(1) is an exact symbolic representation of the value that satisfies the equation.

The 0.56.. floating-point result is only an approximation accurate to a finite number of digits. The evalf() command can be used to approximate the exact symbolic quantity to however many decimal digits you wish.

You could also use fsolve instead of solve, if you wanted only the floating-point result.

Maple is a computer algebra system (CAS) and it is able to do lots of exact computation involving such exact symbolic quantities, which is why `solve` doesn't just return the approximate result.

acer

What Axel's trying to show is that LambertW(1) is an exact symbolic representation of the value that satisfies the equation.

The 0.56.. floating-point result is only an approximation accurate to a finite number of digits. The evalf() command can be used to approximate the exact symbolic quantity to however many decimal digits you wish.

You could also use fsolve instead of solve, if you wanted only the floating-point result.

Maple is a computer algebra system (CAS) and it is able to do lots of exact computation involving such exact symbolic quantities, which is why `solve` doesn't just return the approximate result.

acer

There's not much point in googling either.

The Maple language code in the .mla archives requires an interpreter in order to run. The Maple kernel is such an interpreter. I don't think that there is any other full and good interpreter of that syntax. So such Maple code only runs in Maple itself. As a result the world is not fascinated by it. You might find this post of interest, though.

Only the Maple graphical user interface is implemented in Java. None of the computational numeric code in Maple is implemented in Java (with the very, very minor exception of some plot rendering stuff, I suppose).

acer

You posted this query twice. I posted a response here, that might be of some use to you.

acer

The fact that Maple's `int` can get better answers following some change or variables is well known and documented by many examples over the years on usenet. Sometimes `int` gets a poor answer without it, and sometimes no answer. As far as I know there is no algorithm to find such the natural substitution that gives the best result. But candidate substitutions are often obvious. A scheme with pattern matching and trying some candidate substitutions has been suggested as an augmentation to `int` in the past. I cannot recall where and when I first saw it, but it wouldn't have been recently.

Change of variables is often not the only way to get the nicer answer, and that's true in this case too. (FTOC and simplification under assumptions also "worked".) This is merely part of what makes definite integration extra tricky -- how to choose methods to try and whose results to accept.

acer

The fact that Maple's `int` can get better answers following some change or variables is well known and documented by many examples over the years on usenet. Sometimes `int` gets a poor answer without it, and sometimes no answer. As far as I know there is no algorithm to find such the natural substitution that gives the best result. But candidate substitutions are often obvious. A scheme with pattern matching and trying some candidate substitutions has been suggested as an augmentation to `int` in the past. I cannot recall where and when I first saw it, but it wouldn't have been recently.

Change of variables is often not the only way to get the nicer answer, and that's true in this case too. (FTOC and simplification under assumptions also "worked".) This is merely part of what makes definite integration extra tricky -- how to choose methods to try and whose results to accept.

acer

Could you name an example, the versions for which it differs, and whether the object is (2D Math) input or output?

acer

The Maple Standard GUI is a Java application.

The Maple kernel (interpreter) is written in C and C++.

The Maple Math Library is written in the Maple language. This is an interpreted language. It is not compiled. See the help-page showstat for how to look at the source of such routines. (Also, kernelopts(verboseproc=3) and `eval`.) These routines are stored in the .mla archives.

Some numerics are also inplemented in C and C++ and accessed on the fly by Library routines using Maple's external calling mechanism. Some of that is proprietary (3rd party, not Maplesoft) and may not be available for open release.

The functionality to compile Maple language routines to stand-alone executables is limited: it can be done (partly by hand) for a small subset of possible routines which do pure numerics (symbolics would require the licensed oem OpenMaple, and thus not be "stand-alone".) Producing stand-alone Maplets is also problematic, partly because of its tie-in to the interpreted Maple language..

acer

That simplify() method, while slick, is actually not very efficient.

Consider this example,

> expr := expand(1-(1-x1*x6)*(1-x1*x5*x7)^100):

> st,ba:=time(),kernelopts(bytesalloc):
> simplify( expr, {seq( (x||i)^2 = x||i, i=1..7 ) } );
                        x1 x5 x7 + x1 x6 - x1 x6 x7 x5
> time()-st,kernelopts(bytesalloc)-ba;
                                6.205, 67096576

And now, in a new session,

> expr := expand(1-(1-x1*x6)*(1-x1*x5*x7)^100):

> flat:=z->subsindets(z,specop({identical(seq(x||
> i,i=1..7)),posint},`^`),t->`if`(type([op(t)],
> [name,posint]),op(1,t),t)):

> st,ba:=time(),kernelopts(bytesalloc):
> flat(expr);
                        x1 x5 x7 + x1 x6 - x1 x6 x5 x7
> time()-st,kernelopts(bytesalloc)-ba;
                                0.044, 4979824

And, just for fun, in another fresh session,

> expr := expand(1-(1-x1*x6)*(1-x1*x5*x7)^100):

> flat := z -> FromInert(subsindets(ToInert(z),specfunc(
> {specfunc(identical("x1","x2","x3","x4","x5","x6","x7"),_Inert_NAME),
>     specfunc(posint,_Inert_INTPOS)},
> _Inert_POWER),t->op(1,t))):

> st,ba:=time(),kernelopts(bytesalloc):
> flat(expr);
                        x1 x5 x7 + x1 x6 - x1 x6 x5 x7
> time()-st,kernelopts(bytesalloc)-ba;
                                0.058, 1310480

Of course, the efficiency at larger powers and longer expressions might not matter for your particular application.

acer

The competition that you mentioned sounds like this.

acer

I am going to guess that what the poster is really hoping for is some way to get Maple to actually do symbolic summation under these conditions. He may have some problem -- very particular in nature -- for which he knows that a closed form is possible on account of special circumstances for the excluded finite index values. And if the poster suspects that the symbolic summation may not work nicely for all n=1..N together (can it be so?) then the suggestion to do sum(..,n=1..N) - add(..,n in S) may not appear as satisfactory.

That's just a guess.

acer

I am going to guess that what the poster is really hoping for is some way to get Maple to actually do symbolic summation under these conditions. He may have some problem -- very particular in nature -- for which he knows that a closed form is possible on account of special circumstances for the excluded finite index values. And if the poster suspects that the symbolic summation may not work nicely for all n=1..N together (can it be so?) then the suggestion to do sum(..,n=1..N) - add(..,n in S) may not appear as satisfactory.

That's just a guess.

acer