@C_R As you've seen, one aspect of your original approach is that f(x__0) gets evaluated with x__0 being a mere name. In this case you encountered problems with that.

That aspect is sometimes called "premature evaluation", with a problem ensuing because procedure f is not handling a mere name as you'd prefer. The aspect is that procedure f is being called before its argument gets an actual numeric value.

Previously you were given some ways in which the root-finding could be accomplished (using Maple 2021 at the time).

Your procedure f was defined as,
   f := x__0 -> int(1/sqrt(sin(x__0) - sin(x)), x = 0 .. x__0)

Note that for,
    fsolve(f(x__0) = 2*sqrt(alpha), x__0 = 0 .. 0.9*Pi/2)
the call f(x__0) for x__0 a mere name occurs before fsolve ever receives any arguments. The call f(x__0) is being evaluated prematurely.

In my Maple 2023.0 the approach of delaying the evaluation of f(x__0) does succeed, ie,
    g := alpha -> fsolve('f(x__0) = 2*sqrt(alpha)', x__0 = 0 .. Pi*1/2*0.9):
    g(0.6336176953);
produces the answer 0.5614162053. It is slow, taking about 75 seconds, because the numeric integrations are not fast.

For me, it doesn't take "forever". But it's slow. It's slow because the way in which the numeric integrations are requested makes them slow (not because fsolve itself is slow).

You had used a so-called operator calling sequence in a call to plot. That's another way to avoid the call f(x__0) for x__0 a name. A similar approach for fsolve can also avoid the premature evaluation. This too takes about 75 seconds for me.
   g := alpha -> fsolve(f - 2*sqrt(alpha), 0 .. Pi*1/2*0.9):
   g(0.6336176953);

At the risk of being irritating, I'll mention that (as shown before), with a bit of care using numeric integration can do well here. Here's a slightly different tweak that I showed before (which was a coarser error tolerance with a slightly higher working precision).
    f := x__0 -> int(1/sqrt(sin(x__0) - sin(x)), x = 0 .. x__0, method = _d01ajc):
    g := alpha -> fsolve(f - 2*sqrt(alpha), 0 .. Pi*1/2*0.9):
    g(0.6336176953);
That produces the answer 0.5614162054 in less that one second, for me.

As Preben has shown, the integral can be solved symbolically under assumptions and a procedure formed from the result using unapply. Previously I too had shown a symbolic integration under assumptions, using Maple 2021 and a change of variables, followed by unapply. The ensuing fsolve attempt is very fast. As you've seen, cases that do not do well here include that in which the integration is attempted symbolically but without the key assumptions.

The most notable aspect of your worksheet is that you have formed the equation (1) before you assign values with units to the parameters. You don't have to do it that way, but I will retain that approach because it's key to some of the things you've noticed.

Download units_after.mw

If the Units (or Units:-Simple, or Units:-Standard) package is loaded then the arithmetic operators `+` and `*` are rebound to package exports of the same names, which are units-aware.

The reason why it works directly if you "retype" the input (after assigning values with units to the parameters) is that the input gets parsed using those units-aware versions.

But your original equation (1) is formed before the parameters have values with units. And so the resulting expression contains calls to the original global (units-unaware) arithmetic operators. Mere re-evaluation does not reparse, or re-utilize the rebound units-aware versions, even after the parameters are assigned values with units.

It is unfortunate that Units:-Simple:-simplify is inadequate here, taking longer and not getting the desired result. I will submit a bug report against that aspect. But combine(...,units) or the global :-simplify do fine.

Based on your description, you might consider line-printing, eg.

Download lineprint_ex1.mw

Your complete requirements are not clear, based only on your original Question. Is a fixed width font wanted? Could your "output" contain non-ASCII characters? Does all whitespace need to be removed? What did you mean by the trailing "/", if something other than the linebreaks? Etc.

This might be as much as I can recover, while also being able to reliably Save&Reopen using Maple 2022.2. (I noticed that your original attachment was last saved in Maple 2022.2.)

Opgaver_til_ULA_13_addition_af_spin_ac22.mw

I suggest that your save a copy of this, on the side as a backup, for now.

Is this what you're after?

L := [a,b,c,d];
foldl(`&^`, L[]);

In a worksheet,

Download foldl_ex1.mw

