@robertocooper 

The symbol-forming operator `...`​​​​​​​: A symbol (in its specific sense as a Maple type) is what might be commonly called a "variable" in programming languages. (They are a subset of Maple names, the only difference being that a name can have indices.) You probably already understand, at some level, the basic rules for making symbols: just about any combination of letters, numerals, and underscores that doesn't begin with a numeral. But actually any sequence of characters whatsoever, no matter how weird, can be a symbol if you enclose it in `...`. If the symbol would otherwise be a reserved word, then the quotes are required to use it in any other context. Such is the case with Kitonum's `if`---if without quotes is a reserved word---and the "other context" is that it's being used as a function name. That `if` and ifelse mean the same thing is irrelevant (to the meaning of `...`, not to the meaning of `if`).

Symbol forming is the only way that the back quotes are used in Maple. They are always used in pairs. Symbols have many similarities with strings, which are formed with double quotes "...". Single forward quotes '...' are also used in pairs in Maple; however, their meaning is completely unrelated to symbols or strings, so be careful not to confuse them with back quotes.

The elementwise operator ~: This operator has an action similar to the commands map and zip. It duplicates the action of some other operator (to which it has been appended) over the contents of a container or containers. This is called elementwise operation (see ?elementwise). In the case at hand, the matrices are the containers. The result of M = Id is exactly what it looks like: an equation whose both sides are matrices. But the result of M =~ Id is a single matrix whose every entry is an equation formed from corresponding entries of M and Id.

Unlike the back quotes, the tilde (~) has several uses in Maple, both in input and output. The majority of its uses in input are elementwise operations.

For further help: In my opinion, this website, MaplePrimes, is by far the best place to get help about these things. There's also the Maple Programming Guide, which is available directly within Maple's help system.

@Yo Since Maple 17 (I think), one seq with no index is sufficient:

Sys:= {seq}(M =~ Id);

@student_1 There is a sigularity for any rho <= -1, so you need to assume rho > -1.

Each ​​​​​​psi[i] is piecewise linear in t. Your integral is thus essentially the same as

J:= simplify(int((A^(rho+1) - t^(rho+1))^(alpha-1)*t^rho*(B*t+C), t= 0..A)
    assuming alpha > 0,  rho > -1, A > 0;

My Maple can easily do that integral, although the result before simplification is a bit scary looking. You then just need to change A to j*h and change B and C to their appropriate values over the piecewise branches.

@Gillee I said that there were 8 solutions meaning over the complex numbers. I didn't mean 8 integer solutions. However, given that there are 8 complex-valued solutions, I'd be surprised if it didn't sometimes occur that all 8 of those were integers.

Your procedure LoL is examining 6 of those 8 for integrality somewhat at random. The parameters a, b, c, and d can appear in solutions in + or - form (just like the sqrt) with a and b having the same sign and c and d having the sign. You check these combinations (each with +sqrt or -sqrt):
(+a, +b), (+c, +d)
(-a, -b), (+c, +d)
(-a, -b), (-c, -d).
So, you're missing (+a, +b), (-c, -d). If this last case gives integers and exactly one of the above 3 cases give nonintegers, then there'd be 6 integer solutions without LoL detecting it. That's why there is a 6-integer-solution case that your procedure didn't find.

In general, the number of roots of a univariate equation of polynomials and absolute values is the degree of the underlying polynomial times 2 for every absolute value containing the solution variable. Specific cases may have fewer roots.

I neglected a step in my solution procedure of verifying the specific roots in the original equation. That is usually needed when generating specific cases from a parameterized general solution. I'm working on a procedure for this (that doesn't use copy-and-paste to get the original equation inside the procedure).

@ik74 I'm reluctant to even respond to such an uninformative Reply. It should be obvious that if you want more help, you need to give more details about how exactly it doesn't work.

