Excerpt from the documentation (solve/details):

 The useassumptions option will not make use of any assumptions that cannot be rewritten as polynomial inequations.  In particular, it does not process assumptions restricting the domain:
solve(x^2+1,{x}, useassumptions) assuming x::real;
Warning, solve may not respect assumed property 'real' on 'x'.
                       {x = I}, {x = -I}
instead one should use RealDomain[solve] or isolve for solutions over the real numbers or over the integers, respectively.

So, the answer appears to be to use RealDomain:-solve. You can restrict to x>0, which also forces x to be real, but that may be too restrictive for some cases.

Or you do what kitonum suggests.

M.D.

Our library does not appear to give me acces to the article so I cannot check it myself. But normally you would contact the corresponding author of the article (who is nowadays usually identified by an email address) and ask whether the code is available.

I assume you checked Maplesoft's application website...?

M.D.

The quick answer is that

sum(u(n),n=0..infinity);

is what you would think it is (except in cases where sum itself does not do what you might expect).

Sum(u(n),n=0..infinity);

is the inert form, i.e. Maple does not try to execute it. The visual clue is that the sum symbol is printed in gray in the output. This is often useful e.g. when you want to simplify the argument under the sum or to distribute the sum over the terms or other manipulations, before evaluationg the sum.

sum('u(n)',n=0..infinity);

means that u(n) does not get evaluated before handed over to the sum function. Thre may be cases where that is useful although I cannot come up with one quickly.

Other than that be aware that sum tries to evaluate symbolically, e.g. to find a closed expression for the sum. If you want to add a certain number of terms, add() is the function to use.

Hope this helps,

M.D.

Gridlines have been f'd up in Maple at least since Version 15 (try to have gridlines with a log plot when you need to use display to produce a plot: no gridlines, or no log plot. I had it confirmed by Maplesoft tech support, have been promised that it would be fixed, but it never got fixed).

But I digress. In your case I'd suggest using plots[setoptions]:

plots[setoptions](gridlines=true);

which you place right before the call to plot (or plots[display], or whatever). I found that in several cases it produced what I wanted even when including the option in the plots command would not.

I hope this helps,

M.D.

You can try using "fully qualified" names to inspect variables. E.g., inspect ":-a" if you want the value of at the root level. Or inspect foo:-a if you want a at the foo level. This should work as long as you are in a routine called by foo.

Caveat: I have not tried this myself recently.

M.D.

Maple does not have a library with an Ising model. However, a quick Google search reveals this: http://zhugayevych.me/maple/, where there is a link to an Ising model. Note that I have no clue what it is (I did not load it). Check it out.

To convert your Matlab model to Maple, be aware that [ ] in Maple denotes an index into a Vector, an assignment is := rather than =, the loop syntax is "for i from 1 to 12000 do <Maplestatements> end do; and Maple statements are terminated with a semicolon. Should not be too hard, but do read the relevant Help pages. There is also [Matlab]FromMatlab to convert Matlab expressions.

HTH,

M.D.

What is wrong with hitting the "calculate whole sheet" button (the !!! button) once your sheet is loaded? No need to move the cursor anywhere.

Somehow I am not sure we understand you right, though. When you open a worksheet it displays the results from the last time you saved it. Unless you changed the sheet and saved it without recalculating it, the results would not change when you recalculate it after opening the saved file (unless you do something involving random numbers, although even then you would normally get the same sequence of random numbers). If you save a sheet with changes but without prior recalculation, you are basically saving a sheet in an inconsistent state. Not an error per se, but can lead to confusion. I have learned the hard way to avoid doing that.

M.D.

Well, this happens to me fairly regularly. My work-around is typically to create a new document block with the hour-glass like button on the toolbar of the window. At least for worksheets in Document mode this usually creates a new line and execution block w/o the red prompt. You can later delete the execution group with the prompt (cmd-delete).

I hope this helps. Creating documents with 2-d math is not for the faint-of-heart; I have torn my hair out over it on occasion. But with enough persistence it is possible to do near-textbook-quality typesetting in this way, of great value when preparing scripts for lectures.

M.D.

I haven't got the time to fully resolve this, but here are some pointers:

