Added density of a categorical #10949
Not sure if this is the correct approach to the problem 

closes #10949.

 Assuming it is I will go ahead and add some documentation for this enhancement. Let me know if you have any feedback.

Great!

I know @jreback suggested to multiply by 100, but is that right? Shouldn't we let the user convert to percent? (a more general point than this PR)

I'm not sure you want integer division there.

I would test for an actual value, rather than just the code that you wrote
 Happy to change this to a proportion, I agree that it seems a more sensible default. 

With regards to integer division, what is the preferred way to target Python 2 and 3 with float division, `from __future__ import division`?

Will update the tests in the next commit.
 I'm not sure on the pandas standard for the division - the maintainers will opine - either `__future__` or coercing with `float(x)` would work.

And they'll also ask for a note in what's new & the docs.

Cheers!
 further, can you do a tiny bit of research to see what `R` calls this (they call the `Categorical` a `Factor`.
 I haven't had much luck searching for an equivalent field in R but I have found that the SAS community calls this number the cardinality ratio: http://www.sascommunity.org/wiki/Cardinality_Ratio
 Should we consider preempting or handling `ZeroDivisionError`?
 whoosh never realized we allow 0 categories!. Yes that should be a `NaN`
 pls add a release note in 0.17.1 (enhancements)
add to api.rst as well
 can you update
 Apologies for the delay, I was trying to understand out the correct way to add documentation for this feature before other projects stole me away from this fix. 

I've made an updated commit. There remains one failing test due to the recommendation to switch from `tm.assert_numpy_array_equal(np.nan, s2.cat.density)` to `self.assertEqual(np.nan, s2.cat.density)`. Please advise on the best way to approach this failing test.
 use self.assertTrue(... is np.nan)
 closing as we closed the original issue #10949 

let's see an actual usecase (as I proposed the original issue, and don't really have one :)
