Heartbeats

Are you working in Ruby and need to do some asynchronous work? Like, you're waiting for an input but also want your program to, say, be doing other calculations on the side, or to stop waiting if your user is too slow?

One of the first programs I made this year was an emulation of the game Set, which a certain element of speed to it - players try to make sets before each other (or before the computer does, in this version).  Here was my solution for allowing the terminal to continue displaying available cards while *also* waiting for the player to input a set while *also* putting a clock on the player's actions and letting the computer jump in with its move when time was up:

        begin
status = Timeout::timeout(rand_time) do
# status = Timeout::timeout(rand_time) do
DisplayBoard.run(board)
puts "Choose your cards: "
guess = gets.chomp
if guess
converted_guess = GuessConverter.run(board, guess)
PlayerTake.run(game, board, winning_sets, converted_guess)
end
end
rescue Timeout::Error
ComputerTake.run(game, board, winning_sets)
end
GameTurn.run(game)

This method works...but it's also got some downsides. Namely, that rescue statement deliberately introduces an error if it times out.  In a simple terminal application like mine, this wasn't a problem - that's basically what I wanted it to do.  However, this can cause lots of problems in other contexts, like running a web app.  Basically, Timeout is a bomb that will remove infected tissue when sometimes a scalpel is all that is needed.

Enter Heartbeats.

Basically, instead of telling Ruby to do two things at once, which it's bad at, you can tell Ruby to do things really fast at the same time (which it's good at).  Here's how to do it:

1. Tell your machine to be doing Task A (say, waiting for a player's input) with a timer loop.

2.  Add Task B to your loop (say, calculating a new game state or just counting the overall time that's been spent on Task A).

3.  Add a check at the end of your loop for Task A and add a check for Task B.

Your Ruby program will now do two things, indistinguishably from the human eye, at the same time.

checks = 0
timer = EventMachine::PeriodicTimer.new(5) do
DisplayBoard.run(board)
puts "Choose your cards: "
guess = gets.chomp
if guess
converted_guess = GuessConverter.run(board, guess)
PlayerTake.run(game, board, winning_sets, converted_guess)
end
checks += 1
if checks > 10000
timer.cancel
end
end
GameTurn.run(game)

Tada!

Here's a link to a white paper from Microsoft about the creation of this idea in network computer and its advantages if you want some more advanced reading.



Comments

Post a Comment

Popular posts from this blog

The Sorting Hat

Image
Here's a lesson about the difference between theory and practical applications. Everyone knows about  bubble Sort  and  merge Sort  - they're probably the first two sorting algorithms you learned.  Everyone also knows that (1) bubble sort sucks and (2) this is due to the fact that its average time complexity is O(n^2), aka the worst time complexity.  It even generally performs worse than things like insertion sort and  selection sort , the "a D- is still a passing grade" of sorting algorithms. While all these things are true, there's a more important truth: always test your code. While reading  The Imposter's Handbook by Rob Conery  the other day and flipping through the comparison sort algorithms he provides, I decided, Why not actually test out this code?   And, the  speed test demon  that I am, my test involved sorting out his [23,4,42,15,16,8] array one million times with bubble sort and with merge sort, and I got this res...
Read more

Kadane's Algorithm

Imagine it is 1977.  You do not have a degree in computer science.  You have not spent months grinding leetcode.  You are given a algorithm problem that a decorated mathematician has already created what looks like an optimal solution. And then in less than a minute you come up with a better answer. You are  Jay Kadane , and the problem that you have solved is the maximum subarray problem. The maximum subarray problem gives you an array of numbers and asks you to pick out the subarray with the largest sum.  The problem is trivial if all the numbers are positive: [ 1 , 5 , 1 , 3 , 2 ] <- the largest subarray is obviously the entire array But what if you've got some negative numbers thrown in there? [ 1 , 5 , -1, 3 , - 2 ] <- sure, you don't want the negatives. But isn't taking the -1 worth the +3? A brute-force solution materializes pretty easily: just create every subarray and find the biggest sum: [ 1 ] = 1 [ 1 , 5 ] = 6 [ 1 , 5 , - 1 ] = 5 ...
Read more

Loose Equality, the Null Operator, and Other Oddities

 Here's a fun bit of code to run: console . log ( '0.5' == 0.5 ) //evaluates to true console . log ( '0.5' === 0.5 ) //evaluates to false The first equality statement is what's known in JavaScript as "abstract equality comparison", which people usually refer to as "loose equality."  Loose equality compares objects only after doing a type conversion - so even though '0.5' is a string and 0.5 is a number, JavaScript sort of jams them together and says "sure, good enough."  It's weird, but convenient sometimes when dealing with data that's really (in an abstract sense) numbers but could come through the pipes as either a number or a string. People have written surprisingly long algorithms to precisely define what  abstract equality  and  strict equality (aka, normal equality)  mean in JavaScript and other languages that adhere to the ECMAScript standards.  But for our regular usage, things that are to people the same ...
Read more