A new seminar series on microeconomics at Vanderbilt

Posted on by

This Spring term, we will inaugurate a regular microeconomics brownbag seminar series for graduate students and faculty members at Vanderbilt to present ongoing research with connections to microeconomic theory.

The first session will take place on Tuesday, February 23, in Room 413B on the 4th floor of Calhoun Hall, from 12-1pm. Professor Yevgeniy Vorobeychik from the Computer Science and Computer Engineering department will talk about “Computational Game Theory, and Its Role in Security, Privacy, and Healthcare”.

A light lunch will be served starting at 11.45 am.

For more information about this seminar series, see https://vumicrobrownbag.wordpress.com/ or contact me at  martin.van.der.linden@vanderbilt.edu.

Absolute vs relative poverty : what do people think?

Posted on by

Poverty, Resource Equality and Social Policies

In a recent post on the blog, we presented Martin Ravallion‘s discussion of absolute and relative poverty.  In a nutshell, an absolute poverty measurement counts an individual as poor if her consumption lies below some level of deprivation associated with what is viewed as “basic needs”.  On the other hand, relative poverty measurements consider that an individual is poor if she is sufficiently disadvantaged as compared with other individuals in her country or region.

There exists a vivid debate between advocates of absolute and relative conceptions of poverty. Which notion of poverty should prevail — if any — is still an open question among researchers. Now, choosing between absolute and relative poverty notably involves value judgments about what a decent life is, and scholar should certainly not monopolize the debate. At the political level, this choice requires a healthy democratic debate. As any decision process requiring a public deliberation…

View original post 634 more words

Synchronizing attached files in Zotero

Posted on by

Zotero offers free database synchronization across devices, but if you want to synchronize more than 300Mb of attached files through Zotero’s official storage service, you will have to subscribe to a paid plans.

