• Need a lot of upfront design (border obsessive)?
• More willing to wade through muck (opportunist)?
• Disdain all order (monkey on a typewriter)?

There's a million ways to slice it, but it all boils down to how much control you feel you have to have over a given situation. My wife, for instance, absolutely needs to feel that she is in control over a given situation, whatever that situation may be. I, on the other hand, am much more willing to trust in a beneficial outcome. That difference can be explained in terms of a bazillion things. A few items could be:

• Religious faith (I have a very deep faith, my wife is more agnostic)
• Upbringing (I was brought up wanting for nothing, my wife was more working class)

And, you could continue that list.

> I, on the other hand, am much more willing to trust in a beneficial outcome.

I think a lot of that has to do with how you view the potential of a 'negative' or 'undesirable' outcome. I've noted that people who feel the need to exert utter control are typically driven by a fear that a situation will not turn out the way they expected; and that fear is caused by believing that the expected outcome is likely to be better than any unexpected outcome.

Those of us who are more opportunistic tend to be more optmistic (assume an unplanned outcome will be at least as good as the expected one), and tend to view the unexepected with a different attitude. The attitude of which I speak is best summed up in an old Chinese tale (my apologies, I'm summarizing from memory)⁰:

An old man and his son lived together on a farm, and they were not wealthy. One day, their only horse broke out of the stable and ran away. A neighbor stopped by to offer his condolances, saying "It is so terrible for you, that your only horse ran away."

The old man smiled and said "how do you know it is so bad?", and the neighbor walked away shaking his head.

In the night, the lost horse returned, and with her an entire herd, which the old man and his son were able to capture. In the morning, the neighbor was passing by and saw the great herd of horses. When the old man told the story of the horses' capture, the neighbor said, "aha! I see now that it was very good that your horse broke free!".

The old man gazed calmly at the neighbor and said only "how do you know it is so good?" The neighbor left once again, muttering about the old man's lack of joy.

A few days later, the son was breaking one of the new horses. He fell from the horse and broke his arm. The neighbor heard, and rushed over to offer his condolances. "I see now why you were cautious about calling your new wealth good fortune," he said. "This is terrible -- how will your fields be plowed when your son cannot tend them?"

The old man smiled and said, "how do you know it will be so bad?" The neighbor scoffed at the old man, and cursed his ignorance.

Later that day, however, the local lord's army came through the town, and pressed every able-bodied man into service. The son was spared, as he could not fight with a broken arm.

When the neighbor observed this, he was enlightened.

I think the more opportunistic tend to take the old man's view and wait to see what a particular outcome will bring, rather than assuming it will be bad (or good, even). I personally think it is the better of the two approaches -- though there is certainly something to be said for appropriate planning and consideration -- because it allows one to react to changes and make the best of any situation.

From a programming perspective, that results in code that is more flexible. By flexible, I mean that it is easy to alter when requirements change, and easy to build upon. The latter of those makes reusability easier, as well.

0: If anyone knows this story, and can point me to complete translation of it -- or at least tell me its common name and/or attributed author -- I would be most grateful

Update=> dragonchild kindly referred me to The Lost Horse, which appears to be a much more concise version of the above tale, and an actual translation thereof. Thank you, dragonchild.

Anima Legato
.oO all things connect through the motion of the mind

I see this being applied in two places,

• More general work habits, and
• More specific coding or even development styles.

General work habits

I have to admit that my own work habits are a little haphazard. I flit from here to there, rarely focussing on something for a long period of time. Currently I'm a) watching all of my servers using Nagios, b) keeping an eye on internal E-Mail (pine), c) running two delete document scripts, d) watching a smaller group of servers (xload, qstat, top), e) keeping tabs on personal E-Mail (GMail), f) reading SlashDot and g) browsing perl Monks. I am really in the middle of h) upgrading application server software on two matched servers, one in Toronto and one in Mumbai. I have a cup of coffee that's half gone, and a cell phone on my desk. I have MP3s of songs I have to learn when I have time.

Specific development styles

I started writing something on my own time using CGI::APplication and Template::Toolkit and while it's been frustrating at times, it's also worked well. I've got a huge overarching vision of what I want this to be when it's done but I've had to focus on a small, small subset of the task at hand and get that running first.

Sometimes it's hard to have the discipline to do that, but if that's what it takes, OK.

Jigsaws? Not crazy about them

My wife is actually the jigsaw person in the house. I have too much other stuff to do, to have to think about (or even do) jigsaw puzzles.

Anyway, I can't really see any parallels to the way I code much. I suppose I do prefer well defined tasks - "You do this bit, I'll do that bit", but I don't remember having problems solving jigsaws together with other people.

C.

I think the article is talking about people who insist on finishing all of the border first before they even start working on the rest. Personally, recalling from the few times I did a jiggsaw, I start with the border too, but I never complete it. I might if I had the patience, but I just don’t. I work my way through detail-rich areas of the image where it’s easy to see which pieces go where. That organic growth is the gratifying part. The large flat-coloured areas where you have to guess more than arrange are always last and completed far more lackadaisically than the rest.

The article does have a point in that, upon reflection, this mirrors the way I generally approach any project quite well.

Makeshifts last the longest.

Why would anyone want to waste time with jigsaws??? There are few things as annoying and pointless. So I gess I'm in the last group, "if you want your jigsaw sorted you should not have messed it up!"

It would be interesting to see the results of this test on groups of people who use different launguage.

As for getting conflicts when people have to make a puzzle together, well, the puzzle has only *120* pieces. That's 10 x 12 pieces. That's childs play! Doing a 120 puzzle with 2 adults is like having 2 people work together to swap a backup tape (and then observing "extreme behaviour" if one person pulls out the tape alone).

Let them make a 5000 piece puzzle.

No one actually built their own jigsaw(an interesting feat of electrical and mechanical engineering). They didn't even build their own jigsaw puzzle (which is what I expected the article refered to). They just assembled a pre-existing jigsaw puzzle out of existing puzzle pieces. Children (and the jumbo sized version, called 'adults') have fought over "the right" way to play the puzzle game for years. I was disappointed to find little new in the article that direct experience in my childhood didn't already tell me.

As someone who is mostly interested in Perl programming, (rather than human psychology as applied to Perl programmers), let me instead pose a different puzzle question: How could one write an efficient perl program to solve a jigsaw puzzle? Given a representation of the pieces (say, scanned images), and a representation of the final result, how do you avoid "combinatorial explosion" in the number of comparisons required?

As a more challenging variation, simulate some human limitations. Unlike computers, humans can't tell at a glance whether a given "sky coloured" puzzle piece with two knobs and an edge matches in a given place without picking it up, and trying it for fit. You could simulate something similar for the computer: give colour information about the piece within a given rgb range, and "fuzzy" rather than exact edge configuration information. Moving a piece into a slot would give some limited information about the quality of the match (fits exactly, fits badly, nearly fits, etc). Minimize for (a) amount of time to solve the puzzle, and/or (b) number of pieces "moved". Assign a higher 'time cost' to moving a piece, given that moving a piece is slower than thinking about a piece, to an extent.

To make it all Perl related, submit your solution in Perl (or post to cpan as a puzzle solver).

Best of luck to anyone brave enough to attempt such a program! :-)

