I haven't investigated this in detail, but at first glance my guess is that the two equations are redundant, i.e., they say essentially the same thing.

Anyway, I totally agree with mmcdara's Answer.

Maple has the ability to numerically (and only numerically) solve "delay-differential" equations (DDEs). The "functional" aspect of your integro-functional equation is entirely of the "delay" type. I don't know whether there's any possibility of converting your equation to a DDE, but it's worth considering. 

Note that p is a bound variable (in the sense of mathematical logic), so it may be better to treat q as the equation's independent variable.

Even if the equation cannot be converted to a DDE, it may be worth considering using a custom algorithm that imitates DDE numeric techniques, for example, a very fine mesh of points in the interval p..p+q.

@sharmamanjeet391 Please attach a worksheet, as you did above, showing your failed attempt to implement the solution that I described.

@sharmamanjeet391 None of your systems contain any dependence on t. It just seems to be a placeholder. Thus they are actually ODEs not PDEs. Remove all occurences of t and use dsolve. I'm not saying that this will work, but it's worth trying.

And the method I described was not meant to be a workaround for this particular bug; it's just basic mathematical advice applicable even for algebraic equations. 

@Sphericalmoments Here is a procedure to create random multipartite tournaments having any number of partite sets. As you suggested, it was easy to do this by generalizing my line of code that you highlighted.

RandomMultipartiteTournament:= (N::seq(posint))->
local i:= 0, j, r:= rand(0..1), V:= combinat:-choose([seq]([$i+1..(i+= j)], j= N), 2), v;
    GraphTheory:-Graph({seq}(seq(seq(`if`(r()=0, [i,j], [j,i]), i= v[1]), j= v[2]), v= V))
:
G:= RandomMultipartiteTournament(3,4,5,6);
    G := Graph 4: a directed unweighted graph with 18 vertices and 119 arc(s)

#Verify correct number of arcs three ways:
3*(4+5+6)+4*(5+6)+5*6;
                              119
add(mul~(combinat:-choose([3,4,5,6], 2)));
                              119 
N:= [$3..6]: add(N[k]*add(N[k+1..]), k= 1..nops(N));
                              119

#Verify number of partite parts:
GraphTheory:-ChromaticNumber(GraphTheory:-UnderlyingGraph(G));
                               4

Ordinarily, I'd write you a lengthy explanation of every syntactic element of my command that you asked about, but I have a limited ability to type at the moment (the pain extends down to the fingertips of my right hand). So, can you tell me specifically which parts you don't understand? 

@Sphericalmoments Although this solution is not immediately obvious to me (especially considering my current condition), I suspect that the maximum count that you want can be determined for arbitrary (n x m) bipartite tournaments by simple combinatorics. Perhaps your reason for exploring the problem iteratively is to get ideas for such a formula.

@Sphericalmoments Procedures for both the random bipartite tournament and all bipartite tournaments of a given size would be very easy to write, so I wouldn't quite call it a "package". I'd expect about 4 lines of code for the former and 7 for the latter.

I'd write them right now, but I had a minor muscle injury in my back 12 days ago that nonetheless is causing me incapacitating pain. But maybe I can do it later today.

Would you please define bipartite tournament? To my knowledge, a tournament is a directed graph constructed from an undirected complete graph by assigning a direction to each edge. I'm having trouble reconciling that with it being bipartite.

I wrote the above before you posted the code. I'll likely be able to figure it out from the code. But please attach your worksheet using the green uparrow on the editor's toolbar. It's much easier to read your code that way.

@AT Siacara As I said in my Answer below, a procedure made with the command proc cannot make indirect references to its parameters, and unapply should be used for such procedures. For example, you have

cstr5:= proc(NN, MM) FS - G1 end proc

where FS and/or G1 presumably contain references to NN and MM. That's what I mean by an indirect reference. It should be changed to 

cstr5:= unapply(FS - G1, [NN, MM])

I agree with you that the root cause is likely the same as with that other Question, but I haven't been able to figure out that root cause.

@ThomasLev If the order of subtraction of any one of the three square roots were reversed, then the integral would be a real number of the same magnitude. You should double check that you got those orders correct.

Can you give a brief defiintion or example of a "variation tab"?

(To avoid typographic confusion, I'm using L instead of l.) Starting with E being any positive number and using your definitions for R, L, and the interval of r, we have that r^2 < 4*E^2, so the integrand is guaranteed imaginary over the entire interval. For example, evaluating at the interval's endpoints, we get

restart:
R:= E/10:  L:= R/100:
eval~(r^2-4*E^2, r=~ [R-L, R+L]);

which is clearly negative.
 

@mmcdara If you're going to sort the output of combinat:-randperm, then you'd might as well just use combinat:-randcomb instead.

Sorry, I just accidentally separated this Reply of yours into a new Question. I can't undo that. But you can copy this back as a Reply (or, better, as an Answer).