A comparison of programming languages in economics

8 Jul

Interesting comparison of programming language speeds. Given that the big data world seems to be all about Python, I wonder if folks start doing complicated calculations over big data if they will move away from Python? SAS is apparently working on “Accelerators” to work on hadoop nodes which appear to address this same problem. They already have them for Databases and Db appliances.

The above makes sense if you consider that for the most part “big Data” is about folks doing simple calculations in parallel  over many data nodes.

The thread of comments below the article are also interesting.


There is a new NBER working paper with that title, by S. Borağan Aruoba and Jesus Fernandez-Villaverde. Here is the abstract:

We solve the stochastic neoclassical growth model, the workhorse of modern macroeconomics, using C++11, Fortran 2008, Java, Julia, Python, Matlab, Mathematica, and R. We implement the same algorithm, value function iteration with grid search, in each of the languages. We report the execution times of the codes in a Mac and in a Windows computer and comment on the strength and weakness of each language.

Here are their results:

1. C++ and Fortran are still considerably faster than any other alternative, although one needs to be careful with the choice of compiler.

2. C++ compilers have advanced enough that, contrary to the situation in the 1990s and some folk wisdom, C++ code runs slightly faster (5-7 percent) than Fortran code.

3. Julia, with its just-in-time compiler, delivers outstanding per formance. Execution speed is only between 2.64 and 2.70 times the execution speed of the best C++ compiler.

4. Baseline Python was slow. Using the Pypy implementation, it runs around 44 times slower than in C++. Using the default CPython interpreter, the code runs between 155 and 269 times slower than in C++.

5. However, a relatively small rewriting of the code and the use of Numba (a just-in-time compiler for Python that uses decorators) dramatically improves Python ’s performance: the decorated code runs only between 1.57 and 1.62 times slower than the best C++ executable.

6.Matlab is between 9 to 11 times slower than the best C++ executable. When combined with Mex files, though, the difference is only 1.24 to 1.64 times.

7. R runs between 500 to 700 times slower than C++ . If the code is compiled, the code is between 240 to 340 times slower.

8. Mathematica can deliver excellent speed, about four times slower than C++, but only after a considerable rewriting of the code to take advantage of the peculiarities of the language. The baseline version our algorithm in Mathematica is much slower, even after taking advantage of Mathematica compilation.

There are ungated copies and some discussion here.



The more things change, the more they stay the same…

16 Jun

Very amusing article – totally agree that the addition of a CDO if too broadly defined begins to confuse things. Is the CDO part of an integrated strategy to move things ahead, or a tactical band-aid response to an organizational problem?


Self Service BI

29 May

Good article on Self Serve BI. The term has been around a while, but never seems to get old.

Interesting thought process to identify analytical approaches

29 Jan

Courtesy of a colleague in the medical data management world – check out this graphic. It is missing a few approaches, but lays out the thought process well.

Machine Learning - Cheastsheet

The Booz Allen Field Guide to Data Science has a similar linkage that is useful. That book can be downloaded here

While I am at at, I found this good book Managing Research Data by Graham-Pryor that focuses on managing research data. I continue to be surprised at the approaches taken by “traditional” data management folks to feed the analytical processes. The old school way of dealing with analytics data did not work well which has created some of the organizational work arounds that exist in companies. This only gets worse when dealing with large amounts of data, and data that must work across systems / sources.

Seven ways to use Big Data in Health Care

2 Jan

This article  summarizes a range of ways that health organizations are using big data in the post-ACA environment.




It’s good reading for shedding light on the role of private companies in driving analytics innovations.



Interesting observations on the healthcare system implementation

9 Dec

Many thanks to http://www.bespacific.com/ for forwarding this post. I often get funny looks when I tell people that the expected outcome may not be the desired outcome. With ones analyst hat on, it is easy to say this – one has a hypothesis, and one tests it. If the hypothesis proves false, then we have identified a place not to go, or a refinement in thinking. For an analyst “failure” (as defined below) is an option. For program managers, it must be an option, but one that is so hard to manage – generally the inability to address this issue starts at the top, and is framed within the culture of the organization.

As a project manager, one would think it is an option – identified as a “risk” in PMP speak, and addressed and managed as such. We will not know the details of what happened for a while, but the article below sheds some light.