You do not need to muck around with delta. You do not assign a value to it so it will remain in your system as a variable of sorts and Maple can give you, e.g., the dependence of your solutions on delta. You may not, however, want to declare it local as it may not be known upon exiting your procedure (you will need to play with this; I haven't gotten that far).

You use the old versions of matrix and array; I'd switch to the new ones. When you do that you'll get an error complaining about the sparse keyword in the Array assignment next-to-last line; get rid of that; you don't need it.

I then get an "Error, bad index into Array". Most likely your solve command does not get any solutions and therefore t is not defined.

Hope this helps, I need to go now.

M.D.

In addition to Carl's answer, be aware that you can often look at large Matrices or Vectors by either double-clicking on the short output (the info about the vector you refer to above) or by double clicking on its name in the Variables list on the left-side panel of the Maple GUI. That will fail only once your output gets beyond 1 Million characters, or if your Vector has funny entries that don't get displayed at all.

In this way you avoid cluttering your worksheet with too many lines of output.

Mac Dude

As you will know, a Maple worksheet is organized in execution groups (indicated by the grouping bars on the left-hand side of the worksheet). You can execute each group by hitting the return key with the cursor in the group. After executing one group, the Variables pane on the left side allows you to see all variables Maple has created so far and inspect their values (double click on an entry, if it is a larger Vector or Matrix double click on the text in the window that just opened). If your sheet is all in one execution group you can use the menu item Edit:Split or Join:Split to separate statements PROVIDED THEY ARE NOT IN AN IF-Then-Else BLOCK, A PROC, MODULE OR LOOP! Procs, modules or loops have to be completely within an execution group so this trick does not work there.

To analyse a proc or module, you can use the debugger. Use

stopat(procname);

to invoke the debugger upon entering procname. Inside the debugger you can execute program lines and inspect variables. RTFM; the debugger is a bit complex in usage.

Debugging a for...do loop is more difficult. A trick I have used with large programs is to declare a Vector before entering the loop and then set the elements of this Vector to the loop index at strategic locations within the loop (e.g. before each procedure call; before each nexted loop etc.). If the program hits an error within the loop I inspect this Vector and can see how far it got and infer the place where it crapped out. If it is a proc, I can then use the debugger on that proc. Or (more-often than not) inspect the proc. carefully and find the problem in this way. Another way is to sprinkle print statements throughout the loop; on larger projects I would define a debug variable which is used to turn these printings on and off.

There is also a trace command which I am not overly familiar with but encourage you to read the Help pages about.

Maple's debugging facilities are not the greatest in the world. One way to get around that is to modularize your code as much as possible. I once had to re-factor a large piece of code (> 2000 lines) and encase each function in a proc; all of which resided in a library module, in order to be able to debug and maintain the code. Hopefully yours is not that long.

If you want more detailed help you'll need to post the code.

HTH,

Mac Dude.

In your code, a becomes a table, i.e. an associative array (or  hash, in Perl lingo). You get a moderate speed-up (from 29 sec to 20 sec) by declaring a as Matrix of floats:

a:=Matrix(1000,1000,datatype=float);

You get a factor of 10 by wrapping the expression in an evalhf function, which asks Maple to use the floating-point hardware (assuming Digits is 15 or less). Also, declare datatype=hfloat in that case. Final answer:

a:=Matrix(1000,1000,datatype=hfloat);
                      [ 1000 x 1000 Matrix   ]
                      [ Data Type: float[8]  ]
                 a := [ Storage: rectangular ]
                      [ Order: Fortran_order ]
st := time():

for i to 1000 do for j to 1000 do

a[i, j] := evalhf(abs(i-j+1)^0.3-abs(i-j)^0.3);

end do end do:

time()-st;

                             2.596

3 seconds is not that bad. Note that in this case the speed-up from evalhf is impressive. Often it is much less so.

M.D.

A quick look does not reveal any Maple command to parse LaTeX into Maple syntax. I assume one could read the LaTeX source as text into Maple and then parse it, but parsing LaTeX is not all that trivial so writing a parser would be some effort.

The question was asked at tex.stackexchange, but no real answer either. There is a LaTeX importer for Maple TA, but since I don't know Maple TA I don't know what it does. Google is your friend here.

There are programs around that can strip LaTeX commands off a text file but since you presumably want to import equations this would not be of help to you.

Bottom line: if you just want to import a few equations, type them in. If you have a mass-production project, maybe investing time in writnig a parser for your needs would be worth it.

M.D.

I have written a number of packages, some with more than 2000 lines, using modules exclusively. Since modules (and therefore packages) can contain other modules I find I can create just about any structure I want using this approach.

For example, I wrote and maintain a simulator for a certain feedback process. The main loop reads data, calculates a response and sets an actuator. The input and output devices are all coded as modules inside a package. Each module then has procedures and variables (properties) as needed to implement the functionality needed. In addition there are local procedures (hidden from the outside caller) and variables to implement and control certain operations needed in more than one place. Conceptually the main program looks like this (the package is called IPSim):

with(IPSim);

IPSim:-Init(parameters);

do while running

  IPSim:-LockInAmplifier:-Read(...); # get data

  <do some calculations>

  IPSim:-Orbit:-Move(...); # set the actuator

   <more calculations>

  IPSim:-Dither:-Set(...); # change a parameter of the loop

  IPSim:-LockInAmplifier:-Set(...); # change parameters of the readout system

end do;

This is vastly simplified; the point is to illustrate that modules allow a highly structured approach to programming in Maple. I don't know what you want to do, but I would think modules and submodules should allow you to structure your code to your liking. Note that in principle a package can pull in others by means of the "using"  construct although I tend to prefer using the long form in my packages to avoid polluting the name space.

The Maple Programming Guide has the necessary info and is esssential to learn how to do this.

Joe Riel makes the point to keep such code in separate text files. I do this as well (and I use his maplev Emacs mode), and for large packages this is the way to go. But that is a separate issue having more to do with limits of the Maple GUI as a programming environment than with the structure of your code as the whole package has to be within one execution group. For such projects I use a small Maple worksheet to read in the code and create and store the .mla file where Maple can find it (this sheet is then run each time I update the package code).

I hope this helps,

Mac Dude

So, if you initialize P by an assignment

P:=10;

then Maple will evaluate P to 10 whenever it sees it. You can use uneval quotes (single quote) to prevent this at one step; Maple removes the quote pair at the first evaluation so you may need more than one pair of uneval quotes.

It isn't fully clear whether this helps you, however. In essence, you have the same situation as if you had not initialized (assigned) P. If your system is solvable without assigning a (numeric) value to P then you are all set: just defer the assignment to P until after the system is solved. Alternatively, eval the solution at the point P=10:

eval(expression,P=10);

If your system is solvable only with P being assigned to, then I do not see how Maple could do what you have in mind: in order to solve P needs to be assigned at which point P no longer exists (having been replaced by the number 10).

Maybe the solution can only be found for P in a range of values? Try "assuming", e.g.:

dsolve(...) assuming P>0;

I have never tried assuming with solve so I do not know whether it works there.

But maybe I am missing something here...?

Mac Dude