First of all, in your scenario, "16 is a magic number." You envision that there could never be more than 16 so you conceive of the problem as being solved bya 16x16 matrix, yet this is almost certainly not the "correct" or "appropriate" representation.
The more-appropriate representation, in the database, would probably be a large table of rows consisting of, e.g. {id_of_participant_who_sez, participant_1, participant_2, I_think_probability_is}. This is how the data would be stored, and you observe that the "16" number is completely gone. There is now no limit on the number of participants... none whatsoever.
The results can now be evaluated by a query such as SELECT participant_1, participant_2, AVG(I_think_probability_is) ... and once again, those results come out as a big long list, not a matrix. So your display code now has to read that list, populate a (say...) 16x16 matrix, and display the matrix in tabular form.
Lots of n00bies make this mistake and create table structures with so-called "repeating fields" with 16 slightly-different names. They build apps that absolutely cannot handle "17" without being re-designed. And, they short-circuit the powerful grouping and querying abilities of SQL.
Almost always, the "appropriate structure for representing your data" is not "how the end-user would like to view it."