You can simply use the top-level solve command.

For example,

eqs := [ K1 = N*(R9 + R6) + R9 / (R9 + R6)*N^2 + (2*R6 + 2*R9)*N + R9,
         K2 = N*(R6 + R9) / (R6 + R9)*N^2 + (2*R6 + 2*R9)*N + R9 ]

sols := solve(eqs, [R6,R9], explicit);

solveexample.mw

One way to get something stronger than evalb (via EqualEntries, from LinearAlgebra:-Equal) is,

    andmap(is,v1-v2,0)

There are other terse ways.

The following happens due by automatic simplification in the kernel (ie. you cannot delay it using delayed evaluation, once you get to this expression):

'2^(-1/2)';

              1  (1/2)
              - 2     
              2  

The following division does not suffer from that effect, and still using unevaluation quotes. But it is a relatively poor solution, since a pair of uneval-quotes will get stripped off upon each evaluation.

'1/sqrt(2)';

                1
              -------
               sqrt(2)

Solutions that require an ad hoc number of pairs of uneval-quotes tailored to suit the application are clumsy and poor. (Too few quotes and the effect vanishes, yet too many and ugly quotes are visible. It's a poor technique.)

There are a few other approaches that do not suffer from the ephemeral nature of uneval-quotes. One is to use an inert form:

1/%sqrt(2);

Other choices include wrapping key parts with a call to ``(...) , which can be undone using expand or evalindets.

More work is involved if you want to replace forms in precomputed results. For example, to replace the following returned result one might sensibly wish to first check that the integer base of the radical in the numerator divides into the denominator.

7/(6*sqrt(2));

              7   (1/2)
              -- 2     
              12  

But first you might want to consider whether this is for final presentation only, or whether you need computation/manipulation of the fixed-up/somehow-inertized expressions.

If you inform the identify command of additional base constant values then it can find an appropriate match.

If you provide factor with an (ad hoc, alas) extension then you can get exact trig form results without going via floating-point approximations (ie. without evalf).

Download solvetrig.mw

Sorry, this site's not allowing me to inline the worksheet.

The SolveSteps command is part of the Student:-Basics package. It looks like you may have mistakenly tried to use the command name without either qualifying or loading it

Try either of these:

Student:-Basics:-SolveSteps([12*x + y = 18, 7*x - 8*y = 32]);

with(Student:-Basics,SolveSteps);
SolveSteps([12*x + y = 18, 7*x - 8*y = 32]);

Is this the kind of substitution you want to achieve? (two ways)

ee:=BesselK(a1,b1)+BesselK(a2,b2);

applyrule(BesselK(a::anything,b::anything)
          = 1/(2*GAMMA(a))*(b/2)^(-a),
          ee);

subsindets(ee, specfunc(anything,BesselK),
           u->1/(2*GAMMA(op(1,u)))*(op(2,u)/2)^(-op(1,u)));

BKsubs.mw

ps. I added a factor or 1/2, for fun...

The non-CUDA timing can change because the MKL bundled with Maple (ie. that matches the Intel compiler version used to build the relevant parts of Maple) can be a later version. It can change from from release to release of Maple, and Intel strives to improve it. When newer architectures arrive there may well  be additional potential optimizations which require new coding by Intel.

The CUDA implementation of the relevant DGEMM function might also be improved, over time as well as for new architectures. There's no forcing reason why the Intel MKL should improve at the same rate as the CUDA implementation.

If I correctly understand your ratio definition (and if the CUDA timing is roughly the same for your two cited Maple versions) then the diminishment in the ratio could be explained simply by the fact that Intel has improved the performance of their MKL DGEMM for at least your platform and hardware. This has been a general trend for some years now.

The cost of transfering the data to-and-from the GPU card has also become a larger relative portion of the whole computation, as the timings improve. On some platforms and architecture the MKL DGEMM on the CPU is actually faster than the CUDA DGEMM on the GPU + data transfer cost for the 4000x4000 example.

The final step can also be accomplished using the collect command.

Download Q20210316_ac.mw

I also adjusted your use of algsubs to obtain your intended alternate, eq_i2, which had its first argument's lhs and rhs reversed. (I recall our covering that aspect previously.)

You can get rid of the warning by explicitly declaring the name as local to the procedure.

While the 2D Input parser has not yet been updated to recognize the local declaration within a procedure entered as an operator in the arrow style, you can still enter it in the proc()...end proc way.

For example, in either 2D or 1D input modes,

    f := proc(t) local n; seq(t^n, n = 0 .. 3); end proc

or, if you'd like the immediate output of the printed procedure to appear in arrow notation,

    f := proc(t) option operator, arrow; local n; seq(t^n, n = 0 .. 3); end proc

kernelopts(version);

     Maple 2020.1, X86 64 LINUX, Jun 8 2020, Build ID 1474533

4 %+ 3 %* 2;

            4 %+ (3 %* 2)

op(0,%), [ op(%) ];

            %+, [4, 3 %* 2]

In Maple 2019.2 it produced your cited result.

Several people had previously and independently reported the problem.

A table has last-name evaluation rules.

Download table_and_loop_acc.mw

You could apply rationalize or evala to the integrand, before calling int.

restart;

kernelopts(version);

    Maple 2020.1, X86 64 LINUX, Jun 8 2020, Build ID 1474533

B:=sqrt( (-4*u^(1/3)+1)*u^(4/3)):
A:=1/(-12*u+3*u^(2/3)-3*B):

foo:=int(rationalize(A),u);

  1/2*(-(4*u^(1/3)-1)*u^(4/3))^(1/2)/u^(2/3)/(-4*u^(1/3)+1)^(1/2)*arctanh((-4*u^(1/3)+1)^(1/2))-1/12*ln(u)

simplify(foo) assuming u>0;

                    /               (1/2)\           
           1        |/    (1/3)    \     |   1       
           - arctanh\\-4 u      + 1/     / - -- ln(u)
           2                                 12      

foo:=int(evala(A),u);

  1/2*(-(4*u^(1/3)-1)*u^(4/3))^(1/2)/u^(2/3)/(-4*u^(1/3)+1)^(1/2)*arctanh((-4*u^(1/3)+1)^(1/2))-1/12*ln(u)

simplify(foo) assuming u>0;

                    /               (1/2)\           
           1        |/    (1/3)    \     |   1       
           - arctanh\\-4 u      + 1/     / - -- ln(u)
           2                                 12      

And, if you prefer, you can also apply simplify to those modified integrands, before calling int.

foo:=int(simplify(evala(A)),u):
simplify(foo) assuming u>0;

foo := int(simplify(rationalize(A)),u):
simplify(foo) assuming u>0;

An alternative here for simplifying the integration result foo under the assumption that u>0 is,

simplify(combine(foo,symbolic));

I believe that the above also produces the simpler result in 2021.0, but you could check.

eqs := [(a*x1+b*x2)/x3+c*x1^2/(e*x2+d)=f];

               [                   2      ]
               [a x1 + b x2    c x1       ]
        eqs := [----------- + -------- = f]
               [    x3        e x2 + d    ]

(numer@(lhs-rhs))~(eqs);

   [a*e*x1*x2+b*e*x2^2+c*x1^2*x3-e*f*x2*x3+a*d*x1+b*d*x2-d*f*x3]

This did not also use the normal command.

Does the RealRange output appear as you want, if you first issue this command?

   interface(typesetting=extended):

Note that command can be placed near the top of a Worksheet or Document, but it should be placed in its own Execution Group or Document Block, ie. not in the same one as a restart.

I do it for at least these two reasons:

1) So that I can re-run the whole sheet by just clicking the !!! button. Ie. I don't have to also click the restart button.

2) When I write a worksheet for someone else I ensure that they'll get a clean restart if they re-run using only the !!! button. (This leads to less confusion.)