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 .

As a tip for future queries,

> MmaTranslator:-FromMma("Hypergeometric0F1Regularized[a, z]");

        hypergeom([], [a], z)
        ---------------------
              GAMMA(a)

> lprint(%);

hypergeom([],[a],z)/GAMMA(a)

How's this?

C_Users_jonas_OneDrive_Skrivebord_Mat_B-A_Hjemmeopgavesæt_Opgavesæt_1115_MAS_-_Kopi_ac.mw

You have used Maple 2021, and 2D Input.

In that case you can use the prefix form of the inert `%.` operator.

Also, to get it to display in infix notation as output, you'd need to utilize the extended typesetting level. (In that case the "dot" appears in gray.)

You can use InertForm:-Display to show the "dot" in black, instead of gray.

And you can use the value command to make the inert call active.

Download inert_matrix_products_M2021.mw

@abert Preben's procedure returns the name of its local z. That is sometimes called an escaped local.

Download escaped_local.mw

As Christian mentioned, the means by which your procedure f evaluates that name z is the same means as for your procedure h, ie. because in both cases the unevaluated name was passed in as the argument.

You mentioned "lexical scope".  Consider the following contrasting example, in which procedure g gets a value for z via lexical scoping. Perhaps you were thinking of something like this, when you wrote of your procedure g, "After all, its definition is within the lexical scope of z."

Download lexical_ex.mw

Note. op(7,eval(g)) is the lexical table of the procedure assigned to g, as mentioned on the Help page for topic proc.

Your original example's procedure g, however, has an empty lexical table, and does not get a value for z via lexical scoping. It gets it because the reference was actually passed.

Fwiw, illustrating six free variables, and all integer solutions:

[k[6] = 22*k[1]-3*k[2]-k[3]-4*k[4]+4*k[5]+3*k[10],
 k[7] = -5*k[1]+k[2]+2*k[3]+10*k[4]-k[5]-k[10],
 k[8] = -14*k[1]+k[2]-k[3]-3*k[4]-3*k[5]+k[10],
 k[9] = -4*k[1]-k[3]-4*k[4]-k[5]-4*k[10]]

That can be had by,

simplify(combine(solve(evalc(convert(eqs,radical)),
                {k[6],k[7],k[8],k[9]}))):

You wrote the k[1]..k[6] are the "unknowns". The following produces a rational solution. This is similar to what Kitonum showed, but without requiring the unguaranteed steps of evalf & identify.

simplify(combine(solve(evalc(convert(eqs,radical)),
                       {k[7],k[8],k[9],k[10]})));

Naturally, you can scale (here, by 3) to get purely integer solutions.

The following would remove spurious imaginary components (eg. small imaginary artefacts due to floating-point roundoff error).

It will also remove remaining complex (ie. non-real) results, so that max can succeed.

temp := [solve(f=0,x)]:

max(select(type,
           simplify(fnormal(evalf(temp)),
                    ':-zero'),
           realcons));

Why haven't you shown us your actual equations, or uploaded and attached a worksheet that produces them? That would make it easier for people to help you.

The simplest way to get the result is to use the solve command.

The way in which the optional second argument is passed to solve controls the form in which the result is returned (ie. as y=value, or just the value).

Download solve_lin.mw

You could also get a so-called step-by-step solution shown for this class of linear problem.

This is a verbose illustration of how one could solve it by hand. (Maple's solve command has its own methodology, and I'm not sure whether you are actually asking how that works, internally.)

Download SBLSS.mw

Download simpl_ex.mw

I will submit a bug report against simplify.