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

There is a minor mistake in the above code.

The external function name used in the define_external() call is 'dgesvd'. But that will not work on MS-Windows. The symbol for the external function should instead be 'dgesvd_' with a trailing underscore. That is what is actually in the external dynamic library.

In other words, in the Maple procedure degsvd above there should instead be a line like,

   dgesvd_external:=define_external('dgesvd_',

It seems that it works with either symbol name, 'dgesvd' or 'dgesvd_', on Linux.

acer

Alec asked if users might get direct programmatic access to the parser.

He was talking about the Standard GUI and typesetting control, I think. And it is probably hard to expose. It seems that the Std GUI has its own parser, outside of the Maple kernel.

Would such access pre-empt automatic simplification by the kernel?

acer

Alec asked if users might get direct programmatic access to the parser.

He was talking about the Standard GUI and typesetting control, I think. And it is probably hard to expose. It seems that the Std GUI has its own parser, outside of the Maple kernel.

Would such access pre-empt automatic simplification by the kernel?

acer

Step-function. Right. Yet another choice.

I see now that a step-function shows from plotting operator 'f' in my post below. I wouldn't have guessed beforehand that it would be so.

acer

Step-function. Right. Yet another choice.

I see now that a step-function shows from plotting operator 'f' in my post below. I wouldn't have guessed beforehand that it would be so.

acer