I hate to post 'solutions' that don't solve anything, but this is somewhere between an XY Problem and something I wouldn't touch with a 20 foot pole.

Why are you bothering with the decomposition? Putting aside complicated questions of individual identification, storing that information is, by definition, derviable from and therefore redundant with your other data fields. This violates some basic DB design principles. Assuming you actually have a good reason for needing this data (see this Slashdot article, including the 4+ comments), unless you obtain it by an independent channel (self selected), you will always have a reasonable chance of being wrong.

As well, there are a lot of names in 'Anglo' that are gender ambiguous, depending upon your tolerances. Sam? Teri? Terry? Joe? Robin? Evelyn? Pat? Do you care more about avoiding false positives or false negatives?

How does the gender affect your app? If you are using it to map to a title, you are already wrong because of professional titles and the married/single split in female titles in English. And informally storing PII in a database is frequently asking for trouble.

#SHORT#

The result is subjective and unreliable; your problem is ultimately intractable; DNE.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

*Just LONG*
I firmly believe that this is a reasonable question. Why else would CPAN host a module that attempts to solve this?

While I completely understand the limitations (The ambiguity of particular names for instance, as you pointed out) of a concept like this and I would never expect it to be 100% accurate, we target our audience through certain advertisements and offers based upon their gender.
Would you ask a female if they wanted to buy * enhancement supplements? Would you ask a male if he wanted to buy a diaphragm?

As it just so happens, however, individuals are very unlikely to fill out a question that asks them "What gender are you?" and such questions must forever remain optional and 'skip-able'.

Therefore, our ability to unfailingly gather pointed data from our viewers is quite limited and we are attempting a 'behind-the-scenes' approach.

Subjective - I fail to see how you draw that conclusion as my feelings and opinion have very little to do with this.

Unreliable - Hypothetically. In its current form; however, this module produces 6.8% accuracy for our data. I am not asking for 100% accuracy, but I would like to see that number increase.

Finally, we anticipate that some of this data will end up being UNDEF which is perfectly acceptable.

This question that would not be 'touched with a 20 foot pole' was blatantly beaten with a one inch subjective metal bar.

By providing context, you have very substantially informed the question. One of the points raised in the Slashdot discussion (And I am, of course, loathe to consider Slashdot as a reliable source) is that application dictates what you actually mean by gender in a CS context. And your targeting question is precisely why the real question here is what are your failure tolerances? What is the cost benefit of an incorrectly targeted ad vs. offering non-specific ads to the same consumer?

Therefore, our ability to unfailingly gather pointed data from our viewers is quite limited and we are attempting a 'behind-the-scenes' approach.

Which hits on the DB question: why are you doing this in preprocessing rather than post? You are applying a model to your data, and therefore potentially corrupting your input stream by mixing original and derived information.

this module produces 6.8% accuracy for our data

You do get that there is inherent error, which is important, however, 6.8% accuracy is a pretty specific number. How did you determine that? Do you have independent training and test data sets, or does that mean some guy looked at the results and guessed yes or no?

#SHORT(ish):#

Subjective means that there is no general right answer. Because the cost benefit questions are use case specific, you must tune your own list. Because you were asking about using someone else's list.

Unreliable means you can't rely on an external answer. Because you were asking about using someone else's list.

frozenwithjoy's dataset will give you what you need to generate your own list. You can set your tolerances where ever you like, and have quantified reliability metrics in a particular market. My whole point was not that you shouldn't do it; rather that someone else's solution is almost assuredly wrong for you, a.k.a. Does Not (yet) Exist.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other