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.

Please upload your program & data using the green arrow in the editor toolbar.

In general, a fitting procedure can find parameters for a given fitting function (the model you want to validate in a statistical sense). In general a fitter cannot generate the functional form most appropriate (statistically) to describe your data. It can only give guidance (using the Chi-squared criterion) as to which function out of a number of trial functions may be the best.

M.D.

Somewhere in the middle of that long thread @Carl Love  wrote this:

SumList:= proc(L::list)
local S:= 0, i;
    for i to nops(L) do
        S:= S + L[i]
    od;
    S
end proc;

Here S is the variable that the elements of the list L get summed up in. i is the index that addresses each element in the list L when the loop executes. S and i are declared local to SumList so they are not visible outside SumList. S is initialized to 0.

In the for loop, i begins at 1, this is a Maple default when the beginning value is not given. nops(L) is one way in Maple to get the number of elements in the list.

The single S before end proc causes S to be returned to the caller. Again, that is a feature of Maple.

This fulfills your assignment.

M.D.