@Leinad evalc stands for "eval complex" (as you might have guessed). It is needed when you want functions like abs and argument to actually do what you expect, but it is also needed for the Re and Im functions to evaluate as expected. By itself, evalc tries to put a complex expression in canonical form (a+I*b) with the other variables all considered real.

While we are at it: evalf stands for "eval floating point" and is used to convert all numeric constants to floats and combine them as much as possible. This includes things like evaluating functions which may return unevaluated if no rational solution exists for a specific set of arguments (e.g. cos(1) won't evaluate, evalf(cos(1)) will). Handy when you ultimately want to do numerics.

eval in itself forces evaluation of its argument if possible. Sometimes needed when certain kinds of table constructs are used (the ones with "last name evaluation", i.e. tables, procedures and Records and maybe a few more). But eval also allows evaluation at a certain point (eval(xpr,x=1)) and to control the depth of evaluation (which in itself is a recursive process). RTFM.

Keep at it and read the manual (Help) on these. It is worth it and important to unlock Maple's power.

Mac Dude

@JohnS Thanks much, it works for me as well. I seem to get hung up always at the trivial issues...

M.D.

@Preben Alsholm In addition, if you use the tilde on an operation or function that in itself uses lists for its arguments you can run into an error saying in effect: "Element wise operations only work with equal lengths of the objects involved". This indicates that the tilde operator can get confused as to exactly which element lists it is supposed to map over. map on the other hand has no such issue. So I second and wish to amplify your opinion: map is not at all obsolete.

OTOH, the tilde many cases is a welcome short cut to map a function over a list or Vector and I use it all the time for that. Actually, I believe in newer Maple versions (17 and newer?) many functions already map over elements on their own, reducing the need for the tilde.

Mac Dude

@maple2015 Here is your first line (the one using curve) back. As you see I replaced your PLOT with plots:-display and added a label. plots:-display puts the plot structure onto the screen, which in practice means you can wrap it around almost any plotting command and add options the plotting command you use does not know how to process. In addition, plots:-display accepts a list of plot structures and thus put several curves onto one graph. It is a very versatile command that is well worth studying in depth (perusing its Help file).

SN := curve([[3, (4.566256-4.544647)/(4.544647)], [4, (4.544933-4.544647)/(4.544647)], [5, (4.544653-4.544647)/(4.544647)], [6, (4.544649-4.544647)/(4.544647)], [7, 0]]): plots:-display(SN,axis[2]=[mode=log],labels=['x','y']);

Since you are using log plots there is one word of warning here: I found out just the other day that an old bug with log plots has surfaced again in Maple 2015: if you plots:-display a log plot it sometimes shows up linear only, independent where (and how often) you specify mode=log for the axis you want logarithmically. Jeez, Maplesoft, wtf??? Anyway, a possible solution is to use plots:-setoptions(axis[2]=[mode=log]) before the plotting commands. Experiment, it does not always work for me either.

@acer Thanks, I already did so but two is better than one!

M.D.

@acer and Tom:

Thanks for your comments. As acer noticed I have a .mapleinit file and the culprit was that I set UseHardwareFloats:=true; (meaning I force Maple to use fpp hardware). Setting UseHardwareFloats to deduced (i.e. making it optional) allows the solve command to proceed.

Having said this, my Maple 17 installation uses the same .mapleinit file (literally) and there I do not have this problem. So I do consider this a bug/regression and will file an SPR.

Thanks,

M.D.

Edit: it is UseHardwareFloats:=true; (not "yes")

I ran your code for n=10^4 and 10^5. In both cases the status line gives 33.93 MB used once the loop is done (and in fact during the whole run once it settled). Activity Monitor gives 40 MB real memory . No sign of memory increase with n.

That you get more memory used than me at n=10^4 could be because I run a 32 bit version whereas you likely have a 64 bit version. I am not close enough to my desktop right now to try my 64-bit version.

Also, I start the worksheet with restart; Try that; it might make a difference.

Again, note that I used my old Maple 15 (vintage 2011) for this test. Should it be a difference between versions it would be a regression, and a bad one at that. So far I have not seen such a regression in my daily work with Maple2015, which is not a proof that it does not exist.

Mac Dude

PS: Mac OS X 10.5.8, PowerPC

@Preben Alsholm Preben, thanks very much. I wrote an SCR on this. It is very annoying as I am planning to use the sheet that has this issue in a teaching environment in less than two weeks...

Mac Dude

You have not provided enough details.

From what you posted, I'd be much more conserned about solvability in general as opposed to speed and efficiency. You say that each additional equation is about twice as long as the previous one. This sounds like exponential growth; not a good situation esp. when you have an "unlimited number of equations". Then, is each eq. adding independent parameters to solve for? How do you ensure you have enough equations and parameters for a solution to exist?

Also, presumably the polynomials get to higher and higher order. Beyond order 5, there is no general algorithm to solve polynomial equations, although there are important subclasses that can be solved and in my experience Maple is not too bad in  identifying those.

Your question about equations not independent of the others bothers me. If your system is overdetermined a solution may not exist. You need to check for that first. I do not know whether commands like eliminate() are powerful enough to help with that check as I have not used them (rtfm and experiment to find out what eliminate can and cannot do)...

You may be able to make progress by using a least-squares approach, i.e. you will find the "best" approximative solution (in the least-squares sense) in the absence of an exact one. Maple's minimization routines likely can help with that.

Obviously these are generalities. A better definition of the problem seems in order.

Mac Dude

@acer You say that input shows up partially in blue, i.e. like output? While I have in some cases input that is formatted like output (e.g. mu shows as µ etc.), whereas in other cases the input is not quite formatted like output (e.g. mu stays mu, but fractions still are typeset as 2-d fractions) I have never ever had it turn blue (and that is mostly up to Maple 17; I am only now starting to use Maple 2015).

Anyway; my first order of the day is to get this sheet working again. How did it get into this state? I do not really know. It originated actually as a Maple 15 sheet and was worked on in 17 as well. I then recently added the first subsection (The Hamiltonian of a particle...) to it; and at some time I realized that the other parts had gotten into this funky state. Since recalculating the whole sheet does not scroll properly I did not see when this happened because I did not look that far ahead. I did not work on it in Maple 2015 so I do not see this as a Maple 2015 problem although Maple 2015 does not show the input lines either (behaves identical to the older versions).

One possible way it got messed up may be that I tried to put some code >after< the first subsection ends but >before< the second subsection (Linear Motion...) starts (specifically the H:='H' deassignment)...??? That code did not seem to be executed at all.

Of course, I would like also to find out how to fix this in general if/when it happens again. For this sheet, most likely I will copy-paste from a backup version that has the offending oparts working correctly.

Anyway, thanks, and enjoy the holidays.

M.D.

I suggest you try this out with a small subset so you are not waiting endlessly for each action in the GUI due to the many numbers in your sheet. As it is it is not useable at least for me. Each action takes a long time (in the GUI). For the full data set I suggest you put it into a file and use somethng like ImportMatrix to read it in.

Another hint: you do not need to use NonlinearFit, your problem is linear (in the coefficients) so LinearFit is the method of choice (and will be much faster).

I glanced from the sheet that the NonlinearFit command seems not to be recognized (it returned unevaluated). It is possible that the load of Statistics failed for some reason.

Again, make it small enough so you can actually work with this thing.

M.D.

@acer I tried the Group and Block Management:Expand Document Block, but no joy. If I select a whole section, all selections are grayed out; if I only select one Document Block, then I get the "output redirected..." line but no input.

I am uploading the document here; I thought this was a trivial little thing I just wasn't aware of, but maybe it is more involved.

Thanks much,

M.D.

2b_Hamiltonian_(Worksheet_6)_2016.mw

@Preben Alsholm Oops, yes, Physics[Vectors] is not needed or used for this part. The original is in a document-mode sheet in 2-d input and looks just fine, but Physics[Vectors] overloads many Maple operators which can lead to very messy input lines esp. when copying 2-d input into a 1-d input sheet.

I am presently doing this in good-old Maple 15. So maybe CompleteSquare has changed a little... will check in 2015 (different computer).

Thanks,

M.D.

Edit: Checked in Maple2015: yes, it behaves differently than Maple 15 does. It outputs the same as my mtaylor statement (which is what Preben found also).

@Preben Alsholm Interesting; I guess I need to look at the Student package more often...

It does actually not quite get there: The result is

Simplifying the 2nd term (using applyop) is not quite as straightforward as on might like, but possible. For once, I really want it to look like the result I show in my o.p. to remain consistent with standard usage in my field.

Thanks much,

M.D.

@JohnS Wow, long one. It certainly seems relevant; I'll study it carefully,

Thanks,

M.D.