Since the eigenvectors of a nonsymmetric Matrix with floating-point entries could be nonreal in general, the data structures used for the eigenvalue and eigenvectors results are consistently a Vector and Matrix with datatype=complex[8] (at hardware working precision, and complex(sfloat) at higher working precision), regardless of whether the values are mixed real/nonreal or all purely real.

In such a case as yours, you are free to cast the results to a float[8] or other Vector and Matrix. See below.

Alternatively, you can change a kernelopts setting so that the visual display of the zero-imaginary components are suppressed for such Vectors/Matrices.

Download Eigenvectors_ac.mw

For this example you could perform simplification after substituting your example numeric values, and in this case avoid the small imaginary artefact due to floating-point round-off error.

For this example this also happens to lead to better accuracy that applying evalf without that simplification (even after removal of the spurious imaginary artefact).

Download ztrans_ex1.mw

Your attempt at procedure df is calling diff(f(x),x) where x has a numeric value. That does not make sense.

Also, your loop will not terminate if the process is not converging to a root (because of the choice of initial x0).

Here is an adjustment that computes the derivative more properly, and which also terminates the loop after a maximum numer of iterations. It also uses evalf in a few key places to help ensure that the computations are done in floating-point even if x0 is numeric but not a float (eg. an exact rational).

I haven't changed your overall process, mostly because I suppose that this is coursework and that you are supposed to figure out and refine the approach. Perhaps it would be better if you could repeat the process at other initial x0 choices. Putting the code into a reusable procedure could make it easier for you to try that.

Download rf0.mw

By splitting up the surface we can arrive at a nicer result. Not only is the gap narrower here, but the jaggedness along the top and bottom boundaries has cleared up.

Unfortunately this is tricky to do programmatically in general.

The gap gets smaller if you increase the resolution (eg. grid=[200,200]), and the overall appearance looks quite nice with style=surface to suppress the grid-lines.

Download plot3d_ridge.mw

There are other ways to accomplish something similar. (You could even get the gap to vanish altogether...) This is simply the first thing I considered.

You are passing an equation,
    C_prev = -0.7676394482e16
to SFloatMantissa and SFloatExponent. That's why those two commands are returning their very same argument, unchanged.

This behaviour is documented in the very first bullet point of the Desciption section of the relevant Help page.

Try passing the actual floating-point value instead of that equation.

C_prev_V := eval(C_prev, it[1]);

                              15
   C_prev_V := -7.676394482 10  

SFloatMantissa(C_prev_V);

        -7676394482

SFloatExponent(C_prev_V);

             6

Or, in full,

Download SFloatMantissa.mw

Confirmed with,

   restart;
   int((b*g*x+a*g)^2/(A+B*ln(e*(b*x+a)/(d*x+c))),x):

using Maple 2023.0.

It appears to be occurring here, where an argument to Utils:-Userinfo:-PrintInfo is wrapped in print (instead of, say, sprintf).

   showstat(IntegrationTools:-Indefinite:-Stage2,25);

This is just an idea I saw elsewhere; I'll have to wait and see if it makes a difference.

I have toggled off "Enable MapleCloud connection" in the popup dialogue,
     Tools -> Options - Network

Elementwise mapping of DrawGraph works fine for me, over CubicVT a table of graphs. The result will, naturally, also be a table.

tablemap_ac.mw

I elected to convert that resulting table to a list, after which there are several easy ways to plot them together.

Your attachment seems to have unevaluated Graph calls in it, making it suspicious whether GraphTheory really was loaded before such construction attempted. (Orphaned output, and a lack of restart, are additional small hints of a possible lack of care about programmatic flow...)

If I were to do it programmatically then I might start with something more like the following, which I think is a little less opaque,

Download shiftsum.mw

Of course, one could also add type-checks, eg. ensuring that S is of type {Sum,sum}, that op(2,S) is of type name=range, etc.

You are passing a flat sequence of eight arguments, after s.

It doesn't magically read your mind and know that you intended it to take successive pairs from that flat sequence of eight things. You could see that by changing SubstituteAll to a dummy name like, say, SA.

How about using four lists (of pairs), and having a custom iterator take the operands from its second argument, before it calls SubstituteAll.

  foldl( (a, b)->SubstituteAll( a, b[] ), s, seq( [L1[i], L2[i]], i=1..4 ) );

Eg,

Download foldl_ex.mw

ps. I find that much more legible than a mixture of extra unevaluation quotes and eval calls.