It's as simple as 

diff(BesselI(alpha, x), x);

Note that the last letter of the function name is uppercase I ("eye"), not lowercase l ("ell").

I can't get Maple to give the Fourier transform of your function, even by direct integration in the a=1 case.

However, regarding your other question, about algsubs: As discussed on its help page ?algsubs, this command treats denominators differently than non-denominators. To substitute x=ex (where x is a name and ex is an expression) into another expression LE, there are only two commands that should be used: either eval or subs---reserve algsubs for more-complicated substitutions, such as when x is an expression.

• If you want to make the substitution regardless of whether it's mathematically valid, use subs(x= ex, LE).
• If you want Maple to consider the mathematical validity, use eval(LE, x= ex).

Either of these commands will be more robust and far more efficient than algsubs.

For this reason among others, SearchText should be deprecated. StringTools:-Search and StringTools:-SearchAll are externally compiled, so they're adequately efficient replacements; probably more efficient when multiple searches are specified in a single command. Making a wrapper for a case-insensitive version of these to replace searchtext is trivial (if we say that only ASCII characters can have a "case").

While I agree with your premise in theory, in practice you may need to make a distinction between different kinds of infinity. The code that you show returns +infinity, somewhat by happenstance. It could just as well have been -infinity or some complex flavor of infinity. Also note that once you allow infinities, the usual field rules of real and complex arithmetic no longer apply. In general, Maple's ability to navigate these issues on its own is pretty good.

As Acer's Answer shows, mod is complicated, and so I usually reserve its use for "higher" algebraic and number-theoretic computations. For numeric arithmetic, I use irem, which automatically returns unevaluated for non-numeric arguments--suitable for your purpose.

iremp:= (x,m::posint)-> irem(m+irem(x,m),m):
plot(iremp(ceil(x),2), x= -9..9);

The first of these commands is to make the correct adjustment for negative arguments, similar to the distinction between modp and mods.  

A not-necessarily-integer parameter---nominally called "degrees of freedom"---is commonly used for the t and chi-square distributions. See "Welch's t test" and "Welch-Satterthwaite equation". This is taught even in second-semester statistics. Perhaps "degrees of freedom" wasn't the best choice for the name of this parameter, but this usage is unfortunately well established, and the mathematical concept is solid.

Unfortunately (AFAIK) there's no way (either with or without assumptions) that you can use the commands solve or isolve to achieve your goal, which I think is to extract 100, 20, 3 from 123. But there is an easy way:

b:= 10:  convert(123, base, b) *~ [seq(b^i, i= 0..floor(log[b](123)))]  

The 10 could be replaced by any integer base greater than 1. The results are returned with the least-significant digits on the left.

In order to implement the Path psuedocode that you show, it is necessary that the AllPairsDistance procedure record the path information in the matrix Next (note that lowercase next is a reserved word in Maple). So, I wrote an object-oriented module that implements both procedures.

This uses Maple 2019 syntax. If you're using an earlier Maple, let me know, and I can change it.
 

Download FloydWarshall.mw

It just assumes that all unweighted edges have weight 1. That is explained in the first paragraph of the help page ?GraphTheory,AllPairsDistance.

I'm not sure if that answers your Question, since I can't find a direct reference to "Betweeness centrality matrix".

I think that you've conflated the mostly typographical notion of the first or left-most coefficient with the algebraic concept of the leading coefficient. And it seems that you simply want the sign of the left-most. I think that this procedure will do it:

Sign:= (e::algebraic)-> 
   if e::{`+`,`*`} then thisproc(op(1,e))
   elif e::{`^`,function} then 1
   else try sign(e) catch "invalid argument": thisproc(op(1,e)) end try
   fi
:

Edit: Added type `^` to code above.

Your

= "inverse of tan (x)"

contains an invisible bad character. Just backspace over this part of the command and retype it manually; don't copy and paste.

In an arrow expression such as x-> D1, the name(s) to the left of the arrow (the x in this case) are called parameters. In the vast majority of cases, of course, the intent is that the expression will depend on the parameter(s); that is to say it'll be a function of its parameters. For this to happen, the parameter(s) must explicitly appear on the right side of the arrow. 

In your case, on the other hand, you're trying to make an arrow expression with an indirect reference to the parameter; x doesn't explicitly appear in D1. That's a case where you should use unapply.

From my brief review of your worksheet, it looks like all your numeric dsolves are simple integrations, so they can be replaced with numeric integration. You should try that; I think it would use less memory.

Unlike a typical calculator, Maple doesn't have an easy way to switch from "radian mode" to "degree mode". It's always in radian mode. But we can define functions so that the conversions between those modes can be done in a few keystrokes. I think that this is the level of convenience that you're looking for. We define two simple functions, the first to input 2D vectors in (magnitude, direction-in-degrees) form and the second to add them and then output the result in that form. You can put these in an initialization file:

`&<`:= (r,t)-> polar(r,t*Pi/180):
`&+`:= (a,b)-> evalf([op](polar(evalc(a+b)))/~[1,Pi/180]):

Usage:

(1 &< 30) &+ (1.5 &< 60);
      [2.418279598, 48.06753728]

If you're referring to the Grading package, I believe that that was introduced in 2014.