HealthCare.gov and the Gulf Between Planning and Reality
By Irving Wladawsky-Berger
Guest Contributor, WSJ

 It’s way too early to know what really happened with the botched launch of HealthCare.Gov.  We don’t know how it will all play in years to come and what its impact will be on the evolution of the Alternative Care Act, on election results over the next few years, or on President Obama’s legacy. Depending on how it all turns out over time, this will be just a chapter in future books on the history of the ACA and the Obama administration, or the subject of major books and investigative reports.

 Most everyone who’s been involved with the development of complex IT systems knows how wrong things can sometimes go.  So, when serious problems do happen, we are eager to learn the lessons that might help us avoid similar problems in the future. It’s quite possible that HealthCare.gov and the ACA’s overall IT system are such complex outliers–technically, organizationally and politically–that any lessons learned might apply to few other projects.  But, given the increasing complexity of private and public sector IT systems, the lessons are worth thinking about.

 I like the way Clay Shirky, NYU faculty member as well as author and consultant, framed the problem in a very interesting blog, Healthcare.gov and the Gulf Between Planning and Reality.  He writes about the gulf between those charged with planning the overall rollout of the ACA and health care exchanges and the realities of trying to get such a complex system designed, built and launched in a short amount of time. It’s essentially a tale of failure is not an option versus the messy world of highly complex IT systems. While the blog is focused on the launch of HealthCare.gov, it can also be read as a more general discussion of the kinds of problems often encountered with highly, complex IT-based projects when a management decision to win a deal at all costs comes back to haunt the implementation of the project.

 “For the first couple of weeks after the launch, I assumed any difficulties in the Federal insurance market were caused by unexpected early interest, and that once the initial crush ebbed, all would be well,” he writes.  “The sinking feeling that all would not be well started with this disillusioning paragraph about what had happened when a staff member at the Centers for Medicare & Medicaid Services [(CMS)], the department responsible for Healthcare.gov warned about difficulties with the site back in March.”

 The paragraph responsible for Mr. Shirky’s sinking feeling was part of an October 12 NY Times article, From the Start Signs of Trouble at Health Portal. According to the article, the warnings came from CMS deputy CIO Henry Chao, the chief digital architect for the new online insurance marketplace. In response, his superior told him:

 “. . . in effect, that failure was not an option, according to people who have spoken with him. Nor was rolling out the system in stages or on a smaller scale, as companies like Google typically do so that problems can more easily and quietly be fixed. Former government officials say the White House, which was calling the shots, feared that any backtracking would further embolden Republican critics who were trying to repeal the health care law.”

 “The idea that failure is not an option is a fantasy version of how non-engineers should motivate engineers,” adds Mr. Shirky. “Failure is always an option. Engineers work as hard as they do because they understand the risk of failure.” In his opinion, neither technology, talent, budgets or the government’s bureaucratic processes are the main culprits here.  Rather, this is a management and a cultural problem.  As a result of the huge political pressures they were under, top administration officials did not feel that they could seriously address the possibility that things might go wrong.

 Other articles paint a similar picture, such as this recent one in the WSJ’s CIO Journal:

 “It was on a cold, sunny day in Baltimore last January that Curt Kwak, chief information officer of the Washington Health Benefit Exchange, first realized that the signature feature of President Obama’s Affordable Care Act could be in trouble.  That day, at a status review meeting of CIOs of state health exchanges, he learned that many of his peers were far behind where they should have been.  According to Mr. Kwak, several of his peers hadn’t yet selected a systems integrator – tech vendors who play crucial roles in fitting together the multiple components of health insurance exchanges that allow consumers to select and enroll in health plans.”

 Why did the administration, as well as several states, wait so long to start the planning of the ACA system including the health care exchanges?  Ezekiel Emanuel– oncologist, vice provost and professor at the University of Pennsylvania and former White House advisor on health policy–said in a good article on the subject that the administration did not want to release detail regulations and specifications on the exchange while in the middle of the 2012 election campaign in order to avoid political controversies. “This may have been a smart political move in the short term, but it left the administration scrambling to get the IT infrastructure together in time, robbing it of an opportunity to adequately consult with independent experts, test the site and fix any problems before it opened to the public.”

 But, then came the reality, which Mr. Shirky describes as the painful tradeoff between features, quality and time.

 “When a project cannot meet all three goals–a situation Healthcare.gov was clearly in by March–something will give.  If you want certain features at a certain level of quality, you’d better be able to move the deadline. If you want overall quality by a certain deadline, you’d better be able to simplify, delay, or drop features.  And if you have a fixed feature list and deadline, quality will suffer. . . You can slip deadlines, reduce features, or, as a last resort, just launch and see what breaks. . . That just happened to this administration’s signature policy goal.”

 The inability of a troubled project to meet all three goals simultaneously, almost feels like the complex systems equivalent of the Heisenberg uncertainty principle; that is, it’s impossible to simultaneously determine the exact position and velocity of an atomic particle with any great degree of accuracy no matter how good your measurement tools are. While clearly not a scientific principle, but a set of guidelines based on decades of experience, there seem to be intrinsic limits to our ability to fix troubled IT projects no matter how hard we try.

 In The Mythical Man-Month, noted computer scientist and software engineer Fred Brooks introduced one of the most important concepts in complex IT systems: adding manpower to a late software project makes it later. Brooks’ Law as his concept became known, remains as true today as when it was first formulated almost 40 years ago.

 Over the years, we have learned that there are limits to our ability to pre-plan complex IT projects in advance. You need a good design, architecture and overall project plan, but you also need the flexibility to learn as you go and make trade-offs as appropriate. Most such projects are therefore released in stages, with alpha and beta phases that start testing the system with a select and relatively small number of users. Such early testing uncovers not only software bugs, but also design flaws that users have trouble with.

 Another important lesson is that all parties involved in a complex, high-risk project must have a good working relationship. All available information on the status of the project should be shared, so there are few last-minute surprises. Tradeoff decisions and project adjustments should involve all key members of the team. Behind most seriously troubled projects lies not only a gulf between planning and reality, but a lack of the close collaboration and overall good will necessary to make the project succeed.

 It’s hard to imagine a more politically contentious project than the ACA.  The administration was worried that any glitches uncovered while testing the system as part of the usual staged release cycle would give further ammunition to those trying to kill the ACA altogether. They may have felt that slipping deadlines and reducing features prior to the October 1 launch was not politically feasible, and that they therefore had no choice but to launch anyway and hope for the best.  Did they make the right decisions?  We’ll find out in the fullness of time.

 Irving Wladawsky-Berger is a former vice-president of technical strategy and innovation at IBM. He is a strategic advisor to Citigroup and is a regular contributor to CIO Journal.


The different aspects of BI

5 Dec


I like the recognition that approaches need to be integrated in order to create useful insights. Valuable insights come from balancing the needs and capabilities of  business strategy, business analysis, business intelligence and advanced analytics.

Big Data and Marketing – Geoffrey Moore

15 Nov

Geoffrey Moore does a good job of explaining big data and marketing – always a cogent explanation of things.

%d bloggers like this: