Wednesday, February 25, 2015

Today's ruling reveals how SCOTUS will analyze King v Burwell

Yates v United States has been bouncing around twitter all day, far more famous for the fact that Justice Kagan cited Dr. Seuss in her dissenting opinion:
" A fish is, of course, a discrete thing that possesses physical form. See generally Dr. Seuss, One Fish Two Fish Red Fish Blue Fish (1960). So the ordinary meaning of the term “tangible object” in §1519, as no one here disputes, covers fish (including too-small red grouper)."
However, a more interesting aspect of the case was why the majority opinion sided with Yates. As Mark Joseph Stern explains:
"Yates fought back, insisting that undersized grouper didn’t qualify as a “tangible object” under the Sarbanes-Oxley, which was enacted following the Enron scandal to stop financial firms from shredding incriminating documents. In a closely divided ruling, the Supreme Court sided with Yates, with a plurality of the justices reading the statute to cover “only objects one can use to record or preserve information, not all objects in the physical world.” Justice Samuel Alito concurred in the judgment, providing a key fifth vote for Yates, noting that “the statute’s list of nouns, its list of verbs, and its title” all apply to “filekeeping,” not fish. This, Alito held, “tip[s] the case in favor of Yates.”"
So there you have it. The Supreme Court just ruled that it must reject the literal, dictionary definitions of terms, even though the statute does not offer an unambiguous alternative, based on the context and totality of the statute. As numerous experts have noted, if the court applies this same standard to the ACA, then it thoroughly kills King's case in King v Burwell.

Javascript, ajax, and class-oriented programming