For not searching enough in Zotero’s documentation, I initially thought Zotero’s official storage service was the only way to go. For a while, I had been using a hand-made  iffy solution relying on a dropbox-like synchronization of my “Literature” folder, in order to have my attached files synchronized without paying. I discovered the hard way that this “solution” was not without problems (see https://forums.zotero.org/discussion/56023?page=1#Item_4).

Then, as I was working out the problems with my hand-made solution, I rediscovered that Zotero’s folks are really all you can expect from open-source developers. Among other things — and  unlike folks at Mendeley, they do not want to trap you into using their own storage service. This means you can safely use a free third party storage to synchronize your attached files. Just follow the procedure described  on https://www.zotero.org/support/sync, under the title WebDAV.

Zotero even maintains a list of third party storage providers which are known to work fine with Zotero : https://www.zotero.org/support/kb/webdav_services.

I personally chose 4shared and have been happy with it so far (4shared’s connection to Zotero used to be a little hard to set up — see http://www.steletch.org/spip.php?article83, but this problem was solved in later versions of Zotero).

 

School choice in Python

Posted on by

Check out my new Github repository at https://github.com/vanderlindenma/school_choice_python.

It contains code to compute school choice assignments via Deferred and Immediate acceptance, and explanations on how to apply the code to different school choice settings.

The code is based on former code by Jeremy Kun, stable-marriage, (2014), GitHub repository, https://github.com/j2kun/stable-marriages, described in one of Jeremy’s blog posts at http://jeremykun.com/2014/04/02/stable-marriages-and-designing-markets/.

I hope to expand on the code and add more functionalities soon.

Otree : when treatment variables don’t fit into a model field

Posted on by

In oTree, because treatment variables are stored as models, your treatment
variable must fit into one of the field types available in Django (see oTree’s documentation on treatment variables).

In this post I’ll describe a hack to circumvent this limitation. It is kind of ugly but it works for me, and it’s the only way I have found to have lists as treatment variables.

The idea is to first convert your treatment variable into a string
and then convert the string back to its intended format.

To do so, you can use the ast package.
For instance, if your treatment variable consists in choosing between the
two lists [1,2,3] and [3,1,2] at the level of the group, you
would first define a treatment field on the Group model:

class Group(BaseGroup):
# ...
   treatment = models.CharField()

Then inside the before_subsession_starts method, you would turn the
chosen list into a string and assign it to treatment (because
treatment is a CharField, it can only be assigned strings)

def before_session_starts(self):
   for group in self.get_groups():
# Turn the chosen list into a string
      group.treatment = '%s' %(random.choice([1,2,3],[3,1,2])

Assuming [1,2,3] was picked, group.treatment is now a string of the
form '[1,2,3]'. Thus, you will need to define a method that will
convert the string group.treatment back to a list whenever
you need it. To do so, first import the package ast:

# Add the following to the import statements before
# class Constants(BaseConstants):

import ast

Then define the following method inside the Group model:

class Group(BaseGroup):
# ...
   def convert_to_list(self):
      self.treatment = ast.literal_eval(self.treatment)

You can now use your treatment variable as a list by calling
convert_to_list. For instance, if you want to use your list
in the Decide page, you could call convert_to_list inside
the vars_for_template method inside view.py:

class Decide(Page):
# ...
   def vars_for_template(self):
#...
      self.group.convert_to_list()

This will make group.treatment available as a list in the
corresponding template.

Troubleshooting

  1.  Remember to have a look at the doc on treatments from oTree. The example above is for treatments at the group level, and you may need to adapt this according to your needs (e.g. by storing your treatment variable in the participant.var of the first player in the group as described in the doc).
  2. One complication with using Django model.CharField() is that it may change the encoding of your string from utf-8 or ascii to unicode. If that causes trouble, you may need to redefine your convert_to_list method to something like
class Group(BaseGroup):
# ...
   def convert_to_list(self):
      if isinstance(self.treatment,str):
         self.treatment = ast.literal_eval(self.treatment)
      if isinstance(self.treatment,unicode):
         self.treatment = ast.literal_eval(self.treatment.encode("utf-8"))

A glance at python’s “tagging” of objects

Posted on by

Just learned the hard way about some basics of python’s memory management. For people coming from R or other languages, it might be confusing to realize that if you define

x = [1,2,3]

set

x = y

and then modify x, for instance through

x.append(4)

the change in x will propagate to y. This means that if you query the value of y, you will in fact get

[1,2,3,4]

This also means that the sequence

x = [1,2,3]
x.append(4)

Is very much different from

x = [1,2,3,4]

For more on this and how to “really” define a new list with some life of its own in the memory, but with the same value as x, see http://henry.precheur.org/python/copy_list.

Tackling Python’s project structure

Posted on by

I recently started playing with oTree (“a Django-based framework for implementing multiplayer decision strategy games.”) in order to code a school choice experiment. This lead me to dig deeper into Python.

One of the issue I got stuck on is probably the most basic issue of all : how to structure the folder and subfolders containing my Python code?

I was not looking for anything fancy here. The code for oTree experiment is mostly located in a file called  model.py and all I wanted was a way to

  • Define the Classes I use in model.py in separate files that I could later “import” in model.py, so that model.py does not become crazy long and unreadable
  • Group the files in which I define those classes into subfolders so that the folder containing model.py does not get overcrowded either.
  • E.g : because I am coding a school choice experiment, I wanted to have a subfolder containing all the solvers that I use to compute the final assignments based on preferences and priorities, and later import the corresponding classes in model.py in order to compute participants’ payoffs.

As basic as this problem may seem, the solution is not obvious (at least to me). Googeling  this kind of issues yields a ton of different solutions, and it’s easy to get lost.

The most understandable and functional solution I have found so far is : http://mikegrouchy.com/blog/2012/05/be-pythonic-__init__py.html

If we are to believe the title, this should also be a “Pythonic” solution, which means it should — hopefully — put you at peace with Python aesthetes (from what I understand, “Pythonic” means something like “in the spirit of Python” or “following the coding strandards which are considered good practice by Python’s community”, whatever that may mean).

Two warnings about the solution in the above links:

  • Although the solution claims to be “Pythonic”, I’ve often seen people argue against the use of imports of the form from subpackage import *. These people usually say that these tend to “clutter the namespace”. The truth is I have no idea what that refers to, so I don’t know whether the argument applies to the use of import *  described in the links. Anyways it is good to know that import * can sometimes freak people out, even if — like myself — you don’t quite understand why.
  • Suppose that following the solution described in the link, you’ve specified the __all__ variable in __init__ in the subpackage directory , and you run  from subpackage import * from file2.py (in the package directory).   Now say you want to access That_Class, one of the Classes from submodule2.py in the subpackage directory. Don’t be surprised if calling  That_Class() from file2.py returns the error NameError: name 'That_Class' is not defined. Indeed, you’ve only imported submodule2.py “as a single object”, and not all the Classes it contains individually. Therefore In order to call That_Class from file2.py, you will need to use submodule2.That_Class().