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

I believe that the "Enable SMP support" option refers to which Maple kernel gets run. The two choices in Maple 11 are mserver and mtserver. The first of those is the usual kernel. The second is one in which the Threads package can be run (and may not be quite as stable). You may also be able to tell which one you are currently in by issuing the command kernelopts(multithreaded) .

But even without that SMP support option toggled, you can still enable separate kernels for separate worksheets/Documents. Whether to do so depends on whether you want all assignments and data to be accessible across your open documents within a single session. (I almost never want this, not so much because I want the benefit of utilizing multiple cores, but more because I don't want each window clobbering data or variables in the other. So I usually have it set to "new engine for each document", or "ask each time".)

I believe that on a multicore system distinct document windows running distinct kernel instances can use distinct cores (if available, just as the GUI itself can use one distinct from that which the kernel uses), even without the SMP option enabled. Hopefully someone will correct that statement, if it's wrong. That little paragraph below the SMP checkbox on the Options popup doesn't have much content.

So, the "Enable SMP support" and "New engine for each document"  options appear to be pretty orthogonal.

acer

You may be interested to learn that the ArrayTools:-Alias routine does not make a full copy of the data. What it does, instead, is provide an alternate view of the data.

Suppose for example that V is a 1-D Alias view of some M, a 2-D Matrix, where one of V or M had been created by an ArrayTools:-Alias call on the other. These two names, V and M point at the same data. Changing an element in one will show up if accessed from the other, and vice versa.

This makes Alias very popular, as it allows a no-copy bypass around difficulties where one routine produces a Matrix and another routine expects a Vector, and one wishes to pass the same data back and forth. No extra storage is used up, by the Alias call. And no extra time is taken for copying elements from one structure to another.

This may be useful, with respect to the last section in the above uploaded worksheet. The convert() calls may be avoided altogether, I suspect. A code fragment might look something like this, where b is the data Matrix,

m,n := LinearAlgebra:-Dimension(b);
d := ArrayTools:-Alias(b,[m*n]):
LinearAlgebra:-Normalize(d,inplace);
Img := ImageTools:-Create(b):
ImageTools:-Entropy(Img);

acer