@JAMET Sorry about that. I had just noticed that myself, and I uploaded a new worksheet a few minutes ago. Try it again.

I have often had trouble with Grid:-Seq when the chunks were too small. I'd recommend that each chunk take at least 2 seconds to process. Your 500 seems both rather arbitrary and way too small.

I don't think that it can be done unless you know the positions of the vertices. If you do know (for example, if you can measure them from an existing picture), then you can use SetVertxPositions. I doubt that there is any algorithm to do it without knowing those vertex positions.

To give you an idea of the problems with constructing an algorithm, consider the triangle inequality.

@mmcdara The output of showstat is equivalent to the output of printf; so, yes, it's "side-effect" output rather than "return value" output. That's why I went one step back through the showstat code to get the output from debugopts(procpretty= ...). This is identical to the standard showstat output, but in string (actually name) form.

@Pascal4QM Thanks. As you can probably tell, I worked it out by deconstructing showstat itself.

@acer You can use a line-width specifier in the format code such as "%40P". Then, the lines will be sensibly broken and indented with a maximum length of 40. It's quite impressive how nicely it's done.

@dharr 

dsolve(..., numeric) does try to solve ODEs for their highest derivatives before proceeding. But if there are multiple solutions, even trivial ones, it refuses to arbitrarily select one.

There are other issues that may hamper the attempt that are relatively easy to address "by hand". For example, in the case at hand, I needed to differentiate one of the equations. That often necessitates additional initial\boundary conditions, but it didn't in this case.

The physics of the original equations is wrong. The algebra by which I first used solve to get dsolve to solve those equations is very standard. Other than correcting g to negative, I didn't look at the physics of the equations; I figured that that'd be a job better suited for you. Indeed, I almost concluded the Answer with "I'll let Rouben address the physics."

@acer The OP is attemptimg to solve this problem, which was posted by another user a few days ago. I guess that they're taking the same course. Thus, the exponent in the integrand is intended to be 3/2, not 3. Maple can still solve it symbolically, although it's not clear whether that's desirable.

@emendes 

Here is my code that processes all 4 extra conditions. I get 123 3-tuples, just as you did. 

Download Symmetries.mw

Answers (in no particular order):

1. Re: Why op rather than `?[]`: The syntax `?[]`(A, [k]) requires [k], whereas op(k, A) does not. Those extra [ ] contribute to the garbage that must be periodically collected. Garbage collection is a major user of processor time.
2. Re: Condition 3 and tuple length: I misunderstood condition 3. I understand it now, and you're correct, the upper limit of tuple length is much greater than the number of distinct js. I needed to see both of your examples to understand condition 3.
3. Re: Maximum orbit length: Since conds(conds(x)) = x for any x (using the current T1 and T2), the maximum orbit length is 2. By the definition of orbit, the orbit length is the number of applications of conds needed to get back to the original. Suppose that T1 were changed to table([1= 2, 2= 3, 3= 1]). Then there would be length-3 orbits. Can this ever happen? This is equivalent to asking Can a variable ever have more than one "counterpart"?

@AHSAN Here's a Maple worksheet: NewtonRaphson.mw

@emendes 

Questions: 

1. For your new (4th) condition, you said "..., as well as its counterpart". Does "..., as well as its counterpart" also apply to the other three conditions? In other words, is it necessarily the case for all possible conditions that the invalidity of one member of its orbit makes the whole orbit invalid even though some members of the orbit may not violate the condition? If so, I'll need to change the above code.
2. Using tables T1 and T2 as above, conds is an involution, i.e., all nontrivial orbits are length 2. Will that always be true, or is that just a property of this particular T1 and T2? If it's always true, I may be able to make the code more efficient.

Answers:

1. The 3rd condition: You show an example of failure of the 3rd condition (i.e., an invalid set), not satisfaction (i.e., a valid set). Yes, of course, invalid sets can have an arbitrarily high number of elements; however, valid sets necessarily have a number of elements at most as large as the number of distinct js. In our case, that means that it's impossible for an 11-or-greater-tuple to be valid.
2. `?[]` vs op: The function `?[]`(A, [k]) is the prefix functional form of A[k] (in all cases). For our cases, it can be (and should be!) replaced by op(k, A). It's my fault for not immediately realizing that on my own. My next version will use op instead of `?[]` wherever possible.

@emendes You can check for those additional conditions like this (this is coded for Maple 2019 or later):

OrbitPartition:= (
    parms::And(set, listlist &under [op]),
    tuple_size::posint,
    permutations_by_index::list(table),
    Allowed::appliable
)->
local 
    C, i, Done:= table(),
    T:= proc(T,j) option remember; `if`(assigned(T[j]), T[j], j) end proc,
    conds:= varCoef-> map(x-> T~(permutations_by_index, x), varCoef),
    Orbit:= x-> 
        local 
            r:= x, 
            R:= {
                do 
                    Done[r]:= if Allowed(r, tuple_size) then r else fi 
                until assigned(Done[(r:= conds(r))])
            }
        ;
        if R <> {} then R[1] fi
;   
    {seq}(
        if assigned(Done[(i:= parms[[seq(C+~1)]])]) then else Orbit(i) fi,
        C= Iterator:-Combination(nops(parms), tuple_size)
    )
:
parms:= {seq(seq([i,j], j= 0..9), i= 1..3)}:
T1:= table([2= 3, 3= 2, 5= 6, 6= 5, 7= 9, 9= 7]):
T2:= table([2= 3, 3= 2]):
Allowed:= (S,sz)->
    local J:= map(`?[]`, S, [2]); 
    {1,2,3} subset map(`?[]`, S, [1]) and max(J) >= 4 and nops(J)=sz
:
   
newabc:= CodeTools:-Usage(OrbitPartition(parms, 3, [T2,T1], Allowed)): 
memory used=10.85MiB, alloc change=-9.46MiB, cpu time=235.00ms, 
real time=137.00ms, gc time=156.25ms

nops(newabc);
                              358

Your 3rd condition cannot possibly be satisfied by any set with more than 10 elements, so there's no need to check those tuple sizes.

Here's the same code done with Maple 2019 syntax. Note that this has a major efficiency boost and code shortening also.

OrbitPartition:= (
    parms::And(set, listlist &under [op]),
    tuple_size::posint,
    permutations_by_index::list(table)
)->
local
    C, i, Done:= table(), 
    T:= proc(T,j) option remember; `if`(assigned(T[j]), T[j], j) end proc,
    conds:= varCoef-> map(x-> T~(permutations_by_index, x), varCoef),
    Orbit:= x-> local r:= x; {do Done[r]:= r until assigned(Done[(r:= conds(r))])}[1]
;   
    {seq}(
        if assigned(Done[(i:= parms[[seq(C+~1)]])]) then else Orbit(i) fi,
        C= Iterator:-Combination(nops(parms), tuple_size)
    )
:
parms:= {seq(seq([i,j], j= 0..9), i= 1..3)}:
T1:= table([2= 3, 3= 2, 5= 6, 6= 5, 7= 9, 9= 7]):
T2:= table([2= 3, 3= 2]):

newabc:= CodeTools:-Usage(OrbitPartition(parms, 7, [T2,T1])): 
memory used=6.13GiB, alloc change=0.77GiB, cpu time=80.48s, 
real time=51.26s, gc time=36.52s

@emendes That issue is addressed by my next Answer, "New paradigm: Partitioning by orbits".