I'm curious what the best approach is to implement an asynchronous ajax request in a class-oriented way (more commonly known as "object-oriented programming" but "class-oriented" is a more appropriate term). A javascript ajax function looks like this:
    function getHTTPObject() {
        var xhr;
        if (window.XMLHttpRequest) {
            xhr = new XMLHttpRequest();
        } else if (window.ActiveXObject) {
            xhr = new ActiveXObject("Msxml2.XMLHTTP");
        return xhr;
    function ajaxCall(dataUrl,dataStorageObject) {
        var request = getHTTPObject();
        request.onreadystatechange = function () {
            if (request.readyState === 4 && request.status === 200) {
                var jsonResponse = JSON.parse(request.responseText);
        }"GET", dataUrl, true);
I know it's popular to do this in jquery, but jquery is just doing this, with 50kb worth of extra crap (side note: the getHTTPObject function isn't even necessary going forward, now that Microsoft is finally on board with XMLHttpRequest objects). I don't want to hear anything about jquery unless it specifically solves the question.

There are a number of reasons we might want to use a class-oriented approach along with ajax in javascript--in webpage with lots of user inputs, for example, classes help to encapsulate, protect, and manage those inputs in a safe, conflict-free way (ie, where user inputs define the internal state of an object at the time it is created, this allows the inputs to change while the object based on the original inputs can still be used). Now suppose we have a data class object like this
function Class1(){
    var internalData=[];


        return internalData;
This class has a private property internalData that cannot be accessed from outside the object, and two public methods, UpdateData and DisplayData, that can be invoked from outside the object. The array internalData just stores the data, which because it cannot be accessed from outside, protects it from accidental misuse. UpdateData makes a GET http request to our server, and saves it to internalData, which we exposed to it in the function call.

All of that works fine, I guess, although I'd rather not have to expose internalData to the ajaxCall function. This is necessary because the data returned by our GET request exists only inside the scope of the request.onreadystatechange method in ajaxCall. We need to get the data out of there somehow. We can't just use a return statement because the call is asynchronous--javascript executes the ajaxCall function synchronously, but loads the data asynchronously, meaning that the data won't exist yet when we try to return it. Instead, we simply expose the object where we want ajaxCall to eventually store the data.

But this creates problems, because it means essentially that our code is not thread-safe. For example, suppose we do this:
var myClass1=new Class1();
var myVar=myClass1.DisplayData();
Most likely, myVar will be empty when you try to use that data. The reason is that ajaxCall is still waiting for data to arrive from the server when javascript moves on to try to execute var myVar=myClass1.DisplayData(); meaning that internalData is still an empty array when this statement gets processed.

My question is, what is the best way to handle this? Usually it is possible to write the code in such a way that whatever you want to do with the data is done from inside the ajaxCall function, but I want a different way, one that doesn't corrupt the class-oriented pattern. It is easy enough to check whether the data has arrived yet, but that isn't really good enough. We really need the program to wait until the data is loaded before executing, ideally without blocking other parts of the program that don't need this data from running. Should we use a timer and keep checking periodically till the data is there? That sounds like a terribly inefficient solution. Make the ajaxCall synchronous?

Unconventional views that Tyler Cowen doesn't want to talk about

Tyler Cowen has a list of views he holds but thinks are too conventional to turn into full posts. And some of them are pretty conventional. Others, not so much. As a plea for him to further elaborate, here are the unconventional ones:

2b. Ok, some of what he said here was conventional. I just want to single out this: "it has served as an inefficient form of wealth insurance for some lower-income groups," as well as this "on net, the negative health consequences of the disemployment effects of the law could easily counterbalance the direct positive health care access effects." These aren't obviously unreasonable hypotheses, but far from conventional! They deserve blog posts, if not whole books, written about them. On the former, I've written before on why it's optimal to have health insurance as part of the social wealth-insurance bundle--does Cowen have a different view? And there's a lot packed into that second part: the health effects of disemployment are empirically inconsistent, especially when considering only the portion of the effect unrelated to changes in insurance coverage. Moreover, the relation of that literature to the ACA is somewhat mixed too: most employment effects of the ACA are either volunary (job lock) and not likely to have negative health effects, or on the intensive margin (the phase out of exchange subsidies and the 30-hour employer mandate) rather than extensive margin studied in those health effects studies. The fact that Cowen thinks these are conventional views makes me suspect that he gets all his health econ news from Casey Mulligan.

3. "The Supreme Court will rule against the current version of Obamacare and send the matter back to Congress." Is Cowen talking about King v Burwell? The conventional view on King and Halbig has always been that they are "reach" cases that have little chance of a favorable SCOTUS ruling. And it would be historically unconventional as well. Historically, SCOTUS has always liked creative arguments that rely on neither literal nor intentional arguments. Think about Bush v Gore, where a white man used a civil rights amendment to halt a legitimate vote count. That creative reinterpretation of the equal protection clause is the kind of reasoning the court likes. King v Burwell is the exact opposite: a case that depends on hair-splittingly literal textual interpretation that even Amelia Bedelia wouldn't buy. The court won't buy it either, because they don't want that standard as a precedent.

5. "But with nominal gdp well, well above its pre-crash peak, it is not demand-based “secular stagnation.” It just isn’t, I don’t know how else to put it. And the liquidity trap is still irrelevant and has been since about 2009." I think Cowen knows this is all highly unconventional--that's why he reiterated "it just isn't," as if already arguing with everyone about this.

8. "I am sticking with my recent Grexit prediction."

Monday, February 23, 2015

Is human capital capital?

The Harvard Mark II computer Wassily Leontief used for his input-output models.
This is a question that seems to have taken the econosphere by storm.

Of course, human capital is not capital. If it were, we'd just call it capital and lump it in with the rest--the purpose of the term "human capital" is to distinguish it from actual capital.

So, if it's not capital, what is human capital? At most, I'd say it's a modeling insight. The vague notion of "skills" and knowledge that it stands in for are very real, but when it comes to modelling we are really just pretending it's a kind of capital stock. The key insight was in recognizing that skills and knowledge share a few of the same kinds of intertemporal dynamics as capital, and that we can obtain accurate predictions by modeling them as such, even though they differ in lots other ways.

One of the earliest modelling successes of the theory of human capital happened in international trade theory. In 1949, economist Wassily Leontief plugged some imported Soviet input-output models into a computer with data from the BLS and let it chug. When the computer solved the model, the results it spit out were mind-boggling--the US was actually a net exporter in labor-intensive goods, not capital-intensive ones. That was pretty shocking because in 1949, shortly after world war II had destroyed half the world, the US owned essentially all the world's capital, having only a small portion of it's population. Why wasn't the US exporting capital-intensive goods as theory predicted?

The answer, it turns out, is human capital. Leontief's model hadn't incorporated any notion of cumulative job skills or knowledge, and therefore missed the fact that Americans in 1949 actually were exporting the things they had a comparative advantage in--goods that were human-capital intensive--despite the relative dearth of physical capital anywhere else on earth.* Failing to model human capital as a kind of capital stock, it turns out, produces incorrect predictions.

Reading this debate on the econosphere, you'd be forgiven for thinking that this kind of human capital--essentially just job skills--is the only kind that exists. Noah Smith, for example, asserts "creating value from... [human capital] requires the owner to sacrifice some leisure." That's not true of all kinds of human capital! I'm a little disappointed that no one brought up any of the myriad other kinds of human capital that exist (or rather, the myriad other kinds of non-capital which exhibit capital-like intertemporal dynamics), such as health capital.

The concept of health capital originated with Michael Grossman's seminal 1972 paper in which he postulated that an individual's life-cycle of spending on healthcare could be modeled as investments into a capital stock. This, for the first time, captures many of the real-world aspects of health behavior and health spending that static models can't grasp. We knew, empirically, that people's health and longevity depends in part on the cumulative choices they make over the course of their lifetime, such as whether or not to smoke, what kinds of food to eat, how much time to spend exercising, and even how much to spend on healthcare. Each of these choices involves an intertemporal tradeoff--that is, a choice of how much to "invest" into maintaining their stock of health capital. Extensions of Grossman's model can explain all kinds of health behaviors from addictions to yo-yo dieting to trends in national health expenditures.

Do humans literally carry bags full of health capital around with them through life? No. Health capital is not capital. As economists we are merely pretending that the vague notion of healthiness is a kind of capital. But because of the similarity in intertemporal tradeoffs, modeling health choices this way yields many correct predictions, and resolutions to old theoretical puzzles we would not otherwise be equipped to solve.

*This account comes ultimately from Leontief, by word of mouth. He was one of my professor's professor. I do not, however, claim familiarity with the academic literature.

Monday, February 16, 2015

Should everyone learn programming?

I'm generally a big fan of the idea of introducing programming into schools as a core subject area, along side reading, writing, and math. But my main worry is that if everyone knows programming, everyone will try to do it on their own, and do it poorly.

Consider SQL for example. Currently none of the doctors in my division know SQL, and as a programmer I'm often one of the few people who interacts with the database to get data to the doctors. Suppose we want to get a list of all the patients who aren't emergency patients or inpatients. An inexperienced programmer might write:
SELECT DISTINCT name FROM patients WHERE class NOT IN ('emergency','inpatient');
But that's wrong. This says get a list of unique names from the patients table where the class column has a value that is neither "emergency" nor "inpatient." What we really want is this:
SELECT DISTINCT name FROM patients WHERE class NOT IN ('emergency','inpatient') OR class IS NULL;
Although the predicate "OR class IS NULL" might seem redundant because NULL is certainly not in ('emergency','inpatient'), it is still necessary because otherwise SQL will skip over rows with null class values.

This arcane bit of programming trivia is not at all intuitive, nor really covered in any of the SQL tutorials or courses. It may not even be consistent across implementations of SQL--this is the behavior of SQL Server, and I really don't know if, say, Oracle or MySQL do the same thing. Yet if you don't know this, you will end up giving factually incorrect information to people.

Every programming language is full of landmines likes these--arcane bits of programming trivia that are unintuitive, poorly documented, and hugely important. And the fact is that much of the time, these errors don't actually throw errors for us--that would be too kind--but instead return deceptive correct-looking but wrong data. (On the other side of my work, the same thing happens in statistics. The fact that your regression returned valid-seeming coefficients does not make it so.)

I find these errors because a big part of my job is ensuring data integrity. I don't just find these issues, I hunt for them. I wouldn't expect, or even want, doctors and other researchers who use this data to run these queries themselves.

So, when it comes to teaching everyone some programming, we should be clearer about the objectives. We do want doctors and other important front line workers to be able to think critically about data needs, database design, and inputing data in ways to minimize the potential for human error, and a general education that includes programming will help with that. But we don't literally want doctors writing SQL statements in between patient visits.