Carl Love

Carl Love

28150 Reputation

25 Badges

13 years, 351 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@MapleEnthusiast Do you have ranges to bound all the parameters? If so, I would start by finding ranges for each matrix entry. The Maple command evalr can do this. Then try to apply the Gershgorin circle theorem.

Regarding the Collatz-Wieland formula: There are a number of generalizations of it and related spectral inequalities in this Wikipedia article: Perron-Frobebnius theorem. While these generalizations only apply to non-negative matrices, this article is extremely detailed and worth reading (although its style is a bit more colloquial than the typical Wikipedia article).

Would you please define precisely what you mean by "the largest eigenvalue (not in absolute value)"? How do you order the nonreal eigenvalues without using absolute value? (On the other hand, it's trivial to prove that 1 itself is an eigenvalue of any square matrix whose rows sum to 1, regardless of the signs, arguments, or magnitudes of the entries.) 

I think that the algebraic/polynomial approach that you've begun (i.e., finding algebraic expressions for the eigenvalues) is doomed due to the infeasibility of the computations, in particular the inequality computations.

@mmcdara You wrote:

  • Thanks acer for correcting me on the number of digits that some _d01ajc  can handle. If I have thought it there was such a limitation, that is because, while I was working on Mehdi's example, I got an error message...:

    Digits:=20:
    evalf(Int(x, x=0..1, method=_d01ajc))
    Error, (in evalf/int) expect Digits<=15 for method _d01ajc but received 23
    

There is a limitation; however, I think that acer meant that that limitation is not as strict as you may have believed. The overall computation is limited to Digits <= 15, but the integrand evaluations can be done at higher precision, as in

Digits:= 15:
Sin:= proc(x::realcons)
    Digits:= 20;
    evalf(sin(x))
end proc
:
evalf(Int(Sin, 0..Pi, method= _d01ajc));

If acer meant something substantially more general than this, I hope that he'll say. (Note that Digits is what is called an environment variable: a global variable whose value, when changed within a procedure, reverts to its previous value upon the procedure's exit.)

  • Would the plot command automatically apply evalf?

Yes, or evalhf if that happens without error. This is not a special property of Int wrt plot; plot will do it for any procedure.

  • I agree with both of you that explicitely specifying the tolerance or using epsilon option would be a better way to get the desired accuracy.

I don't know what you mean by "or" in that sentence. The epsilon option is the way to explicitly specify the tolerance.

@acer In this paragraph:

  • int(eval(A1+A2,omega=20.099752),theta=0..Pi, numeric, digits=5) 
    is not the right way to get 5 accurate digits in general, or even to force a coarse tolerance near say 1e-5.... More approriate is to specify the accuracy tolerance explicitly, instead of having it be implied by an unholy low value for the working precision.

I believe that what acer means is that it's better to use the epsilon option to int to control the precision; the digits option only controls the precision of the sub-computations. If that's what he means, then I wholeheartedly agree. (I'm only posting this Reply because he didn't explicitly mention the epsilon option in that paragraph.)​​​​​​

@MapleEnthusiast Suppose that somehow you eventually got 4 large symbolic expressions for the eigenvalues. Since it's a 4x4 matrix, this can be done by solving a 4th-degree polynomial; so, it is doable, and the expressions would only be, I guess, a few pages long (prettyprinted). Now how would you go about comparing the magnitudes of those expressions to 1? This seems to me to be a task far more complicated than getting the eigenvalues algebraically via the quartic formula.

@acer I did that to fake the unlabeled subticks. It's still not 100% what I wanted because fake subticks are the same length as regular ticks but true subticks are shorter.

Also (as I'm sure you're aware), multiplication by the degree symbol doesn't typeset properly.

@vv Yes, you're right. The part about moving mod to the end must be used with caution, and only when one knows that it'll be appropriate.

@Joe Riel There are many remarkable bijective correspondences among the partitions of an integer n. Some of these would make your mentioned changes to Iterator:-Partition unnecessary, because they'd already be covered (essentially) by Iterator:-PartitionFixedSize. The correspondences most relevant to this thread are

  1. The number of partitions of n into exactly k parts equals the number of partitions of n whose maximum part is k.
  2. The number of partitions of n into distinct parts equals the number of partitions of n into odd parts.
  3. The number of partitions of n into exactly k distinct parts equals the number of partitions of n - k*(k-1)/2 into k not-necessarily-distinct parts.

 

@David Sycamore The techniques for generating the many sequences that you ask for vary considerably. However, the techniques required for your followup questions about conditions and plots do not vary. You've been shown these techniques umpteen times by me and by other respondents. Try to learn them! Try to do it, and if you get a error, then post it and ask.

N:= 2^16:
ta:= CodeTools:-Usage([SeqA](N)):
memory used=350.04MiB, alloc change=31.00MiB, 
cpu time=5.11s, real time=4.88s, gc time=812.50ms

Cond1:= n-> ta[n]+ta[n+1] > n:
select(Cond1, [$1..N-1]);
[1, 2, 3, 4, 17, 26, 30, 64, 87, 266, 313, 358, 405, 484, 547, 
  2686, 15894, 22283, 36552, 50769, 54333, 59410, 59418, 59419, 
  59437, 59438, 59439]

Cond2:= n-> ta[n]>n:
select(Cond2, [$1..N]);
                               []

plots:-pointplot(`[]`~([$1..N], ta), symbol=point);

@Bendesarts My style for that would be

MAINPACKAGE:= module()
local XM:= 1;
export
    ZM:= 3,
    SUBPACKAGE1:= module()
    local X1:= XM;
    export Z1:= ZM;
    end module
;
    :-YM:= 2
end module
:

That is, to whatever extent that it's possible, a meaningful assignment should be made to a variable at the point that it's declared local or export. If nothing meaningful can be assigned, then leave it blank.

@Bendesarts There are two small errors in your posted code. The first is that ZM:= 3 needs to end with a semicolon (or colon). The second is that all named entities, including modules and procedures, should be declared either local or export.

@MapleEnthusiast

You can verify that your technique is correct by applying it to a numeric stochastic matrix.

If I replace LeastSquares with LinearSolve (no other changes are needed), then I get the solution for your new P in a quarter second.

@mmcdara Thank you for the vote up.

I'd like to address the "tricky accounting" mentioned by the OP in this remark:

  • note that there are often multiple copies of the least unused term, which might make accounting for them tricky. 

The way that I addressed this is to store the indices, not the entries, in the heap. The entries determine the order of the heap, but they are not in the heap.

The elegance would be enhanced a bit if Maplesoft updated the old-style table-based object heap to a modern module-based object. This would be an easy job for an intern.

@Sradharam Your derivative notation is very unusual, and I don't understand it. Would you please post the equation(s) in a more standard form?

@Dark Energy The phase planes in the worksheet that you linked are specific to systems of autonomous first-order ODEs. Your functions are neither ODEs nor autonomous. 

@Earl I had already noticed the missing colon and had fixed it. The memory use that I reported is for the GUI alone, not for the kernel, and that number is only visible through Windows Task Manager or a similar external application; you can't see it on the status bar or through any Maple command (that I'm aware of). This may be a Maple 2021 bug. I've already noticed that the rendered versions of 3D plots displayed in Maple 2021's GUI are much larger than those for Maple 2020. (This has nothing to do with the number of points computed via, say, the grid option to plot3d; it only affects the rendering.) The fact that I have a QHD display may have something to do with this.

First 122 123 124 125 126 127 128 Last Page 124 of 711