Mac Dude

1531 Reputation

17 Badges

10 years, 342 days

MaplePrimes Activity

These are replies submitted by Mac Dude

@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.


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.


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.


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?


@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)


@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


@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

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

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.



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.


@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.


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.


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]
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.


@nm To close the loop here: You can mimic type extension by, in module dog, setting it manually:


     return module()
       export data1:=Animal:-data1;

       export move:=proc(_self,$)
         print("In dog class. moving ....");
         print("data1 = ",data1,"  data2 = ",data2);
       end proc; 

    end module;

  end proc;

Now both Animal:-data1 and Buster:-data1 evaluate to whatever Animal:-data1 is set to. But I don't think you can set Buster:-data1 to something and expect Animal:-data1 to follow since assigning something to Buster:-data1 will break the linkage. So it is a one-way mechanism.


@nm I agree with most of what you say, except I would not say returns "just" a module. In fact I cousider the ability of treating procs and modules in the way Maple does it (where they can be handled just like any other data structure) quite cool and useful.

Members of a module do have access to the data structures (or procs, or whatever) of the parent module (Animal in this case), via the lexical scoping mechanism in Maple. I don't have time right now to construct a MWE (work beckons), but I do this all the time (if maybe not in a true OO fashion). It does require some amount of manual work, however. As we agreed, Maple is not an OO language...


1 2 3 4 5 6 7 Last Page 1 of 42