Friday, November 21, 2014

A fact about javascript objects

Here's a little fact about javascript: object properties are always mutable.

Ok, that's not surprising news--javascript objects aren't classes or functions, so there's no information hiding. But also remember that javascript is a dynamically-typed prototype-based language. This interacts with mutability in some surprising ways. Consider the following:
var myObject={
   property1:"this is the only property of myObject"
}
This is an object with just one property, called property1 that stores the value "this is the only property of myObject." We can output the value of property1 to the console like so:
console.log(myObject.property1);
Now suppose we want a second object that is exactly the same as myObject, except that also has a second property. You could write:
var newObject=myObject;
newObject.property2="property1 is wrong, this object has two properties now";
and again we can output the new property on newObject like so:
console.log(newObject.property2);
but here's the thing: we will get the same thing if we try
console.log(myObject.property2);
even though we never added property2 to myObject!

This happens because, perhaps surprisingly, we never created a second object. There is only one object in the above code, and it takes on two variable names. newObject is actually nothing more than a memory reference to the original object, and anything done to newObject is applied to the prototype tree of myObject. This has some pretty big implications for how you program in javascript. For example, whenever you pass an object to a junction, anything you do to that object inside the function changes the state of the original object even if you assign it to a local variable!

It's actually fairly hard to override this behavior. One way would be with classes
function ObjectClass(){
   this.property1="this is property 1";
}
myObject=new ObjectClass();
newObject=new ObjectClass();
newObject.property2="while new object has two properties, myObject only has one property";
In the above, there are actually now three separate objects: a class constructor, which is just a function that creates objects resembling our original myObject variable, as well as two instances of that class, called myObject and newObject, respectively. The instances are truly separate objects, which you can check by verifying that we added property2 only to newObject and not to myObject. So, despite what I said previously, you totally should use classes in javascript. However, this is still a pretty sloppy implementation, because it's pretty cumbersome to create a new instance of a class every time you want to pass an object to a function--there will be times when you want to alter the state of an object before sending it off to a bunch of functions (based on user input, perhaps), but still want to protect the object from any changes performed within those functions. An alternative to this is using the Object.create() method:
var newObject=Object.create(myObject);
Now, direct changes to newObject will not alter the state of myObject. But again, this is a pretty sloppy implementation. Object.create(myObject) does not create a new copy of an myObject, but rather creates a new object that inherits from myObject, and myObject remains part of the prototype chain for newObject. This matters for the rest of your program: any change to myObject.property1 will affect newObject, and the method newObject.hasOwnProperty("property1") returns false, because property1 is not local property of newObject.

There is no easy way to make a copy of an object in javascript. All other alternatives either miss important properties, duplicate properties, or add properties that don't belong.

None of this is true of most other programming languages. In R, if you pass an object to a function, operations applied to the object passed to the function exist only inside the scope of that function. That is, the program treats the argument in the function as a totally separate copy of the original object. If you want to apply the changes to the original object, you must either rework the function so that the changes are returned and then applied to the original copy, or you must hard-code the object directly inside the function. The latter is bad coding, but the former is usually quite acceptable.

So here's my question? Is this javascript fact a feature or a bug? Is there ever a reason you would want changes applied inside a function to always change the state of the original object? Is there ever a time when you would declare a new variable if you just wanted a reference to an already existing object rather than a separate object?

Wednesday, November 19, 2014

Halbig and King: a timeline

You've probably heard about the Halbig and King lawsuits over Obamacare. These are two lawsuits arguing that because the section of the ACA that specifies the formulas for calculating subsidies says "Exchange established by the State"--with no mention one way or another of exchanges established by the federal government for states that opt not to do it themselves--the law prohibits subsidies from being paid to customers on any federally-administered ACA exchange. King v Burwell is now headed to the Supreme Court, and the impact on the US healthcare system could be huge and immediate.

