pearselab / r-world-Wolflab

r-world-Wolflab created by GitHub Classroom
0 stars 0 forks source link

Square step #1

Open Wolflab opened 8 years ago

Wolflab commented 8 years ago

Square Step - Sounds like a dance. Line 16 and 17 of my English code attempts to explain my question. When I am calculating the value for an edge mid point, I had been assuming that this is the mean of THREE other points: the two corners plus the center of the MATRIX in question. If this is an edge that is internal with respect to the full landscape, do I need to include the center point of the adjacent square? In other words, mean of FOUR points: the two corners and center of A1 AND the center of matrix A2. That would complicate things a bit. Just need to know because it affects my program design

willpearse commented 8 years ago

Never thought I'd be dancing with my computer...

Hopefully what we've discussed makes this make a bit more sense. Let me know if not...

Wolflab commented 8 years ago

Yes - helped lots. My algorithm was going subsquare by subsquare and running diamond.step then square.step on each. Looping through ALL subsquares on diamond.step, then through ALL subsquares on square.step makes much more sense. I might ask you to check my English algorithm, before I convert to R. r maybe I'll do it in French first? Thanks

Wolflab commented 8 years ago

The matrix size has to be more than odd. It must remain odd all the way down the hierarchy of ever decreasing squares. So it must be an odd number raised to an odd number. Just talking to my duck.

willpearse commented 8 years ago

Quack.

Wolflab commented 8 years ago

That worked. Thanks

Wolflab commented 8 years ago

OK. So I decided to keep the current structure, feeding the matrix into each function returning the modified version. As far as I can tell, that won't be too memory inefficient. Now I am trying to make my square step work in all cases (including subsets). Currently it only works on the first "cycle" - the largest square, where the middle edge values are the mean of two corners and ONE center value. The general function needs to work on subsquares at the periphery (as in previous sentence) but if the subsquare is central then the middle edge value must now be a mean of FOUR points (now adding the center point from an adjacent subsquare). Does that make sense? I know I can do this with some complex "if" statements to test for the above conditions. But I am lazy, I mean I want simpler code that is easy to read, so I prefer to TRY to calculate the new value from the mean of FOUR, but if one of those values is out of bounds of the main terrain square then I simply ignore that value. Looks like I can do so for indices higher than max rows, but negative indices do bad things. Is there a simple way to use an out of bounds index to take care of this? Or should I start generating lots of "if" statements? Thanks

Wolflab commented 8 years ago

All the matrix index tutorials I could find were showing how to correctly index, not how to actively use an out of bounds error.

willpearse commented 8 years ago

Ah, right - yes, there is. This is interesting to me, because it's precisely this problem that led me to using my rather around-the-houses methods for calculating things before.

Anyway, the general approach is to make a list of potential co-ordinates, and then filter out the ones that aren't valid. You'll find having a function like this will come in handy later when plants/herbivores are dispersing as well. Something like:

valid.cells <- function(pot.rows, pot.cols, nrow, ncol){
    good.rows <- pot.rows > 0 & pot.rows <= nrow
    pot.rows <- pot.rows[good.rows]
    pot.cols <- pot.cols[good.rows]
    #...the same thing for columns...
    #...some sort of return statement
}

...should do the job. Does that make sense? Do you also see why I'm making good.rows before doing any subsetting? I use this trick a lot, so I think it's worth learning it - there could be better ways, and I suppose there always are :-(