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.

How's this?

Mat_1_-_Noter_adc.mw

I don't know how to prevent it with any guarantee. It seems to be related to entering typeset Vectors/Matrices in 2D Input mode (via the Matrix palette?).

In the distant past there were hints that older issues were related to inlining images into Documents.

I gave this Question the "units" tag late last night, but didn't have time to answer.

(In my Maple 2022.2 it is not necessary to put a lowercase typeset call around the axis labels, with default settings.)

With units the kg/m^3 is rendered in upright Roman instead of italics, by default. (As Tom showed.) But it's not mecessary to load the Units package in order to do that.

A short re-usable procedure is one relatively easy way to make other non-unit names get rendered in upright Roman in a plot's axis labels.

Download roman_label_ex.mw

Did you set numeric formatting for that Document Block? If so, you could try right-clicking in that border element and clearing any formatting.

Or, if you wish to retain the formatting but not see any markers, then from the GUI's main menubar, uncheck the "Markers" box under the "View" item. 

See Help topic worksheet/reference/markers .