@Zeineb The iteration count is not a meaningful stopping criterion for Newton's method, so why are you fixated on the sixth iteration in particular? The only reason to impose a limitation on the iteration count is to prevent infinite loops. The meaningful stopping criteria are any combination of

1. relative: abs((x[n] - x[n-1])/x[n]) < tolerance
2. absolute: abs(x[n] - x[n-1]) < tolerance
3. residual (aka function value): abs(f(x[n])) < tolerance

(In particular, I like if crit_3 and (crit_1 or (abs(x[n]) < tolerance and crit_2)) then return x[n] fi.) The above could be done with a different value of tolerance used for each criterion.

Your particular equation has a unique real solution 19.75...; anything different than that is worthless as a solution.

@Pepini You can't directly contourplot a complex-valued function. But you could replace the eval in eval(f(z)) with any of abs, argument, Re, Im, etc.

And, your use of eval does nothing (neither good nor bad) since f(z) is already fully evaluated. In acer's code it was eval(f). That does something because the name of a procedure, f, is not fully evaluated.

I recall that this Question had several responses, including contributions from @acer and @Joe Riel. What happened to them?

An inverse Laplace transform can also be calculated directly by integration. This is a very straightforward and totally formulaic approach. However, the integral can be difficult. In this particular case, Maple has no trouble with it. In the code below, r can be chosen to be any real number that's greater than the real parts of all the roots of the denominator of the transform. Naturally, since 0 is such a real number in this case, that's what I chose.

F:= s-> 1/(s^2+8*s+20):
fsolve(denom(F(s)), complex);
       -4.000000000 - 2.000000000 I, -4. + 2.000000000 I

r:= 0:
evalc(int(exp(s*t)*F(s), s= r-I*infinity..r+I*infinity)/2/Pi/I)
    assuming t>0;
                      1                   
                      - exp(-4 t) sin(2 t)
                      2                   

Another way of calculating this and other complex integrals is

evalc(add(residue~(exp(s*t)*F(s), s=~ [-4-2*I, -4+2*I])))

which produces the same result as the other methods.

@dharr You just posted 2 almost identical Answers. Please delete one of them.

@Pepini Yes, almost anywhere in Maple an entire "container" (list, set, array, table) of input values to a function can be placed syntactically as if it were a single input by using slight adjustments to the syntax that involve ~. This is called elementwise operation (see help page ?elementwise).

Suppose that f is any function of 2 real arguments producing a value in interval 0..1, and, as above, data is a list of 2-lists of real values. Then the color option could be

color= COLOR~(HUE, (f@op)~(data))

Or suppose that g is any function of a single complex argument producing a value in 0..1 and data is as above. Then the color option could be

color= COLOR~(HUE, (g@Complex@op)~(data))

In the above Answer, I effectively used g:= z-> .5 - argument(-z^2)/(2*Pi) without explicitly defining g. The .5 and 2*Pi are to rescale the output to interval 0..1.

​​​​​​

@agh314 The primary errors are the result of memory not being shared. Any variables that you've defined or structures that you've created (other than those in list) prior to calling Grid:-Map that might be needed by Query need to be sent to the remote processes by using Grid:-Set. I don't know DifferentialGeometry, so I don't know what a "defined frame" is, but I suppose that you do. Perhaps alg1 is a defined frame. So do

Grid:-Set(alg1) 

before Grid:-Map.

The error "invalid input: op expects 1 or 2 arguments, but received 0" is simply the result of there being no output to return due to the primary errors.

When you used Threads for this, are you sure that the results were correct? And did they truly run in parallel rather than locking each other out? What was the total CPU utilization (which you can check with Windows Task Manager or similar tools on other OSs)?

Since list is very small, you should use Grid:-Map[tasksize= 1](x-> ...)

If you do a numeric integration of an integrand that contains a symbolic variable (h in this case) other than the variable of integration, then what form of result are you hoping to get? I do not mean this as a rhetorical question; I literally want to know.

You should reduce the value of M to 3 or 5, reduce Digits to 15, and run the code with the output-suppressing colons replaced by semicolons so that you can get some appreciation of the enormity of the expressions involved. And they'll be much larger still when M=50.

@Muhammad Usman Some response to my Answer would be appreciated.

@noecb2002 Thanks for the plaintext ODE. Using it, I have no trouble solving your IVP with standard dsolve options and no adjustment needed for the trunc (after I provided initial conditions that I made up). But I suspect that you may be trying to use one of the more complicated methods, perhaps lsode[backfull]. In order to have any chance of duplicating your error message, I need plaintext of your initial conditions AB and options dsolve_options. So please post the plaintext output of lprint([AB]) and lprint(eval([dsolve_options])).

@chrisc I didn't deny that it was a bug; I said that it should be corrected. But given that x::complex is Maple's default assumption anyway, it's worth being more careful with expressions such as abs(1,x) that don't even make sense (at least to me) when x is nonreal.

Please post the expression Lagerkraft in plaintext form so that we can copy and paste it. The command lprint(Lagerkraft) will present it in plaintext form.

I suspect that the problem is the trunc. If that's the case, you may be able to fix the problem by giving the command

`diff/trunc`:= 0;

before the dsolve. (Note that diff(trunc(x), x) = 0 is true almost everywhere as they say in Real Analysis (meaning that the set of x for which it is not true is infinitesimally small (technically, measure zero)), so just making it 0 should be good enough for a numeric dsolve solution (which is, after all, a form of integration, so what happens on a set of measure zero doesn't change the result).)

To achieve the results from your linked video, change the projection from the plane to the sphere to

P__pl_to_sph:= (r, theta)-> (theta, 2*arctan(2/r))

And change the sphere's color function to

Color__sph:= (psi, phi)-> COLOR(HSV, (1+sin(phi)*cos(psi))/2, 1, 1)

or

Color__sph:= (psi, phi)-> COLOR(HUE, (1+sin(phi)*cos(psi))/2)

Everything else can remain the same. Let me know if this is the plot that you want:

I needed to use Maple 2020 instead of Maple 2021 to post the plot.
 

@Earl Thank you. I've added a few details to the Answer above, and I did a lot of clarifying of the typography, so please reread it carefully (and probably several times).

I just watched the video on Mobius transforms that you linked. I can see that the projection that I used is different from that used in the video. And, of course, the coloring function is different. Both of these details can be changed simply by changing the projection function and the coloring function in the code. No change is needed to the expository text or the algebraic/functional framework that it lays out.

The projection from the sphere to the plane that I used gives the point on the plane where it is intersected by a line tangent to the sphere at the preimage point. To get the projection from the plane to the sphere, I simply inverted that function algebraically (which is trivial in the coordinate systems that I used). However, in the video, the projection from the plane to the sphere is where the line connecting the plane's preimage point to [0, 0, 1] intersects the sphere. This line goes through the sphere rather than being tangent to it.

I'm doing that algebra now.

I have two questions about your system:

• Why do you say it's nonlinear?
• Do you think that it's possible to solve it without specifying f, alpha, omega, and x__||(1..4)||0?