@nm Thanks for the extensive testing. 

There's a command that can be used to test a procedure for a list of inputs and expected results: CodeTools:-Test. In this case you could do 

CodeTools:-Test~(
   ''ODEdegree''~((T1:= index~(tests, 1))), 
   index~(tests, 2), 
   label=~ convert~(T1, string)
);

Note the my procedure only works for syntactically correct ODEs, and it doesn't check that its input is such. Your 5th and 6th test cases are identical and have a syntax error: They have y where they should have y(x).

@Christian Wolinski 

I wasn't using the indets order; I was sorting by length. I think that I just need a tie-breaker for when the lengths are equal. For this, I'll choose set order. So, a small modification:

#Strict operand ordering:
S_O_O:= (x,y)-> length(x) < length(y) or length(x)=length(y) and x={x,y}[1]:

SubsIndets:= proc(e, t::type, T)
local J:= sort([indets(e, t)[]], S_O_O), r:= e;
   to nops(J) do (J,r):= subs(J[1]= T(J[1], _rest), [J[2..], r])[] od;
   r
end proc:
      
h := proc(x) global i; i := i + 1; T[i, op(0,x)](op(x)) end;
e:= f(f(f(f(x), g(y)), f(x)), g(y)):
i:= 0:  SubsIndets(e, function, h);
i:= 0:  subsindets(e, function, h);

Now the built-in version and my version return exactly the same thing (for your example, at least).

I agree. The left-side result seems "too recursive". I wrote my own versions of subsindets several different ways, and in every case, they retuned the same result for your left side and right side.

Please change the title of this Question. The banality and genericness of your title could lead to this Question being forgotten or overlooked. Something like "Serious discrepancy in subsindets/evalindets." (It affects evalindets also.)

@nm Here is a correction that uses frontend to temporarily ignore everything except the derivatives. I also added a check that the transformed ODE is a polynomial function of the derivatives. So, please test this on numerous examples:

ODEdegree:= (e::{algebraic, `=`(algebraic)})-> 
   try
      (e-> degree(
         e, 
         indets(
            e, 
            'typefunc'(
               (O-> `if`(O>1, 'typefunc'('`@@`'(identical(D),O)), specfunc(D)))
                  (PDEtools:-difforder(e))
            )
         )
      ))
         (
            ((e::satisfies(e-> degree(e, indets(e, specfunc(Diff)))::posint))-> 
               convert(e,D)
            ) 
               (frontend(
                  evala@Norm,
                  [convert(`if`(e::`=`, lhs-rhs, x->x)(e), Diff)], 
                  [
                     {
                         specfunc(Diff), `+`, `*`, 
                         'satisfies'(e-> hastype(e, specfunc(Diff)))^rational
                     }, 
                     {}
                  ]
               ))
         )
   catch:
      FAIL
   end try
;

You wrote:

• The hard part...is to see if the ODE can be written as a polynomial in derivatives....
  (Maybe Maple has some built-in functions to help with this algebra part?)

Better yet, Maple has a single command that does the whole polynomial conversion, evala(Norm(...)), so that part is not hard at all. It's in my code above, of course.

@nm Your indets[flat] seems okay, and better than my AllPowers procedure. I learned something new about the flat option (which is a fairly new option in Maple) from your example. I'm glad that you researched it! 

I hate repetition of code fragments, and I just figured out a way to avoid the repetition of identical(y):

indets['flat'](expr, identical(y)^~{1, algebraic});

Thank you. That's an impressive amount of formatting in a Maple document. Vote up. And I like how you show how Maple can be used for a large compendium of both non-mathematical and mathematical content. 

Some sugggestions:

1. I think that you should use standard left justification for the main exposition rather than the center justification that you used.

2. (I don't know if this was true in Maple 2015): Maple comes prepacked with all the geographical information needed to make a map of the World, which can be shown on a globe or projected to a flat map. You'd probably like the include something like that, probably in several places.

3. Surely Maple could be used to analyze remote sensing data (your 14th section). An example along those lines would be great. (My very first computer programming job (in 1979) involved analyzing satellite data of the ocean surface, primarily to detect chemical spills.) Maple comes prepackaged with all the "hooks" needed to download raw data from the Internet. 

@Carl Love Here is a procedure to address the modification needed based on your answer to Christian Wolinski's question:

AllPowers:= proc(e, y::algebraic)
local b,p;
   subs(
      {p= 1, b= y}, 
      indets(
         subsindets(subs(y= b^p, e), identical(b^p)^anything, e-> b^(p*op(2,e))), 
         identical(b)^anything
      )
   )
end proc:

Usage:
AllPowers~([y^2*sin(1/y) + y^(3/2) + x*y^7, y^2+y], y);

Note that the first argument can be any expression at all, including sets and lists, and the second argument can be any algebraic, not necessarily a name or function.

@Christian Wolinski Yes, I am working on it. I'm sure that you realize that it's difficult to exclude those undesirables from the indets. If you get to it before I do, then I think that he should select your Answer as Best.

The most important thing is that the OP learn to use indets rather than the details of this particular usage of it.

There have been numerous reports recently of this strange behavior, and the consensus has been that it's due to having a pirated copy of the Maple code.

@Joe Riel Yes, most associative operators should have a corresponding command with special evaluation rules akin to {seq, add, mul}. So that would include union, intersect, and, or. I don't include cat or xor because they have no possibility of internal simplification, so you might as well just apply their functional (prefix) forms to seq. 

@radaar Sorry for the delay in answering your memory question. I ran into a problem (a bug, I guess) specific to using Statistics:-Sample with Grid. I finally figured out a workaround for it, and I just Posted my version of your above code in the Posts section. Better yet, the solution is elegant, runs superbly fast, and uses an insigificant amount of memory. So, go read that Post.

The major problem with your code was that you were using Grid to do a small computation inside a large loop. Grid is very inefficient for small computations due to the overhead of initiating the kernels. The correct way is to make Grid:-Map or Grid:-Seq be the outer loop rather than be in the outer loop.

@JAMET The error is because the length of your major axis is less than the distance between the foci. Perhaps you meant 2*lma.

@nm Yes, I was aware of this when I posted the code. I was waiting for someone, mostly likely you, to notice ;-).

Actually, what stopped me was that in order to fix this properly, I need to know what the degree of the following is supposed to be:

diff(y(x), x) = y(x)^(1/2)  # (1)

Is it 1 or 2? Clearly, the degree of

diff(y(x),x,x) = diff(y(x),x)^(1/2) + y(x) 

is 2. But with #(1), I don't know if the y(x) is to be considered a "zeroeth-order derivative". If yes, then the degree of #(1) is 2; if no, then it's 1.

@ThU Perhaps I'm being naive, but I interpretted the Question to mean that the OP wanted the 2s to be placed in the algebraic exponents, while the minus signs were to remain in the arguments to exp. Your code doesn't separate the minus signs from the 2s. 

If I am indeed being naive about the OP's intent, then your method does seem like a reasonable way to get the desired result if you can get to the expression before it's entered.

@Guy1 To "vote up", you need to click on the thumb icon in the header of the Answer (upper right, under the timestamp). Please do that.

I added some significant details to the Answer, so you should reread it; specifically, I made a distinction between "merger of animations" and "animation of a merger".