A big part of the public argument on Halbig and King (though perhaps less important as far as actual legal arguments go) is whether Congress intended for customers on federal exchanges to be eligible for the subsidies. I'm not sure I've seen anyone actually cross the political aisle here: Democrats think Congress intended for them to get the subsidies, Republicans think that denying them subsidies was intended as a way to incentivize states to create their own exchanges. I take issue with debates over what Congress "intended" because Congress is not a person, so lets amend this to an answerable question: at the time the bill passed the Senate, did any individuals believe that the subsidies would not be available on the exchanges, and did any people believe that they would?

What's weird about this question is that there's basically no evidence. I searched the google archives from 2009 and 2010. Not one result about the ACA included an explicit comment about the availability subsidies on the federal exchanges. As best I can tell, not one person in the English-speaking world had even considered the question at the time the bill was signed into law. So while it is false to say that Congress (or anyone) intended to deny subsidies on the federal exchanges, it is equally false to say that they intended to provide subsidies on the exchanges. No one had considered what would happen to subsidies if any states opted not to establish an exchange. So when did Halbig first become a thing?

Sarah Kliff's interview with Michael Cannon, who helped craft the argument that would become the plaintiffs' cases in Halbig and King, helps shed some light on the timeline here.

23 March 2010
President Obama signs the Patient Protection and Affordable Care Act into law. It's language provides formulas for subsidies for plans purchased on "an Exchange established by the State"--there having been no mention anywhere of whether or not this provision applies to federal exchanges as well.

December 2011
More than a year after the law has passed, conservative activists meet at the American Enterprise Institute to brainstorm legal strategies to weaken the ACA. One attendee presents on the faulty language in the section that explains the formulas for calculating subsidies. To Michael Cannon's recollection, this is the first ever mention of that.

March 2011
Jonathan Adler does a presentation on the same theme at the University of Kansas. According to Cannon, many health economists and experts were in attendance at Adler's presentation (Was Jonathan Gruber?).

15 July 2011
HHS issues the first draft of ACA regulations for public comment. One of those regulations is a clarification on the calculation of subsidies in ACA exchanges, saying that:
"The definition for an “Exchange” in §155.20 is drawn from the statutory text in section 1311(d)(1) and 1311(d)(2)(A). We interpret section 1321(c) of the Affordable Care Act to mean that this definition includes an Exchange established or operated by the Federal government if a State does not establish an Exchange."

January 2012
Jonathan Gruber, architect of the Massachusetts health reform and econometric consultant for part of the ACA, gives a talk in which he mentions that the subsidies would not be available on federal exchanges, and implies that this was intended to incentivize states to create exchanges.

16 July 2012
Jonathan Adler and Michael Cannon coauthor a paper laying out the legal case against subsidies on federal exchanges.

2 May 2013
Several businesses file a law suit that would become known as Halbig v Burwell.

16 September 2013
Several Virginia residents file the lawsuit that would become known as King v Burwell.

7 November 2014
The Supreme Court grants certiorari in the King v Burwell case.

Update: Adrianna McIntyre pointed me to this from a while back, where she already covered most of the points above.

Tuesday, November 18, 2014

Don't be fooled: that new FDA rule is not about gay men

I have written in the past about the social benefits of donating blood. Blood is one of the easiest, most valuable things you can donate. So I took some interest in headlines like "The FDA may finally let gay men donate blood..." That's how it was reported in most media outlets, though Vox was a bit more responsible and finished the thought:"--but only if they stop having sex."

The new proposed rule would allow men who have previously had sex with a man to donate blood only if they have not had sex with any men at all in the past year. For some reason, that's what the press calls letting gay men donate blood. So I just wanted to make one thing clear: almost all of the newly eligible donors under the new rule are straight men, not gay or bisexual:
Finally, the FDA will reverse a policy that has been discriminating against straight men for decades.
This graph is taken from the 2011-2 NHANES panel and shows the proportion of newly eligible blood donors--men who have had sex with a man but not in the past year--who identify as gay or bisexual versus those who identify as straight. The new rule overwhelmingly benefits straight, not gay or bi, men.

