I have seen something like this whan for some reason the kernel attached to a worksheet died and I tried to contitnue using the sheet. But upon the loss (e.g. crash) of a kernel usually Maple puts up a message so you can save the worksheet and then quit and reload Maple.

What I have always missed is the ability to start a new kernel for an existing and open worksheet i.e. avoid having to shut down the Maple front-end. I have sometimes half-a-dozen worksheets open, so that hurts. The overall architecture (separate graphical front-end and kernel) surely could support that approach. 

I have also had the front-end itself lock-up on me. That is really aggravating.

M.D.

In the mid 2010s I used Maple to teach a course in Accelerator Physics. I structured it into a series of about 13 Maple workbooks (i.e. large worksheets) that combined narrative with the algebraic treatment. Essentially an electronic textbook. I do recall that preparation of the course was quite a lot of work; not only had I to bring the material into a suitable form but also wrestle with Maple to be able to present it in a decent way. We printed the workbooks (a total of about 150 pages) so they could scribble in it, but they also got the actual worksheets. These students were mostly grad. students and accelerator operators, i.e. a somewhat more mature audience that overall was quite motivated, which clearly helps. And the ability to produce graphs of even complex relationships clearly is powerful.

An unexpected benefit was for myself: Whenever I have to look up something I can use my Maple worksheets and get formulas I can use directly.

My take-away was that using something like Maple as a teaching tool is worthwhile for students and teacher, but that preparation is not a trivial matter and probably more complex than doing it the old-fashioned way. And it is important to be well versed in the technicalities to avoid losing time for technical (computer-) problems. I did a half-a-day intro to  Maple, how to use it and some of the pitfalls.

I suggest you decide what it is you actually want to do or solve and ask specific questions about that. Even better: Read up on what you want, try something yourself and ask when you get stuck.

And, please mention your operating system, which makes a difference.

M.D.

@Ronan The print statement, which prints upon the with(...) statement in the calling sheet, has the version number of the package and the date when I created the .mpl file (and both are updated by hand, there is no magic here). So when something is funky I know immediately if I am loading the intended version and "built". I am quite certain that it will print the value of a variable if so desired.

Listing settable globals is an interesting question. Personally I do not use globals; I like having the variables in my modules and procs isolated. In Maple, variables declared in a module are known in its procs and submodules unless they are overridden; I have yet to run into a situation where that was not enough. Occasionally I use setter routines to set certain variables needed in a module.

I assume you would like a general method that finds all globals and lists them; I do not know if that is possible. "type()" will test a given name for globalness, but then you'd need to find a way to run all variable names through it. You might be able to avoid using globals by allowing assignment to exported variable names. They have to be unprotected for that to work. These of course show up on the list printed upon loading the module.

M.D.

@mvms271091 While indeed, if you evaluate f at x=3 you get 0/0, this is not a true discontinuity since you can extract a factor of x-3 from both the numerator and the denominator. The limit for (x-3)/(x-3) for x -> 3 is 1 (and is valid and the same from both left and right), so this is legal and correct to do.

Hence the discontinuity is not a true discontinuity, I think it is actually called a removable discontinuity.

For me (Maple 2015) the simplify gives

Why do you think this requires a non-zero denominator (apart from the fact that it diverges towards infinity for x -> 0)? Note that the asymptotes are the same for both expressions also, as they must be.

Although, asympt(f) gives

which at least in my book is not a proper asymptote (it is just the expanded simplified expression). In this case the asymptote is x+3 which—besides being obvious—can easily be verified with limit().

AFAIK there are no "default assumptions". In general an undefined variable is not even assumed to be real but can be complex also.

M.D.

edited to add the sentence about the asymptote.

I "fixed" some of the more egregious errors so the sheet actually runs. You do need a second meaningful initial condition, however, to plot the result.

Edited file attached.

M.D.

eval.mw

You are not giving an example, but in general you can get at the terms of an expression using op(index,expr) where expr is your expression and index denotes the parts. E.g. if your expression is a sum of terms, op() will allow you to print the individual terms one-by-one. You can intersperse text blocks to describe the salient points. Use e.g. expand() to cast the expressions into useable form.

