Please provide a small example of what you consider to be a "bidiagonal" matrix. I've heard of tridiagonal, but I don't think that bidiagonal is well-defined. If a matrix has only one diagonal other than the main diagonal, then its eigenvalues are obvious: They are just the main diagonal.

@Kitonum I believe that the OP is refering to something like this:

restart:
M1:=146996733613391:
M2:=1348471408813:
teks:= CodeTools:-Usage(numtheory[cfrac](M1/M2,  'quotients'));

memory used=23.62MiB, alloc change=22.90MiB, cpu time=31.00ms, real time=28.00ms

31 ms seems to me to be an outrageously long time for such a trivial computation.

@marc sancandi wrote:

PS : For Carl Love :  at x=L1 the OP has not written boundary conditions (as you said) but just Temperature and heat flux continuity conditions

Although it may not be a "boundary condition" in the sense of a true physical boundary or in your textbook senses, Maple is counting any condition that uses a specific value of x as a boundary condition. Three different values of x are used. That is the one and only reason for the error message. The lack of a Dirichlet boundary condition is irrelevant to Maple at this point in its analysis of the problem. That's all that I was saying.

Maple's numeric PDE solver is quite limited. You've specified boundary conditions at three x values: x=0, x=L1, x=L1+L2. The solver can only handle boundary conditions at at most two x values.

@one man I guess that you're refering to Draghilev's method. It would be great to have a general procedure for that in Maple.

@vv It's feasible to do the 2x2 case for moduli q up to about 64.

I'd forgotten that Iterator was now available in out-of-the-box Maple. It's great that there's finally a library alternative to combinat:-cartprod.

As far as I know, RootFinding:-Isolate is the only sure way to get (approximations of) all of the solutions for a polynomial system.

@Kitonum You've come up with a brilliant new way to do Cartesian products in Maple! There hasn't been a new good one (that I've seen) in nine years. You should add this procedure as a comment to this 2007 thread: Cartesian product of lists. Maybe Joe Riel will incorporate it into the post. The parameter Expr should be typed uneval instead of algebraic. Then you won't need the unevaluation quotes, and your NestedSeq will be more like regular seq.

However, your code above is about 50% slower than my most recently posted for loop. I think that in general a for loop is faster than a seq when then seq has a significant percentage of NULLs. Still, your procedure will be great for cases where there's not a significant percentage of NULLs.

@vv Yes, using LinearAlgebra:-Determinant is faster, and LinearAlgebra:-Modular:-Determinant is even faster than that (by a little bit). Here's the modified code:

restart:
macro(LA_M= LinearAlgebra:-Modular):
Wordsize:= integer[kernelopts('wordsize')/8]:
CartProdSeq:= proc(L::seq(list), $)
local S,j;
    eval(subs(S= seq, foldl(S, [_i||(1..nargs)], seq(_i||j= L[j], j= 1..nargs))))
end proc:

PRIME:= 2:  n:= 4:

for M in CartProdSeq([CartProdSeq([$0..PRIME-1] $ n)] $ n) do
     if LA_M:-Determinant(PRIME, LA_M:-Mod(PRIME, Matrix(M), Wordsize)) <> 0 then
          GROUP[cat("", op~(M)[])]:= [][]
     end if
end do:

GROUP:= [indices(GROUP, nolist)]:

@acer Yes, that's my current setup almost exactly: Maple 16.02, 64-bit, Windows 7, Standard GUI.

@Stavros Sorry, I needed to use Det instead of Determinant. No packages are needed. Here's the corrected code:

restart:

CartProdSeq:= proc(L::seq(list), $)
local S,j;
    eval(subs(S= seq, foldl(S, [_i||(1..nargs)], seq(_i||j= L[j], j= 1..nargs))))
end proc:

PRIME:= 2:

for M in CartProdSeq([$0..PRIME-1] $ 16) do
     if Det(Matrix((4,4), M)) mod PRIME <> 0 then GROUP[cat("", M[])]:= [][] fi
end do:

GROUP:= [indices(GROUP, nolist)]:
nops(GROUP);

     20160

@acer That's great, especially the resolution. What does the color indicate? Is it the number of attractors per r value?

@Joe Riel I can't reproduce it either anymore. But I reproduced it about a dozen times before posting.

However, there's still the issue of the args being reported as a large integer by trace. That's not a big concern, but I wonder if it's happening for you.

I just finished the code and posted it to the "Bifurcation in Maple" thread with some very interesting plots.

@Joe Riel There are often requests here for some way to circumvent automatic simplification for display purposes. Your 3/3 shows that you have done this. I've also checked that it is possible to make the denominator 0. These forms seem to be stable. I got 3/3 + 3 = 12/3, and 1/0 + 1 = 1/0.

I have often wished that evalindets had an option recurse which would cause it to use eval[recurse] instead of regular eval.