The raw data originally comes from the Social Security Administration, but I am familiar with it because it comes with an R package as a sample dataset to play with.

UPDATE: the link I provided also has some R scripts to download the raw data from SSA and parse it. If you use these scripts, you can specify the dates and which states you want to pull the data from. Also, there is a script to grab the top X names for each sex. This could help you avoid shared name conflicts.

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.

Thank you for your opinion.

*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.

#LONG:#

Why else would CPAN host a module that attempts to solve this?

Have you perused the CPAN Acme offerings?

we target our audience through certain advertisements

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.

I downloaded a database of first names by gender in csv format from namegenderpro.com. I think this is by far the biggest data set of first names by gender that exists (177k names).

My name is in their data with the wrong gender and I’m acquainted with eleven others with the same name and gender. :P