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

Do you consider that you own that term as a common law trademark?

acer

I see, the context menus which explicitly suggest the variable names like '#msub(mi("v"),mi("x"))' don't do anything for your equation. That's a bug.

The context-menu items which just do general solving (ie. Solve -> Solve, rather than Solve -> Solve for Variable) seem to work ok.

You could try entering the solve() call by hand, instead of using the context-menus.

solve( eqn, v_x )

where you remember to toggle the v_x as atomic identifier so that it truly matches the name of your variable in the equation.

The subliteral item is in the top-right corner of the Layout palette. You can manage palettes using the top menubar with the choice View -> Palettes -> Show Palette.

acer

I see, the context menus which explicitly suggest the variable names like '#msub(mi("v"),mi("x"))' don't do anything for your equation. That's a bug.

The context-menu items which just do general solving (ie. Solve -> Solve, rather than Solve -> Solve for Variable) seem to work ok.

You could try entering the solve() call by hand, instead of using the context-menus.

solve( eqn, v_x )

where you remember to toggle the v_x as atomic identifier so that it truly matches the name of your variable in the equation.

The subliteral item is in the top-right corner of the Layout palette. You can manage palettes using the top menubar with the choice View -> Palettes -> Show Palette.

acer

It may be necessary to toggle each relevant instance of v_x (which gets created as table-reference v[x] by default) as an atomic identifier.

In other words, you have to toggle it in each of your equations, and also in your solve() call if you use it as one of the variables for which to solve.

Or use the subliteral item from the palettes, for each and every occurence.

And make such that none of them are in any special font (bold, italic, size, etc) before toggling as atomic.

In short, you have to make sure that all the instances of v_x really are the same atomic name, for solve() and Maple to recognize then as being the same.

Wouldn't it be nice, if v_x got typeset as v with an x as the subscript without getting converted by default to the indexed name v[x]? If that were so, then all this atomic identifier effort would not be required. I cannot recall having seen anyone post code where the table-reference nature of subscripted input names was desired.

acer

It may be necessary to toggle each relevant instance of v_x (which gets created as table-reference v[x] by default) as an atomic identifier.

In other words, you have to toggle it in each of your equations, and also in your solve() call if you use it as one of the variables for which to solve.

Or use the subliteral item from the palettes, for each and every occurence.

And make such that none of them are in any special font (bold, italic, size, etc) before toggling as atomic.

In short, you have to make sure that all the instances of v_x really are the same atomic name, for solve() and Maple to recognize then as being the same.

Wouldn't it be nice, if v_x got typeset as v with an x as the subscript without getting converted by default to the indexed name v[x]? If that were so, then all this atomic identifier effort would not be required. I cannot recall having seen anyone post code where the table-reference nature of subscripted input names was desired.

acer

Leaving aside this particular student for a moment, what about the situation that one has forgotten how to do something in Maple or is a complete neophyte?

How will that user discover the appropriate Maple routines to use?

Some of the routine names can be successfully guessed. `diff` for differentiation, `piecewise` for piecewise functions, etc. But some, like `fsolve`, are much harder to guess.

I haven't checked, but I wonder how many of the questions on these sample examples can be found though the "Tasks" section of Maple's Help system. The context-sensitive menus (right-clicking on expressions and objects) may also be relevant to this. Hopefully both Tasks and context-menus are in the pop-up Tips database.

Back to this student: I hope that the evaluation is more about using and understanding Maple properly than it is about merely remembering routine names. Thus I am content to give up the routine names as hints -- the student can then learn how to use the system (which may then sink in).

acer

Leaving aside this particular student for a moment, what about the situation that one has forgotten how to do something in Maple or is a complete neophyte?

How will that user discover the appropriate Maple routines to use?

Some of the routine names can be successfully guessed. `diff` for differentiation, `piecewise` for piecewise functions, etc. But some, like `fsolve`, are much harder to guess.

I haven't checked, but I wonder how many of the questions on these sample examples can be found though the "Tasks" section of Maple's Help system. The context-sensitive menus (right-clicking on expressions and objects) may also be relevant to this. Hopefully both Tasks and context-menus are in the pop-up Tips database.

Back to this student: I hope that the evaluation is more about using and understanding Maple properly than it is about merely remembering routine names. Thus I am content to give up the routine names as hints -- the student can then learn how to use the system (which may then sink in).

acer

In Unix/Linux/OSX the stack limit may need to be increased in the shell from which maple gets run, for this computation to complete.

I bumped my shell's stack limit up to 50000 (from 8192) on Solaris and saw combinat[numbpart](11269) come out correct in Maple 8 and incorrect in Maple 9. On 64bit Linux, with a stack limit of 10240, it completed (incorrectly) in Maple 11.02.

Of course, you may find that kernelopts(stacklimit) allows you to raise the working limit from within Maple. But that may depend on what the OS's shell's hard limit is.

On Windows, it may be trickier, I am not sure. You might try to utilize Maple's -T option, or its equivalent on Windows. I don't remember what hard limit might be compiled into the binaries. (For what it's worth, I do seem to recall that one can actually change the stacklimit built right into a Windows binary executable using MSVC++ tools.)

acer