--
Ytrew Q. Uiop

How could one write an efficient perl program to solve a jigsaw puzzle?

Step one would probably be to do the border. :-)

Seriously though, take a look at Picking Up the Pieces a /. article about "unshredding" documents.

I think a software jigsaw solver would be quite easy (at least conceptually) without any combinatorial explosion.

Given a scan of all the pieces and a scan at the same resolution of the finished image, all it takes is "moving" each piece over the finished picture and see if it matches the underlying picture at that spot. To avoid moving on a pixel-by-pixel basis, you can probably "jump" the piece around as most jigsaws seem to have some matrix-like structure of the pieces, so you will not have to check every single pixel-position.

Of course you will have to check for every orientation (but as most pieces are more or less four-sided, that is only four checks for every useful position).

The only problem I see is with pieces of a single color (those d****ed "all sky" pieces) as they might fit more than one location. You will have to leave these for the last and try to fit them in given all pieces already in place. Here you might have to try all combinations.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

What combinatorial explosion? Unless you have a specially constructed jigsaw puzzle, in a jigsaw puzzle, every side of every piece fits only one other piece (unless the side is on the border). For most jigsaws, determining whether two pieces fit doesn't even require looking at the pictures, just determining wether the pieces lock, and if they do, whether their corners align is enough.

Considering there's only O(N²) pairs of pieces, with at most 16 ways for two pieces to possibly lock, this leads to a simply quadratic algorithm.

Of course, that still leads to the problem of determining whether two pieces match, but there's no combinatorial explosion. A combinatorial explosion would happen if you first assemble all (or a fraction of all) the pieces before you determine "match" or "no match".