Post an example and we can demonstrate how to do this.

M.D.

You do have a typo in your call to Quadrature: you integrate over eta[4], which should be eta[2].

That does not fix it, though. The issue is the integration over zeta[2]. I do notice that for me (Maple 2015) the plot looks somewhat different:

Maybe that is a hint?

M.D.

@Lali_miani Note that in your example f:=n->n/n+1 is f:=n->1+1 = 2 for all n<>0. Presumably you meant f:=n->n/(n+1)

M.D.

@acer, @Christian Wolinski Thanks to both of you.

I learned 2 things:

First, content(), which I have never come across in over 10 years of using Maple. Here it is the key to extracting the 1/1296 factor.

Second: the way you both use what appears to be an unnamed function to apply the inert muliplication to the original expression divided by the 1/1296 factor. Quite slick.

@acer wins by a small margin as his second solution is robust against the typesetting level whereas his first one and @Christian Wolinski's only really work for one of the two.

Thanks much

M.D.

@Preben Alsholm 

@Preben Alsholm  I just edited my reply, since I traced my problem back to the old UsehardwareFloats issue. I confused myself since I work both at home and in the lab on somewhat different setups...

But for illustration, here is what I observe. Note that it uses routines from a package I wrote.

evalf(P0__SR__source:-value(4.75854402042301)); # this works fine
                       -0.943964252157448

fsolve(evalf(P0__SR__source:-value(tt)),tt=4.75); # while technically correct the result is not what I want
                               0.

plot(evalf(P0__SR__source:-value(tt)),tt=(4.75-0.000001)..(4.75+0.000002)); # see plot below

fsolve(evalf(P0__SR__source:-value(tt)),tt=(4.75-0.000001)..(4.75+0.000002)); # trying to trick it... returns unevaluated.
fsolve(sin(6.28318530717958 Typesetting:-msubsup(

  Typesetting:-mstyle(int, mathcolor = "#909090"), 0., tt)

  (289163.632468524 - 0.000771604938271605 RfFreqApplyFunction(ti

  )) Typesetting:-mstyle(DifferentialD, mathcolor = "#909090")ti), 

  tt, 4.749999 .. 4.750002)

MaplePrimes is too fouled up to show the plot else I could show the zeros I am interested in, that are spaced by O(1e-6) about 4.75.

Thanks,

M.D.

Well, I spoke too soon. It appears that fsolve is broken, or at least behaving differently than what I am used to (and my main version of Maple has been 2015 since I had too many issues with the later ones).

The specific use case is a strongly oscillating function (a sine with some high-ish frequency) where I need to pick a specific zero crossing, which I do by giving fsolve a reasonably close initial estimate. That works fine in 2015. In 2022 it returns 0 for all my cases, which is correct but not the zero I want. So it appears fsolve is jumping ahead or back way too aggressively.

I am sure this can be prevented by using intervals and the avoid option, but it seems like a step back. Now, a comment in the Help for fsolve says it got updated in Maple 2018, so maybe that is where the problem arose.

I guess I am a little less excited now. This situation is in a part of code I am using daily right now and cannot afford not to work.

Edit: It turns out this is the old issue in fsolve when using "Usehardwarefloats:=true" (instead of the default "deduced"). So maybe it is not a new problem, although having such a bug hanging around for this long is unsettling in itself.

@nm It is kind-of off-topic, but couldn't you use the GUI components (which can update in place) to get your output per iteration of your loop(s)? Having to clean-up a worksheet manually every-so-often seems kind-of old to me, even if done while the loop is running (which does seem feasible given that the GUI runs as a separate process).

Personally, I keep all output I need from loops in the appropriate data structures for later inspection. Longer loops update a progress gauge so I can be assured things are still running.

As I say, not pertinent to the Maple 2022 release, which I just installed. At first glance it seems to run fine (which I could not say for some of the earlier 202x versions). I am actually looking forward to using it.

M.D.

@AHSAN My aologies, but I do not have time to do this, you will have to put the effort in yourself. Presumably you know what the code is doing so as you convert the statements you can verify they do the expected thing.

M.D.