#58 Weighted rules miscalculate negative numbers

[Ryan]

I have tried using the NW configuration of largerthanlife, however it appears that -1 counts as "equal to all numbers", because with the rule R3,C0,M1,S19..19,B19..19,NW00000001000000000100810001000000040404000001810482048101000004040400000001008100010000000001000000, it doesn't matter what you replace B19..19 with, it will always birth cells at the positions indicated by 81. I have tested this for the values 1-19 and i'm pretty sure one number does not equal 19 different numbers. With this particular weight, the only numbers that birth additional cells are 1 and 4 which give patterns that mostly match my intent, with the notable exceptions being those aforementioned -1 cells. This is a critical bug with the weights: negative values pass all equality checks. Furthermore i don't quite understand how "hex 80 + x means -x" makes sense from a computing standpoint, as it should be far far easier to just use signed integers (-3 = 256-3 = 253, hex FD), but i don't particularly care as long as it works. The reason, by the way, for the S and B rules is because i was performing the recommended neighborhood check, and running through all the integers, until i noticed an issue.

[Chris Rowett]

This was a bug related to negative neighbour counts for Weighted neighborhoods. I've committed a fix to the repo.

Thanks for reporting!