# Error in Weyl character formula computation.

I need someone with a keen eye for errors. I am trying to use the Weyl character formula for the symplectic group Sp$(4,\mathbb{C})$ on certain matrices coming from 2x2 quaternion matrices. Summing these traces in my case should give an integer output (since they are supposed to represent dimensions of spaces of modular forms)...however I am not getting integers.

In particular I have a quaternion algebra (which for now is just Hamiltons quaternions) and a maximal order. The units of this maximal order (which form the list A) are being used to create 2x2 diagonal and anti diagonal matrices, forming a group G. In order to apply Weyl's character formula I am using a homomorphism into Sp($4,\mathbb{C}$) to get 4x4 complex symplectic matrices. The commands quat1, quat2, quat3, quat4 and Mat do this below (the maths is correct, we do actually get a symplectic matrix so there is nothing to worry about on that side of things). The set Gamma1 below is the 4x4 version of G lying inside Sp($4,\mathbb{C}$).

In order to use the Weyl character formula I must plug two non-conjugate eigenvalues from each element of Gamma1 into a certain rational function which I define by the use of P and Weyl. This part of the program is correct since I used it in a previous sheet for other dimension calculations.

I then get the dimension by summing these values and dividing by the number of elements in Gamma1. However I am getting rational number outputs when I should be getting integers. Can anyone see the errors?

MY CODE:

with(LinearAlgebra):

with(linalg):

quat1:= proc(a::list); a + a*I; end proc:

quat2:= proc(a::list); a - a*I; end proc:

quat3:= proc(a::list); a + a*I; end proc:

quat4:= proc(a::list); -a + a*I; end proc:

Mat:=proc(a::list,b::list,c::list,d::list); Matrix([[quat1(a), quat1(b), quat3(a), quat3(b)],[quat1(c), quat1(d), quat3(c), quat3(d)],[quat4(a), quat4(b), quat2(a), quat2(b)],[quat4(c), quat4(d), quat2(c), quat2(d)]]); end proc:

A:=[[1,0,0,0],[-1,0,0,0],[0,1,0,0],[0,-1,0,0],[0,0,1,0],[0,0,-1,0],[0,0,0,1],[0,0,0,-1], [1/2,1/2,1/2,1/2],[1/2,1/2,1/2,-1/2],[1/2,1/2,-1/2,1/2],[1/2,1/2,-1/2,-1/2],[1/2,-1/2,1/2,1/2],[1/2,-1/2,1/2,-1/2],[1/2,-1/2,-1/2,1/2],[1/2,-1/2,-1/2,-1/2],[-1/2,1/2,1/2,1/2],[-1/2,1/2,1/2,-1/2], [-1/2,1/2,-1/2,1/2],[-1/2,1/2,-1/2,-1/2],[-1/2,-1/2,1/2,1/2],[-1/2,-1/2,1/2,-1/2],[-1/2,-1/2,-1/2,1/2],[-1/2,-1/2,-1/2,-1/2]]:

Gamma1:= [seq(seq(Mat(A[i],[0,0,0,0],[0,0,0,0],A[j]),i=1..24),j=1..24), seq(seq(Mat([0,0,0,0],A[i],A[j],[0,0,0,0]),i=1..24),j=1..24)]:

EV:=[seq(Eigenvalues(Gamma1[i]), i=1..1152)]:

Q1:= proc(i); if (conjugate(EV[i]) - EV[i] = 0) then EV[i] else EV[i] end if; end proc:

Q2:= proc(i); if (conjugate(EV[i]) - EV[i] = 0) then Q1(i) else EV[i] end if; end proc:

Weyl:= proc(m::integer,n::integer); simplify((a^(2*m+2*n+4)*b^(m+2*n+3) - a^(2*m+2*n+4)*b^(m+1) - b^(m+2*n+3) + b^(m+1) - a^(m+2*n+3)*b^(2*m+2*n+4) + a^(m+1)*b^(2*m+2*n+4) + a^(m+2*n+3) - a^(m+1))/((a^2-1)*(b^2-1)*(a*b-1)*(a-b))); end proc:

P:=proc(x,y,m,n); subs(a=x,b=y,b=y,Weyl(m,n)/(a^(m+n)*b^(m+n))); end proc:

dim:= proc(m::integer,n::integer); simplify(expand(sum(P(EV[j], Q2(j),m,n),j=1..1152)))/1152; end proc:


Or would you want to use add instead of sum inside procedure P? Note that add has special evaluation rules and so will not try to compute Q2(j) for symbolic (not yet an integer) j. For finite summation, there can be difficulties with premature evaluation of function calls like Q2(j) inside a sum call. Hence for literal finite summation you might be safer with add. I haven't tested whether that a problem for your code.
Inside procedure Weyl, as marked up here, there are subexpression such as ((a^2-1)(b^2-1)(a*b-1)*(a-b)) where there are no multiplication signs between some of the bracketed terms. Without explicit * symbols between the touching backets that will get parsed as function application rather than as multiplication, for 1D input. (As 2D Math input it could have either * to denote multiplication explicitly or a space to denote multiplication implicitly. I suspect that your code is 1D text. The explicit * covers both forms, and is thus most prudent.)