When we use sim9 this fork calls in sim9_single to create a single random matrix for plotting. Unfortunately, however, sim9_single does not give a random matrix, it just gives a matrix that is a single step in the Markov chain removed from the original matrix. This is why there are only minor changes that show up in the simulated matrices (which you highlighted). For some matrices there may be no change at all because the randomly selected pair of rows in sim9_single don't contain any swappable elements.
We could correct this by adding the burn in to sim9_single, but that is incredibly slow and inefficient for large matrices to redo the entire thing just to get a single matrix out for plotting. What I would suggest is the following:
When you create nullmodObj, add a new data structure to it: nullmodObj$Random.Matrix
Place into this structure the last data matrix that is created by whatever algorithm you are using.
Now for the plotting functions, use nullmodObj$speciesData and nullmodObj$Random.Matrix.
Now we don't need to awkwardly fork out a special exception for sim9. Regardless of what the simulation algorithm is, the object will always contain the matrix of the observed data (nullmodObj$speciesData) and one matrix of simulated data (nullmodObj$Random.Matrix). These are the two things we need to create the "cooc" plot. We also use them of course for all algorithms where there is a graphic type that shows the observed versus the simulated data. So this will work in niche overlap, size overlap, and all future modules.
It also seems cleaner to me because all of the simulating is done in only one place, and then we use the results of that simulation to calculate summary statsitics and create graphs.
Unfortunately, working with objects and classes is a bit above my R-skills, so I would be grateful if you could implement this. I do think we will need this in place before we release the package. About 98% of the co-occurrence simulations are made with sim9 (I will probably switch that to the default), and the current graph is going to raise eyebrows and cause people to suspect there is a flaw in the algorithm.
There is one small fly left in the ointment:
When we use
sim9this fork calls insim9_singleto create a single random matrix for plotting. Unfortunately, however,sim9_singledoes not give a random matrix, it just gives a matrix that is a single step in the Markov chain removed from the original matrix. This is why there are only minor changes that show up in the simulated matrices (which you highlighted). For some matrices there may be no change at all because the randomly selected pair of rows insim9_singledon't contain any swappable elements.We could correct this by adding the burn in to
sim9_single, but that is incredibly slow and inefficient for large matrices to redo the entire thing just to get a single matrix out for plotting. What I would suggest is the following:nullmodObj, add a new data structure to it:nullmodObj$Random.MatrixnullmodObj$speciesDataandnullmodObj$Random.Matrix.Now we don't need to awkwardly fork out a special exception for
sim9. Regardless of what the simulation algorithm is, the object will always contain the matrix of the observed data (nullmodObj$speciesData) and one matrix of simulated data (nullmodObj$Random.Matrix). These are the two things we need to create the "cooc" plot. We also use them of course for all algorithms where there is a graphic type that shows the observed versus the simulated data. So this will work in niche overlap, size overlap, and all future modules.It also seems cleaner to me because all of the simulating is done in only one place, and then we use the results of that simulation to calculate summary statsitics and create graphs.
Unfortunately, working with objects and classes is a bit above my R-skills, so I would be grateful if you could implement this. I do think we will need this in place before we release the package. About 98% of the co-occurrence simulations are made with
sim9(I will probably switch that to the default), and the current graph is going to raise eyebrows and cause people to suspect there is a flaw in the algorithm.Thanks!
Nick