When a worksheet (or document) is viewed as a slideshow (via menu View => Slideshow), its sections become the slides. This means that you need to make each section small enough that it fits on one screen. So, if you need to present a slideshow, it'd be wise to first perfect your edit of the flat (un-sectioned) worksheet, then divide it into sections. Also, the presentation is fixed slides rather than executable code. Generally, when I give a presentation, I prefer to execute key parts of the code directly for my audience. That helps maintain their attention.

This seems to me to be a very weak feature of Maple.

In the following line, you've misspelled indkomst as indomst:

elif 44000 < 0.92*indkomst and indomst <= 44000+fradrag then

Your worksheet begins with the line

restart; ... several with commands ....

But, the restart command should always stand alone in its own execution group. Failure to do so can cause intermittent and irreproducible errors related to the other commands on the same line not being executed.

I cannot test this solution for you because the error is, of course, irreproducible for me.

And, personally, I never rely on the with command to find procedures for me. This is not because I think that there's some bug in with; rather it's because I think that it leads to less-readable code.

Change the line

A:= seq(...)

to

A:= < seq(...) >

This will make A a Vector rather than a sequence. The Export command (like almost all commands) cannot except a sequence as an argument.

Here's an example. Here's two 2x3 matrices:

A:= <1, 2, 3; 4, 5, 6>; 
B:= <a, b, c; d, e, f>;

This command will take the 2nd row of each and combine them into a new 2x3 matrix:

C1:= <A[2,..], B[2,..]>;

This command will take the 2nd row of each and adjoin them side-by-side:

C2:= <A[2,..] | B[2,..]>;

For the first of these combinations it's of course required that the number of columns be the same in A and B. For the second, that's not required.

Regarding your first question---selecting the 3^rd element from each sublist of a list of lists L1---here are three more ways to do it. I find these more intuitive, although there's hardly any difference in efficiency compared to the other Answers.

L1[..,3];
index~(L1, 3);
op~(3, L1);

Experienced Maple users may be surprised that the first of these--which uses Matrix-style indexing--works even if the sublists have different lengths, that is, if L1 cannot be interpreted as a Matrix.

Regarding your third question---sorting a list of lists L3 based on the 3^rd elements---here is a better way, both more intuitive and (slightly) more efficient:

sort(L3, 'key'= (L-> L[3]));

For a very long list, a key sort is more efficient than a sort that uses a comparison function because the key of each entry only needs to be extracted once.

Inside procedure U, you've used the names `U__&eta` and `U__&theta`. But in procedure plug, you've used U__eta and U__theta. These are completely different names to Maple even though they appear the same when prettyprinted.

Have you checked the help page ?index,threadsafe to check whether your code is threadsafe? What you described is common if you try to use procedures that aren't threadsafe with Threads.

Usually it is not necessary to quit Maple entirely, despite what the "lost kernel connection" message on your screen might say. Usually you just need to kill the errant kernel process and close and re-open its assocciated worksheet. If you have multiple worksheets open, doing it this way is much less grief.

By hand (actually, in my head), I isolate the relevant derivative: 

ode:= diff(x(y),y) = a*y^(-6*b-1) - 4*x(y)/y;

Then use dsolve:

dsolve(ode);

How about the simple and obvious 

Linear:= (f::polynom, V::{list,set}(name):= indets(f, And(name, Not(constant))->
   evalb(degree(f, V) <= 1)
:

The problem is that much time is wasted on futile symbolic computation of the integrals. Put the option numeric in your integrals. Get rid of evalf. Example:

Digits:= 15:
int(79.977249/(z+7.943)^2/(z^0.1408592322+7.943), z= 1..infinity, numeric);
                       0.953406537701741

That's returned in 0.016 seconds.

Acer's suggestion of evalf(Int(...)) is essentially equivalent to the above. We were just writing our Answers at the same time.
 

So, without showing any apparent reason for doing so, you use this crazy value 50 billion as one of your upper limits? Reduce that value to a reasonable size and the command will work quickly.

What do you expect to happen if there are a billion roots? that they'd be printed on your screen? Unless you have some unusually massive computer, they wouldn't even fit in your RAM.

C'mon, are you seriously trying to claim that you didn't already know, or at least strongly suspect, that this 50 billion was the source of your error? And if you already suspected that, why didn't you try changing it?

Here are procedures for the primary and inverse functions:

Lehmer:= (S::And(list(nonnegint), satisfies(S-> max(S)=nops({S[]})-1)))-> 
   Rank(Iterator:-Permute([{S[]}[]]), S) - 1
:
LehmerInv:= (s::nonnegint, n::And(posint, satisfies(n-> s < n!)))->
   [seq(Unrank(Iterator:-Permute(n), s+1) -~ 1)]
:

Your fsolve is returning unevaluated for some loop iteration. This can mean several things, all of which commonly occur:

1. There is actually no solution.
2. fsolve thinks that there is no solution even though there actually is. In other words, some iterative process akin to Newton's method is diverging for every initial value that it tries.
3. fsolve knows that there is a solution, but it can't refine it to sufficient accuracy. In other words, the iterative process is converging, but there's some oscillation in the last few digits.

So, whenever fsolve is used programmatically, such as in a loop, you should check the form of the returned value (your S) to make sure that it isn't of the form fsolve(...) before that S is used in a further computation. Do something like this:

Failures:= table();
for i ... do
    ...; 
    S:= fsolve(...);
    if eval(S,1)::specfunc(fsolve) then 
       Failures[i]:= eval(S,1)
    else
       w(i):= eval(k, S)
    end if
end do: 
eval(Failures);

At the end, Failures will contain all the cases for which fsolve didn't converge. You may decide to analyze these further, or you may decide that the cases that did converge are sufficient for your purpose.

If you need further help with this, please post your complete code.

Here is a procedure to return the dependent variables from a PDE, ODE, or a set or list thereof:

depvars:= (pde::{algebraic, `=`(algebraic), {set,list}(algebraic, `=`(algebraic))})-> 
   indets(
      indets(convert(pde, diff), specfunc(diff)), 
      And(typefunc(name, name), Not(typefunc({mathfunc, identical(diff)})))
   )
:

And here is an implementation of is_solution_trivial:

is_solution_trivial:= (pde, sol::{`=`, set(`=`)})-> 
   evalb(eval(`if`(sol::set, sol, {sol}), depvars(pde)=~ 0) = {0=0}) 
: