Often a programming task gets more difficult as one delves into its details. On the other hand, sometimes math comes to the rescue! Douglas wondered if we could implement a kind of lasso mouse move that would enable a user to select an item to move too. This enables silent, "click-less" navigation. I found various mouse gesture scripts on the net but no simple javascript code to achieve the task. How hard could it be?

First there is the question of continuity. When operating systems provide mouse position data it doesn't arrive as a list of adjacent (x,y) pixels. Instead, the (x,y) samples can be very far apart, especially if browser is doing other CPU intensive work. The solution seemed fairly straightforward: The only way to interpolate a continuous path would be to scale down the collected mouse positions until they were pretty much adjacent. By dividing the sample mouse positions by around 20, one can get a pretty continuous path that represents medium to large mouse motions pretty well.

Mouse Coordinates:

The dynamic example above essentially shows the mouse coordinate data scaled down and then displayed on the large grid. (Collision detection is active simply as a way to clear the grid).

Now the question becomes "how does one detect that a path has closed back on itself?" The completion of the lasso motion is essentially a collision between the current motion and the path that has been laid out earlier. So this involves a match of the current scaled-down mouse position to a previously scaled-down position. I tried that and discovered the next problem. The current position was matching to the immediately previous mouse position which also scaled down to the same point. So a metric of some kind was needed to measure the lenght of the line, or the recency of the points that had been laid down in order to determine if a loop was involved, or just points at the end of the same segment.

If one could record how "old" a point was, that might do the trick. "Old" triggered the idea of looking at the mouse motions in 3d, with the third dimension being time or elevation. The mouse traces a path on the ground, but as time goes by, a second point directly above is represented ascending upwards. Whenever the mouse recrosses its path back on the ground, there is a vertical distance between the ground point and sky point. Only when this distance is great enough should we assume the line has looped back on itself.

What seems to work pretty well is to start a counter, and for each new scaled down mouse (x,y) we encounter, we record a counter "depth" for that position. If another mouse coordinate scales down to a previously encountered position, we ignore that if the current counter value and the counter value of the previoius position are too close. This is essentially ascribing a length value to the path between the two.

Note that the algorithm is fairly forgiving when it comes to minor steps back along the path one has drawn. It ignores a shaky hand so to speak.

We did sneak one other feature in the demo above that limits the path length. The geeks out there will recognize the behaviour we now have as remeniscent of a certain game: Centepede! We need to limit path length since otherwise if a user moves his/her mouse around the screen enough, they'll make a lasso when they don't really want to. Only recent mouse moves should be measured for the lasso effect. So:

• Any time there is a colision, we drop all the mouse data we've collected, and start over.
• We drop any data points which are over (say) 20 increments away from current counter value.

The javascript and jQuery code

Future Enhancements

A simple future improvement would be to add sensitivity to the direction of the lasso effect, clockwise or counterclockwise. As well we could return the width and height of the lasso, and its central (x,y) coordinate, and all the objects it touches, the ones inside it, etc...

As Learning Point's Technology Chief, I provide clients with solution advice and software implementations for their websites. My experience spans nearly two decades of building applications and website content management systems for corporate, government, and non-profit clients. Much of my web work was carried out over a decade as Director of Application Development at Communicopia.com, where I led the technical development of hundreds of successful projects, large and small. Formative years in Silicon Valley and an Honours BA in Cognitive Science have enabled me to tackle a wide variety of creative challenges with gusto!

Douglas Grant has worked as project manager, information architect, and strategic consultant since developing the BC Open Learning Agency's (www.ola.bc.ca) first Web-based course in 1994. Early industry experience also included his roles as User Interface/Usability and Documentation Team Leads for NCompass Resolution (www.ncompasslabs.com), which Microsoft acquired and which now forms the basis of its collaboration and document sharing content management system, Sharepoint.

