Carl Love

Carl Love

21288 Reputation

24 Badges

8 years, 254 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity

These are replies submitted by Carl Love

@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, 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 (-x + y(x))     
                             -------------- = 1
                             (-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)(
        subsindets([`if`](C::`*`, op, x->x)(C), `^`, `$`@op),


@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 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) = 

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 


@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:
memory used=86.52KiB, alloc change=0 bytes, 
cpu time=0ns, real time=4.00ms, gc time=0ns


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

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.

@vv As is almost always true in Maple, the = 0 is not needed; (lhs-rhs)(mysol) is sufficient.

@T K Burch If you have x and data in separate column vectors X and Y (and, as before, is an expression with a single free variable, x), then you can do this:

plot([F, <X|Y>], x= (min..max)(X), style= [line, point])

Column is the default vector orientation. If for some reason you have row vectors, let me know. The <...|...operator is a columnwise matrix constructor.


@T K Burch So, this small thing of the punctuation at the ends of statements makes a big difference in Flow. In Maple, the colon means to suppress the output. The semicolon means to not suppress it, and is not required unless there's an immediately following statement.

If Flow doesn't like the punctuation, it should give a normal error message about it, not the weird message that you reported. STATSEQ stands for "statement sequence", which indicates that it was expecting another statement after the punctuation, which is understandable. subsindets stands for "substitute the indeterminants". It's one of the most important low-level Maple commands, but it's a command for a programmer, not an end user.

So, it seems like the Maple Flow input is being processed by regular Maple code. That's useful to know. 

@nm Edgardo used the flat option to subsindets, and I did not. That's the cause of the difference you're seeing. Flat just means not recursive, which is the default. You'll need to decide which you prefer. I don't think that using the flat option is completely correct in this case: It's only performing your desired simplification to the outermost structures of the appropriate type. Edgardo should clarify his reason for doing this.

@Carl Love In the case you present in the PDF, all the items that are transformed are products of exp and sqrt (and possibly other factors). Thus they are all of type `*`. Thus we don't need to consider "naked" sqrts, those that aren't part of a `*` structure. Thus we don't need the _O or _1 factors. The procedure code immediately above simplifies to

MySimp:= expr-> 
    local rad:= anything^fraction;
                e-> andmap(
                    [rad, {specop(exp), specop(exp)^anything}], 
            local d:= ilcm(map2(op, [2,2], indets(e, rad))[]);


1 2 3 4 5 6 7 Last Page 2 of 593