NYTimes scapegoats ACA subsidies

Katie Thomas, Reed Abelson and Jo Craven McGinty have an article in today's NYTimes on how the new Affordable Care Act is leaving some middle-class families "caught in the uncomfortable middle." By this they mean that those with incomes just above the cut-offs for subsidies are paying much more than they would if their incomes were just a little less. Unfortunately the math doesn't quite work out on this.
The calculation that matters is how much money a family has left after they pay for their insurance. Look at the families the article gives the numbers for (I'll assume the numbers in the article are correct):

Family	Actual Income	Premiums	Net Income	Lower Income	Lower Premiums	Lower Net Income	Savings
NH	$100,000	$12,000	$88,000	$94,200	$6,000	$88,200	$200
Polk Cty.	$50,000	$9,801	$40,199	$45,000	$2,228	$42,772	$2,573
OKC	$50,000	$3,279	$46,721	$45,000	$2,425	$42,575	($4,246)

So in two out of three cases the Times describes, the families either have more income after insurance (OKC), or effectively the same amount (NH) that they would have if they made the lower incomes described in the article (ignoring the effects of income tax). At least one of the other families is likely in a similar position (the Montana bakery owners, who would pay $1,500 more a year if their income rose by some unknown amount, which is likely more than $1,500). Most families will have more net income if they make the higher income, even with the higher premiums. In other words, the subsidies are doing what they're supposed to, making the insurance more affordable for those with lower incomes. That they're not helping families who don't qualify for them seems beside the point.
What the article is really about is how for some people ACA insurance will cost more than they currently pay, and it mixes in this mostly inaccurate attack on the subsidies. But even here the article falls down because it doesn't compare all the old and new health-care costs of the families. Premiums are only one part of those expenses: there are co-pays for office visits, medicines to purchase, and so on. Granted, it's not easy to calculate that. You'd need a lot more data than are presented in this article, but that's why this health issuance stuff is hard.
Who's spending more or less on health care because of the ACA? We know as little at the end of the article as we do at the beginning.

Teaching with ORBIS #lawdi

On the last day of our Linked Ancient-World Data Institute this summer, sponsored by the NEH Office of Digital Humanities, I argued that it was important to show how all this exciting work could have practical implications for what professional classicists (and other ancient-world types) spend a lot of time on, teaching. To that end, I promised to do a post describing how I had assigned my Classical-archaeology students some short homework using Stanford's great new tool, ORBIS. What's ORBIS? In the words of the site, ORBIS "reconstructs the time cost and financial expense associated with a wide range of different types of travel in antiquity." More simply it allows you to map routes between two places in the Roman world given certain constraints for cost, time, and type of route.

Naturally the fine people at ORBIS did a nice upgrade to the service after I made that promise, but before I got it completed, so I had some more work to do before this post. (Fair enough, I dragged my feet for too long anyway. Nemesis strikes!) But finally here it is, suitable for framing (or at least bookmarking).

A Very Short Guide to Using ORBIS in your Classical-Archaeology Course

1. RTFM

Make sure that you understand as much as possible about ORBIS, what it is, how it works, and so on. You don't need to be an expert, but you should at least be able to do more than your students will by the time they finish the assignment. It won't take more than an hour to read the "Introduction to ORBIS", "Understanding ORBIS" and "Using ORBIS" tabs on the website. Don't miss the nifty how-to videos. Although there's more there to read, these three sections will get you far enough for step 2.

2. Make sure you know how to use it

Play around a bit yourself on the "Mapping ORBIS" section. Try to get from one place to another. Change the various parameters. Use all the controls, so you know how to change the views of the route and so on. Click the buttons and links and sliders. Go nuts. Depending on your technological prowess, this will take you a few hours at most.

3. Demo it in class

Once you're confident that you can show your students the basics of the site with confidence, have your student read those same three sections of the ORBIS website that you read up in #1 in preparation for a short demo of ORBIS that you'll do in class for them. Nothing fancy, just enough to show them the basics. I like to point out to them how long travel takes when you don't have motorized vehicles and how much faster travel over sea is than over land, but be sure to walk them through creating a route and choosing the various options, no matter what extra details you cover.

4. Assignment 1 of 2

Have your students use ORBIS to find a simple route between two places that you specify. Have them do it under multiple conditions. (I used three different sets.) Then have them either print out or take a screen shot of the result, with all routes shown. Here's one with routes between three sets of cities, one taking the fastest route, another the cheapest, and the third the shortest.

Since you've set the parameters, you'll know what the correct routes should be, and thanks to the different colors, it's easy to tell at a glance whether the student got it right. Successful completion of this will indicate that your students can handle using the basics of ORBIS. Make sure they all successfully complete this first assignment. Then they're ready for part 2.

5. Assignment 2 of 2

This part is up to you. Depending on which section of your course you're using ORBIS in, you'll want to find some question you can answer, or some issue you can illuminate via ORBIS. I actually did something that was completely out of ORBIS' chronological span.

To help my students understand the rationale behind some of the placement of early Greek colonies in the west, I had them examine routes between Delphi and Naples. The latter was used as a proxy for the earliest colony of Pithecoussae. (This was actually a variation on an assignment I had made up years ago using a QuickTime movie with links to the Perseus website.) The biggest travel difference between the later Roman empire, the time in which ORBIS is "located", and the geometric period was the roads in use. Obviously none of the vast Roman road system was in place, and so I made sure the students used only routes that avoided long portions over land. (I want to use this assignment again, so I'm not giving away all the details!)

6. Put the students to work

If you subsequently have your students come up with their own ORBIS projects, odds are they'll find something useful and interesting to do, perhaps something you hadn't quite thought of. A set of mine, for example, used ORBIS to explore the different travel experiences of three characters from the ancient world with differing socio-economic backgrounds, complete with clever backstories!

And there it is. Hope this encourages you to use ORBIS and other terrific ancient-world-related DH tools in the classroom! I'd love to hear in the notes about your experiences with ORBIS or with any other tool.

Were the Ancient Minoans Europeans?: A Comment on doi:10.1038/ncomms2871

Just got around to reading "A European population in Minoan Bronze Age Crete" <doi:10.1038/ncomms2871>, which argues for a European origin for the ancient Minoans based on genetic analysis of mitochondria from some ancient Minoan bones. Their analysis suggests that the ancient Minoans were most closely related to other ancient peoples and, among moderns, the populations of northern and western Europe. This contradicts Arthur Evans' theory that they were related to ancient Egyptians.

This isn't a field I'm entirely up on the research in, but it does overlap with my old interest in biochemistry and my current work in archaeology. Some of what I write here may therefore be easily corrected by those in the know, but I had a few problems with the paper (which I enjoyed overall). Please enlighten me in the comments.

Inconsistent Data

Table 1 of the pairwise genetic distances between Minoans and other populations seems to be based on the data presented in Supplementary Table S5, but it doesn't give the same data. For instance, the first group is Bronze Age Sardinians, which have an average pairwise distance of 2.75111 in S5, but 2.89 in Table 1. Maybe that's because these two tables were calculated using two different versions of the same software (Arlequin 3.5.1.2 vs 3.5.1.3), but that appears unlikely, since the Arlequin updates page doesn't seem to list any such change between versions.

[BTW, if you're going to give a supplementary file of data, why not put it in some nice format like CSV instead of a PDF? I fixed it up with Tabula, but that was an unnecessary expenditure of my time.]

"Ancient"?

The authors divide their comparison population groups into two chronological categories, "ancient" and "modern." Their ancient group includes 11 distinct samples: 6 neolithic, 3 Bronze Age, 1 medieval/Iron Age(!), and 1 Byzantine. They seem to be taking the nomenclature of their original sources, so it's worth noting that Byzantine means 11th −13th centuries and Iron Age-Medieval-Nordic means 1st - 14th centuries (and that the original authors did not apply this catch-all term). I didn't look up all their "modern" samples, but the remarkable chronological span of the their "ancient" ones already raises some doubts in my mind. You can't lump together millennia of data like this and act like you have homogeneous groups. This makes map b in Figure 3 misleading as well, even ignoring the way the map is colored in areas where there is no data at all (like all of North Africa, on which more below). Line c of Figure 4 does break these ancient sets up into three distinct groups, leaving out the Neolithic, but even this obscures the fact that one of these groups has a much higher sharing than the others: the one from BA Sardinia with 52%, compared with a maximum of 12% for the other two BA sites, and 15% for all four of the other locations. I'd question this approach, as it's a great example of why the mean can sometimes be a bad choice for comparison: with an N of 3 in the BA group and a standard deviation that's larger than that, you'd be better off reconsidering your choice to group these data points, or at least use the median.

If we break out this Sard group then, we're left with a much more consistent sharing with the Neolithic groups (mean=24%), and fairly low sharing with the other BA, the Byzantine, and the (absurd) Iron Age-medieval group. In short, with that one Sard exception, all the European post-Neolithic "ancient" groups match the Minoans about as well as the modern Middle Eastern/Turkish/Caucasian sets. Since the Minoans are BA Mediterraneans, that makes me wonder why the Minoans are so different...you know, assuming again that that small N isn't to blame.

Line d of that same Figure 4 breaks down the six Neolithic locations into three sub-groups based on a north-south positions. Again, I'm not sure how far you want to go with an N of 1 in the northern set. The largest sharing with the "southern" group—really France and Spain—is not surprising, given their proximity to the Mediterranean and the likely mixing of those populations in the Neolithic (as discussed, for example, in the article they take one of their datasets from).

More troubling though is the complete lack of any ancient sample from anywhere further outside Europe than Asia Minor (modern Turkey). If you're going to claim that Minoans aren't like ancient Egyptians or Middle Easterners, you'd probably want to have some sample of those groups to compare them to. The authors do note the lack of the typical African L haplotype in the Minoan group, but I'd still like to see a direct comparison with some North African Neolithic and BA data.

Note revealing my ignorance

I find the methodology of creating the haplotype sharing quite interesting. Count the individuals from each set who have a haplotype that appears in any of the Minoan individuals, then divide by the total number of individuals in that set to get a percentage sharing. For example, say you have a population with three haplotypes, A, B, and C, distributed in the population at 80%, 10%, and 10%, respectively. Another population with all the same haplotypes distributed 1%, 1%, 98% would have 100% sharing, while a third population with 85% A and 15% B would score 90%, even though the distribution of haplotypes was more similar than the second group's in overall distribution.

So in the data in this paper, we see that the Sard BA sample had the largest overlap of any group, but with only two shared haplotypes, while the North Africa set had a much lower sharing percentage, but 6 shared haplotypes. I realize part of the problem is the small N's involved, which often don't permit for a great representation of the overall distribution of haplotypes within the total population.

Update: A post from a more knowledgeable guy than myself are here.

Apple's Stupid Data Detector: Meetings

Built into OS X is the great capability for detecting when a meeting is being mentioned in things like email messages. I'm calling this by the old System name of "Data Detector", though I suspect that might not be what Apple calls it now.

It's pretty impressive on the whole. Given a bit of text like the one in a message I got this morning...

The meeting will be on Friday, April 26th at 9:30am in BC 106.

on hover it highlights the date and time bit and give me a little pop-down menu to make an appointment in iCal out of these data:

I can edit the appointment before it gets created, putting it in the right calendar, for example. Great, right? Yes, great.

But...

It also does a few stupid things. First it uses the subject of the message as the appointment text, which would be fine, except the subject very clearly has the same date and time info and it doesn't bother to try to strip that out, even as it removes the leading "Fwd: " from that same text. Second it's apparently too stupid to ever recognize any location info, even when that info is pretty clearly indicated by adjacent and obviously locational prepositional phrases like "in..." or "at...". Sometimes it's going to get those wrong, but a lot of the time it won't, yet it clearly hasn't been written to scrape that info out of a message. Finally this capability isn't active in text that you're typing. So if I'm in Mail, writing a message to confirm an appointment with someone, I can't just click on my own date and time text and make an appointment out of that. I have to go into iCal and do it.

This is one of those insanely great things I love in OS X. It's frustrating when it's senselessly crippled.