Skip to main content

Checking surrounding tiles

If you want to check the surrounding tiles in a series of array.

Instead of using this:

if input[index_r-1]
            result += 1 if input[index_r-1][index_e-1] && input[index_r-1][index_e-1] == "*"
            result += 1 if input[index_r-1][index_e] == "*"
            result += 1 if input[index_r-1][index_e+1] && input[index_r-1][index_e+1] == "*"
          end
         
          result += 1 if input[index_r][index_e-1] && input[index_r][index_e-1] == "*"
          result += 1 if input[index_r][index_e+1] && input[index_r][index_e+1] == "*"
         
          if input[index_r+1]
            result += 1 if input[index_r+1][index_e-1] && input[index_r+1][index_e-1] == "*"
            result += 1 if input[index_r+1][index_e] == "*"
            result += 1 if input[index_r+1][index_e+1] && input[index_r+1][index_e+1] == "*"
end

Please use this

[input[x-1][y-1], input[x-1][y], input[x-1][y+1], input[x][y-1], input[x][y+1], input[x+1][y-1], input[x+1][y], input[x+1][y+1]].count('*')

Comments

Popular posts from this blog

Problem Solving - Refactored

I am going to outline how I approach problem solving. The relative importance and the amount of effort/time required for each is stated as a percentage beside each topic. I borrowed some idea from George Polya's How to Solve It Thoroughly Understand the Problem (30%) When encountering hard problem , you need to deeply understand the problem at hand. Take a paper and list down all known facts and data and what the question is trying to find. Sketch out the problem if applicable. Visualize the problem in your head. A lot of times, we only have to understand the problem well, then the solution will obvious. Have a Plan (20%) You need to have an outline of how you are going to tackle the problem. You need to have a logical pathway that will ultimate produce outcome (nothing to do with coding syntax yet). Without a plan, you are just randomly poking around and got lucky. No hard problem ever gets solved without a plan. Plan using pseudo-code, pen & paper or flowchart. Use wh...

Static vs Relative vs Absolute vs Fixed

Static: the default position. Everything starts from top to bottom nicely according the document flow. Relative: still within normal flow of document. But accept offset position, relative to its original document flow position Absolute: out of normal flow. It doesn't interact with elements around it anymore. The reference point will be parent element that has relative positioning, if not, reference body element. Accepts offset position Fixed: out of normal flow. The element sticks to a corner of the page even if user scrolls. Reference the windows view.

My First 'Not Yet'

I took the 219 assessment about 2 months ago. Kevin administered the test. It was a problem solving question whereby you are required to solve a problem using javascript while talking through the steps. The problem looks relatively simple, so I wrote some test cases and pseudo-code. I then proceeded to code the solution. 30 minutes passed, I was pretty confident my solution was right. It solve 5 of the test cases I wrote. I thought I nailed it. I decided to add in a few test-cases just because I have some time left. One of the test cases doesn't produce the required output. It was alright, this kind of things happens sometimes. I decided to tweak my code here and there, thinking it will produce the required output for that particular test case. To my horror, it didn't. Another 15 minutes passed. I begin to panic a little. I remember asking Kevin 'do I have to time myself for the test'. It was funny now when I think back. Of course I do, it was a 1 hour test. It tu...