@brian bovril Don't associate my name with this ridiculous piece of crap:

• rhs(ST[ListTools:-Search(2, lhs~(ST))]):-mu;
                 ^^^^^^^^^^^^^

There's no point in using Search together with a table.

@Kitonum The first year has an atypically low growth rate. The growth factor for the second and all subsequent years, to the nearest integer, is round((3/2)^12) = 130.

This remains true if we start with any number of females greater than 2 and round down any fractional results, as in

u:= rsolve(
    {u(k)= u(k-1) + trunc(3/4*u(k-2)), u(-1)=0, u(0)=3}, u(k),
    makeproc
):
evalf(u(24)/u(12));

@schzan Your only example only used multiplication and exponentiation. My code does not "fail"; it intentionally reports the presence of unexpected input. So, how complicated can these expressions be? Would there ever be division by an indexed variable? Would a function such as abs or sin ever be used applied to an indexed variable? Would exponents other than positive integers ever be used? Should x*u[2] + y*u[2] count as two 2s? Or should it be one 2 because that's the same thing as (x+y)*u[2]. Is it only one base name (such as u) in each expression that can be indexed? Can other non-name expressions be indexed (note that Maple allows almost anything to be indexed, such as (x+y)[3], 7[2], etc.)? Can the indices themselves contain further indexed names, such as u[1, u[1,2]]? Are the expressions always algebraic, or might they also contain lists, sets, vectors, etc.? It was you who "failed" to provide these necessary details. 

Note that mmcdara's code will ignore multiple occurences of the same indexed variable within an expression. Is that what you want?

To answer that, we need to know at least the following:

1. the average litter size
2. the average proportion of females
3. The average time interval between litters for a female
4. the average lifespan, which may be different for males and females
5. the average age at which a female first gives birth

Thanks for bringing some humor to MaplePrimes. And a Vote Up for a visually impressive and aesthetically pleasing graphic (especially the colors). I haven't read the code yet, but I suspect that there's not much technical complexity to it.

@vv Would you please provide more details about your statement 2? Surely you didn't mean to say "f has values arbitrarily close to 0" because that's a triviality. Did you mean to say that f has zeros arbitrarily close to z=0 (which would be true by Casorati-Weierstrass; however, I don't think that it can be invoked here).

Is z=0 an essential singularity? It doesn't seem so to me. Indeed, f is entire. Isn't an essential singularity needed to use Casorati-Weierstrass?

Are you trying to say that there are zeros with arbitrarily small real parts and arbitrarily large imaginary parts due the essential singularity at z=I*infinity?

@Carl Love The last line above can be improved to avoid the mathematically dubious symbolic. Indeed, no assumptions at all are needed:

simplify(exp((lhs-rhs)(sol))) = 1;
                                         2    
                             2 (-x + y(x))     
                             -------------- = 1
                                          3    
                             (-2 x + y(x))     

It would be great if simplify (or convert) had a mode specific to equations, treating the equation as a whole. (For those who are unaware, when simplify is applied to an equation, it simplifies the two sides independently (which is certainly consistent with the usage of the word simplify in high-school algebra).) Does anyone here have any thoughts about the feasibility of that? What if it were specific to cases (such as this one) where all transcendental functions can be removed, revealing an underlying polynomial or rational-function equation? What about if transcendental constants were acceptable, but we wanted to remove, if possible, all transcendental functions with variable arguments? Does something like this already exist in the vast convert network described at ?convert,to_special_function?

There's a small mistake in your final solution. If you apply exp to lhs-rhs of any equation, you should put 1, not 0, as the new right side.

@Carl Love Here's a major simplification of the above procedure:

Count:= (C::{thistype, `*`}({name, name^posint}))->
    (Statistics:-Tally @ op~ @ select)(
        type, 
        subsindets([`if`](C::`*`, op, x->x)(C), `^`, `$`@op),
        indexed
    )
:

@Carl Love Here's another way to remove the duplicates, which is more direct than Classify:

[entries](table((O-> O:-sol=O)~(SOL)), nolist);

Do you have any mathematical description of the curves such as formulas or a differential equation for which they are solutions?

@Frankoldstudent Those error messages only apply to the inline display of the worksheet on MaplePrimes. The worksheet is still attached and downloadable, and I'm looking at it now.

@Carl Love Regarding your guess, (p1-1)*(p2-1)*...*(pb-1): If n were square free, i.e., a product of distinct primes, then your guess would be the totient of n (aka, Euler's totient, Euler's phi). As I said to you about 3 months ago (here), this is nearly the opposite of the count of divisors. The totient is the count of numbers between 1 and n that are relatively prime to n.

For general positive integers n, given the same prime factorization as in the Answer above, the totient is

p1^(e1-1)*(p1-1)*p2^(e2-1)*(p2-1)*...*pb^(eb-1)*(pb-1) = 
n*(1-1/p1)*(1-1/p2)*...*(1-1/pb)

Like the number of divisors, the above can be encoded into a single line of Maple 13:

Totient:= (n::posint)-> n*`*`((1 -~ 1/~op~(1, ifactors(n)[2]))[]):

In Maple 13, it can also be done as 

numtheory[phi](n);

@Carl Love And here's the procedure that lists the proper divisors:

PropDivs:= proc(n::posint)
local F:= ifactors(n)[2], P:= op~(1,F), E:= op~(2,F)+~1, e, k;
    {seq}(`*`((P^~[seq](irem(k,e,'k'), e= E))[]), k= 0..`*`(E[])-2)
end proc
:
n:= rand(); PropDivs(n);
                        n := 22424170465
 {1, 5, 293, 709, 1465, 3545, 21589, 107945, 207737, 1038685, 
   6325577, 15306601, 31627885, 76533005, 4484834093}

There are much better ways. The number of divisors of n (including n itself) is the product of 1 more than each of the exponents in n's prime factorization. (You should prove this.) That yields this one-line procedure:

NPropDivs:= (n::posint)-> `*`((op~(2, ifactors(n)[2])+~1)[]) - 1:
CodeTools:-Usage(NPropDivs(42!));
memory used=86.52KiB, alloc change=0 bytes, 
cpu time=0ns, real time=4.00ms, gc time=0ns

                           258047999

numtheory:-sigma[0](42!) - 1;
                           258047999

A very similar procedure can actually list the divisors. I'll post later. It all starts from the prime factorization.

A trivial modification of your procedure which'll greatly improve its efficiency can be based on this proposition, which you should prove: Proposition: There's a one-to-one correspondence between divisors less than sqrt(n) and those greater.