@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.

@Mariusz Iwaniuk I will only comment at length on the numeric dsolve, which is where my expertise is. I don't think that you understood my Answer. The numeric dsolve has no problem whatsoever solving any (differentiable) branch of your ODE; it simply requires that you specify which branch. Okay, Mathematica's numeric solver does them all at once; so what, big fat deal?! It's trivial to get Maple to do the same thing if that's what you want. Like this:

ODE:= diff(y(x), x)^2 - diff(y(x), x)^4:
Sols:= map(
    ode-> dsolve({ode[], y(1)=1}, numeric), 
    {solve}({ODE}, diff(y(x), x))
):
plots:-display(
    plots:-odeplot~(Sols, x= 0..1, color=~ [blue, green, red])
);

I believe that most users solving practical problems do not want multiple solutions from a numeric ODE solver because the presence of ambiguity highlights a flaw in the way that the system was input and only one of the branches is physically relevant to them. For such users, that error message should be welcomed.

On the other hand, I think that the symbolic solver should give all solutions, and thus your first example (dsolve(..., 'explicit')) shows that there is a bug.

@Ronan Your most recently posted worksheet is in 2D Input, not 1D. I wonder what makes you think that it is 1D? When your cursor is within an code-input block, the entry mode will be shown in the leftmost pull-down menu on the lowest toolbar.

However, I believe (but I'm not sure) that if you change the istep+= h as discussed above, the rest of the code will work in 2D Input.

The syntax to n do is valid, and always has been valid, in all input modes. Indeed, all of the prepositional phrases of the do command are optional (for, from, by, to, in, while​​​​​​, and until).

The problem that you were having was due to a more-subtle mistake in my posted code. Instead of saving the results in the vector R, it was putting them in a hidden temporary vector and then discarding them. Sorry about that. The syntax that the Modular package uses is unusual and unforgiving. Here is the corrected code:

BooleMobiusTransform:= proc(V::Vector[column](datatype= integer[8]))
uses LAM= LinearAlgebra:-Modular; 
local 
    n:= ilog2(numelems(V)), im:= Scale2(1, n-1), istep:= im, 
    jm:= 1, h:= Scale2(im, 1), istart, 
    R:= LAM:-Create(2, h, 0, integer[8]);
    LAM:-Copy(2, rtable(1..h, V, subtype= Vector[column]), R);
    to n do 
        istart:= 1;
        to jm do
            LAM:-AddMultiple(
                2,
                R, istart..im-1+istart, 
                R, istart+istep..im-1+istart+istep,
                R, istart+istep..im-1+istart+istep
            );   
            istart+= h
        od;
        (im, istep, jm, h):= Scale2~([im, istep, jm, h], [-1$3, 1])[]
    od; 
    R
end proc
:

The vast majority of the execution time of the erroneous code was spent creating those hidden temporary vectors. The current code operates on the vector "in-place" (as did your original). So this code will do the 2^25 case in 0.2 - 0.3 seconds, which makes it well over 100 times faster than the compiled code.

Instead of copying and pasting the code above, download the worksheet attached below. That way, you'll see what I mean by "1D input". You'll see that the code is upright, reddish brown, and monospaced just like in the box above.

BooleMobius.mw (worksheet download link)

@Ronan My code requires 1D input. Are you using 2D Input? The istep+= h is correct and means the same thing as istep:= istep+1. It required 1D input.. Sorry that I didn't mention that; I forget to because I never use 2D Input.

Note that the code above is several times faster than the compiled alternative, so it's probably worthwhile to switch your input mode.

I don't think that making a copy is strictly required, but it's easier to do it that way in LinearAlgebra:-Modular, which has a very unforgiving syntax