I believe (although I'm not sure) that your PDF link only allows access to the full text of the article to ACM members. Anyway, if that isn't true, at least I couldn't figure out how to get more than the abstract.

You'll need to post your worksheet as an attached file. Use the green uparrow on the MaplePrimes editor toolbar.

My preliminary diagnosis is that the Startup Code in the worksheet (Ctrl-Shift-E in Windows) contains an assignment to `&//` before the define command that produced the error.

@grad_stu Good job. That's essentially what I had in mind 

@grad_stu Yes, it can be done. It's a bit awkward though. The code that does the measuring must be part of the code passed to Run. And you make the return values be the timings and whatever else you'd ordinarily return. I'll post an example in a few hours, if you haven't figured it out by then.

@Ronan As explained in my previous Reply, the earlier speedup was largely due to me inadvertently exchanging the updates of h and jm, which incorrectly reduces substantially the number of inner loop iterations.

I think that you should remove Best Answer from my Answer and award it to @dharr .

@dharr You're right; it was a careless mistake on my part. Making that change substantially increases the number of inner loop iterations and hence the time, regardless of any updates to Modular. With this change, I think that the compiled code is faster.

Several more of the index variables can be eliminated. This is just to simplify the code; it has minimal effect on the time. These index variable eliminations could also be used in the compiled code.

BooleMobiusTransform:= proc(V::Vector[column](datatype= integer[8]))
uses LAM= LinearAlgebra:-Modular; 
local 
    n:= ilog2(numelems(V)), H:= Scale2(1,n), 
    im:= Scale2(H, -1), istart, b, r,
    R:= LAM:-Create(2, H, 0, integer[8])
;
    LAM:-Copy(2, rtable(1..H, V, subtype= Vector[column]), R);
    to n do 
        for istart by Scale2(im,1) to H do
            LAM:-AddMultiple(
                2,                            #modulus
                R, istart..(b:= im-1+istart), #addend
                R, (r:= istart+im..b+im),     #addend
                R, r                          #where to store sum
            )
        od;
        im:= Scale2(im, -1)
    od; 
    R
end proc
:

@Jean-Claude Arbaut The purpose of the syntax ':-foo' is to guard against the possibility that the user has globally made an unrelated assignment to the keyword foo. A better solution is to allow the passing of keywords as strings (e.g., "foo"), and much of the Maple library code written in the last few years does it that way. Strings are necessarily constant; there's no possibility that they've been reassigned.

@Jean-Claude Arbaut 

Neither your procedure nor the one in my Answer needs to extract or modify Edges(G) because the same information about edges is contained in the weight matrix.

Your procedure runs without error on an undirected graph, but the edge weights will be doubled (except for self loops). It won't work as-is on unweighted graphs, but this can be easily fixed by substituting the adjacency matrix for the weight matrix (see code below). 

If you learn only one general thing from my code today, let it be this: A procedure should not rely on a package having been loaded. Instead, start the procedure (or an encompassing module) with a uses declaration. (And never use the with command in a procedure.)

In the procedure below, I've excluded undirected graphs from the input in case you don't want that doubling, and also to show you how you can include a filter in the proc line.

Dir2Undir:= proc(G::And(GRAPHLN, satisfies(GraphTheory:-IsDirected)))
uses GT= GraphTheory;
    GT:-Graph(
        GT:-Vertices(G),
        rtable(
            ':-symmetric',
            (W-> W + W^+ - rtable(':-diagonal', W))(
                GT[
                    if GT:-IsWeighted(G) then WeightMatrix
                    else AdjacencyMatrix
                    fi
                ](G)
            )
        )
    )
end proc
:

@tomleslie 

Your procedure doesn't have a consistent way to deal with bidirectional edges in the digraph that have different weight in each direction. I don't know whether you considered this and decided to ignore it or whether the possibility hadn't occurred to you.

My procedure uses the sum of the weights, although it's not clear that this is what the OP wants. 

@AHSAN

It's not clear whether you want to use y as the independent variable of the ODE system or as the specific value of the independent variable at the upper boundary. You can't use it as both, which is how you currently have it. I'll make y the independent variable and use Y as the boundary. It's also not clear whether you want A to play some role in the final result or whether it's just a temporary intermediate constant of integration. I'll choose the latter, and so A will not be used in my solution at all.

ode:= diff(Phi(y), y$2) = K;  #2nd-order ODE
bc:= Phi(-Y) = 1, Phi(Y) = -r;
Sol:= dsolve({ode, bc}, Phi(y));

That's all there is to it.