Douglas earned an MASc (Interactive Arts) from Simon Fraser University's School of Interactive Arts and Technology (www.siat.sfu.ca/grad/welcome/) in 2006 and has worked with Damion over the last decade. His recent work includes IA and wireframing, with Publicis Canada (www.publicis.ca), for The Heart & Stroke Foundation of BC & Yukon's Quittersunite.com (www.quittersunite.com) social networking community to support smoking cessation and strategic consultation for Pinc's (www.pincgiving.com) online video network providing an online platform for socially responsible fundraising initiatives.

I like this simple game example because it encourages us to question and test our intuitions. It shows how hard it is for most of us to think about even simple logic puzzles that involve negation and probability.

In her September 9th, 1990 Parade Magazine "Ask Marilyn" column, Marilyn vos Savant created quite a stir when she advised on the proper course of action in a "Let's Make A Deal" type of game scenario sent in by a reader. Thousands of people - including hundreds of mathematically inclined academics - wrote in to say that her answer was wrong, and some even lambasted her for leading so many astray.

Suppose you're on a game show, and you're given the choice of three doors. Behind one door is a car, behind the others, goats. You pick a door, say number 1, and the host, who knows what's behind the doors, opens another door, say number 3, which has a goat. He says to you, "Do you want to pick door number 2?" Is it to your advantage to switch your choice of doors?

Craig. F. Whitaker, Columbia, MD

Try the game out to see what you think ...

Games 0	Won 0	Lost 0
Restart   Reset   Simulate: Switch   Hold

1) Select a door; then host will select a goat door.
2) Now decide whether you want to select the remaining door instead. Click on your final door of choice.
3) To play again, click on any door, or press "Restart"

Try a "switch" or "hold" strategy simulation button which plays the game fifty times according to the given strategy!

To switch or not to switch? Marilyn said yes, always switch, since that way you will win two-thirds of the time! You may find the easiest way to understand this is by taking on the role of the show host. Your contestant - Ralf, say - makes a choice, right (1/3 chance) or wrong (2/3 chance). When Ralf chooses the prize door (1/3 of the time), you are not helping him out by revealing (opening) one of the remaining goat-doors and asking him if he wants to switch to the remaining goat door (so switch = bad 1/3 of the time). But if he's wrong, 2/3d's of the time, then he chose a goat door. When you reveal the other goat-door, you are definitely helping him out by leaving only the prize door to switch to.

Debate about the correct answer mainly stems from the somewhat vague description of the host's behaviour. Is the host using his/her backstage knowledge to always expose the door (or one of two) that has a goat behind it? Most of us implicitly assume this is the rule at work. After all, the alternative - that the host randomly chooses a door regardless of what is behind it - entails that he prematurely ends the game a third of the time by exposing the prize door! This game has also been named after Monte Hall (a game show host) as "The Monte Hall Problem".

This gameshow can become a fun and tangible classroom activity for primary school students. Explain the game to your students and have them make and paint 3-door gameshow stages and prizes out of cardboard. Let them be creative about what the stage is - barn doors, haunted house doors, emergency room doors - and what the prizes are - 2 goats & car / 2 skunks & lollipop / 2 zombies & 1 wizard etc. Have the stages built large enough so the game host can place prize and bane behind the doors without being seen. Include a scoreboard of some kind or have this as a seperate notepad.

Then have the students break into groups of 2 or 3 to play, each taking turns for a while as the game show host, the others as player/scorekeeper. The host should randomly place the prize each time of course - a 6 sided die can be pressed into action for this, with 2/4/6 counting as 1/2/3 so a single roll can set which door 1 or 2 or 3 gets the prize. Without this randomization, a player may spot a pattern in the host's choice, for example if host moves the prize to a new door on each new game - and that would mess up the results of our little probability experiment!

Have the kids play whichever way they want initally; then start a new scoring page with players choosing either the hold or switch strategy for a fixed number of games, say 20, so that they get the feel for how a particular strategy works long-term. Do the game hosts learn more quickly (than the players) that switching is the best strategy?

The score page can have 2 columns: Strategy (H:hold/S:switch) Win (Yes / No), with each row posting the result of a game. Classes who are doing graphing in math can then total and graph the results of hold-wins vs switch-wins for a given number of games played.