# matrix is found singular over CC, nonsingular over CDF

I am trying to take the inverse of complex valued matrix where every entry is either +/-1,+/-i,or 0. The matrices are quite large and I am getting substantial rounding errors when I construct the matrix using "matrix(CDF,array)" and then take the inverse, but I still get an output.

When I construct the matrix using the same array but using "matrix(CC,array)" and then take the inverse I get this error: ZeroDivisionError: input matrix must be nonsingular

I am confused because the array when I use "matrix(CC,array)" is exactly the same as the array when I use CDF, however "matrix(CDF,array)" is nonsingular and the function inverse works. Why is this happening and is there another way I can avoid large rounding errors when taking the inverse?

I hope this is enough detail. I'm not really sure how to provide an example of this error occurring since the smallest example of the array I am working with is still quite large (52x52) and I haven't been able to get this error to occur with smaller simpler arrays.

This is the encoded matrix over the Gaussian Integers - I had been using QQbar() to run it since it worked to get the inverse.

`b = [286102294921876, 178813934326175001, 69849193096160908206250, 27284841053187847167978515625, 10658141036401502788066894531250000, 179100036621093756, 111937522888183596880, 69960951805114746112500, 43725594878196716328140625, 27343048714101314544736328125, 17080310499295592308075000000000, 10675194062059745192527954101562500, 1716613769531255, 112652778625488296880, 44004991650581359960953125, 17189449863508343696746875000000, 63948846218409016728401336669921875, 895500183105468780, 559687614440917984400, 349804759025573730562500, 218627974390983581640703125, 136715243570506572723681640625, 85401552496477961540375000000000, 53375970310298725962639770507812500, 8583068847656275, 563263893127441484400, 85947249317541718483734375000000, 319744231092045083642006683349609375, 4477500915527343900, 2798438072204589922000, 1749023795127868652812500, 1093139871954917907959375000, 683212419971823692323242187500, 427007762482389807701875000000000, 266879851551493629813198852539062500, 42915344238281375, 2816319465637207422000, 1100124791264533997803125000, 429736246587708592418671875000000, 1598721155460225418210033416748046875, 22387504577636719500, 13992190361022949610000, 8745118975639343264062500, 5465699359774589539796875000, 3416062099859118461616210937500, 2135038812411949038509375000000000, 1334399257757468149065994262695312500, 35762786865235000, 13969838619232179688125, 5456968210637569433595703125, 2131628207280300557632452392578125, 1332267629550187848508377075195312500]`

The issue I'm now having is that I expected the inverse this matrix to look much different - as well as the determinant to be much larger.

Thanks for adding the encoded example. It seems to reveal several bugs.

What remains to do now:

What are the bugs? I cannot reproduce the ZeroDivisionError in Sage 9.3. The matrix is well-conditioned, so I would expect inversion to work without much problem.

Note that your matrix is quite sparse, so you can use

`.dict()`

to write it more directly asGood point about the

`dict`

approach since the matrix is quite sparse.I also cannot reproduce the

`ZeroDivisionError`

but by exploring the example in my answer I isolate three things I think are bugs.Certainly the fact that, after changing ring to

`CC`

, the matrix has determinant`512.0*I`

instead of`2`

is a bug.Oh, I had missed that part of the answer. Indeed, the incorrect determinant over

`CC`

looks quite bad (in most cases,`CDF`

is a better choice), but I think this boils down to numerical issues. The determinant is computed via`._charpoly_df()`

, the division-free implementation. I am not familiar with the algorithm, but I expect it computes products with 52 factors. At least, the computation attains intermediate values larger than`1e19`

, which is a problem if the precision is not increased.Alternatively,

`.determinant(algorithm='hessenberg')`

gives correct results (if the determinant has not already been cached). Actually, I have observed before that the hessenberg implementation can be much faster as well.