To drive the point home, here's a graph of gay and bisexual men who will and will not be allowed to donate under the new policy.
The new rule hardly affects gay men though.


So please stop saying that the new rule would let gay men donate blood. It won't. This rule change is almost entirely about letting straight men donate blood, not gay men.

Sunday, November 16, 2014

The aggravating nature of survey data

Danielle Kurtzleben has a post about how Americans--and everyone else--massively overestimate the unemployment rate. The actual rate is 5.9 percent, yet the average survey response was 32 percent. All the other countries surveyed also massively overestimated their unemployment rates:
Survey respondents massively over estimate the unemployment rate in every country.
While it's fun to sit back and say "haha people are stupid," I think there is a perfectly reasonable explanation for why the respondents answered the way they did:
Currently, 40.8 percent of americans do not have a job.
In fact, while the American survey respondents estimated that the unemployment rate was 32 percent, more than 40 percent of Americans do not currently have a job.

This gets at the most frustrating thing about survey data. The public doesn't really define unemployment the same way economists do. Economists want a useful labor market metric, so we want exclude everyone who doesn't want a job--children, full-time students, people with serious disabilities, the retired, the fabulously wealthy--from our measure of unemployment. We do this by asking two questions in the Current Population Survey: "Do you have a job?" and "Are you looking for a job?" You are only counted as unemployed if the answer to the first is "no" and the second is "yes."

However, most of the public is not trained in how economists define unemployment, which is non-obvious and not necessarily intuitive. For the most part, the public defines the term based on intuition when they hear it, and "unemployment rate" sounds like it is the percent of the whole population that doesn't have a job, not a percent of the subset of the population that wants a job as economists define it. It's true that the survey Kurtzleben cited did explicitly define the term for respondents, but that's the nature of surveys: respondents tend not to read all of the question before answering. This is extremely frustrating to anyone who has ever attempted to design a survey for research, but extraordinarily common and to be expected.

So overall, I'd say there's nothing to see here. The estimate of 32 percent is quite reasonable--actually low-baling it a bit--of what the respondents thought they were being asked. That is all.

Thursday, November 13, 2014

Statistics in the age of HIPPA

Just a brief thought. Part of what limits how much healthcare improvement and research we can do is HIPPA, a law regulating how people's health information can be handled, in order to guarantee medical privacy. To do statistics, researchers need patient data, so that there is a sometimes arduous process of getting the appropriate qualifications, getting permissions, and maintaining data security.

On the other hand, do we really need data to do statistics? The standard model of statistical investigation in healthcare dates to a time when server resources were precious, internet was slow, and scripting languages were primitive. This is no longer the case. We could in fact do statistics through interfaces: all the patient data remains isolated on a secured server armed with a statistical scripting language, and on a client computer somewhere investigators could tell the server to run t-tests and regressions or what have you, and return only the estimates to the client.

I will leave you to speculate on the details here. The point is, in this system at no point is any health information, identifiable or otherwise, given to the researcher, so that there is no HIPPA concern.

A separate but related question is one of ethics. Human subjects research requires IRB approval and usually also informed consent, regardless of whether health information is involved, which is generally taken to mean that it is unethical (and illegal) for researchers to probe databases without first getting approval, even if the subjects have previously consented to allow that data to be collected for research purposes. How would this apply to our situation?

Again, the old standard presumed that researchers had to be in possession of data to analyze it, a factor that introduces new risks to the subjects as there are more opportunities for their data security to be breached. But in our new system, there is no new risk: the researchers are at no point given any data, so there is no potential for them to abuse the data nor is there any potential of an accidental security breach. Allowing additional studies to be performed using this data has no potential to harm subjects, beyond the risks they initially consented to when the data was collected under the original research protocol. Hence, there should be no need for further IRB approvals once the data is collected.

So how about it? Let's make remote analytics a thing. Is there a down side?