William E. Hart's Blog

Science Fiction Comes to Life

2012-02-01T22:41:00.000-08:00

One of my favorite authors is Vernor Vinge, who explores how the evolution of technology impacts future societies. Vernor is a former professor of computer science, so it is perhaps no surprise that his tech focus appeals to me. The novel The Peace War imagines a post-apocalyptic society that is recovering from a world war that was prompted, in part, by a new force field generating device (called the Bobbler).

There are all kinds of futuristic technologies described in this book, which is typical for Vinge's literature. In one scene, the protagonist is about to be ambushed by a group of bad guys. He hands a gun to his teenage companion, who takes out the bad guys without hardly aiming the gun. The trick is that the gun has computer-guided bullets, which the protagonist directed using his laptop.

This sounded like standard sci-fi tech fantasy until I heard about the self-guided bullet that has been developed by Sandia National Laboratories. Mashable has a fun video describing the work (see Yahoo News). Although I work at Sandia, the team working on this didn't invite me to the test range. Perhaps I'll get to help test out the Bobbler. ;)

Testing Open Source Software

2012-01-20T22:20:00.000-08:00

Software testing is widely recognized as a best practice for software development. Software tests define expected functionality, and they can focus developer efforts by providing an objective assessment of the state of a software project. Additionally, software testing data can provide evidence that a software package can be reliably used. For example, when evaluating whether to try out open source software, I routinely look for software testing data to confirm which platforms the software will run on, the versions of associated software that is used, and test coverage statistics that indicate how much of the the code is tested.

Unfortunately, most open source software projects do not publish software test data. I suspects that this indicates that a small fraction of OSS projects have robust test suites. However, this also reflects another aspect of the OSS community: hosting facilities for open source software do not support web-based testing facilities, like Jenkins, that can be used by developers to remotely launch jobs on test machines with a variety of different configurations. This is not totally unexpected, since testing can be computationally intensive.

Recently, I learned about CloudBees, which provides cloud services for building, running and managing Java applications. Happily CloudBees makes its Dev@cloud service freely available to open source projects! This includes the Jenkins testing service, which provides a limited number of CPU hours each month for testing an OSS project. For example, the CxxTest project now hosts tests on a CloudBees Jenkins server. Cool!

A Different Model for Writing Blog Posts

2012-01-08T07:34:00.000-08:00

This is a blog that I have been meaning to write for sometime. I occasionally take a look at thedownload statistics for this blog, and recently I was prompted to do this byother bloggers who were reporting their end-of-year statistics (e.g. see Laura McLay’s review of the Punk Rock OR blog).

Unlike Laura, I do not have impressive download statisticsto report about the many blogs I have written in 2011; frankly, I did notcreate many posts. However, an interesting pattern has emerged regarding thisblog’s readership: there are a few keyblog posts that are frequently downloaded. For example, my most frequently downloaded blog post is a survey ofPython plugin software, which I wrote in 2009. I suspect that other bloggers have seen the same thing; they have a fewposts that are very popular because people do web searches on that topic. However, it is worth stepping back andthinking about the implications of this when writing a blog.

When I first started blogging, I imagined that readers wouldview my blog the way that I view Laura’s blog. They would use a RSS feeder to collect and view blog updates. These would be read shortly after they werepublished, and afterwards they might be used as a reference. This led me to create blogs that referencedeach other as part of a larger conversation on a topic. For example, after blogging about Python Plugin Frameworks, I had severalfollow-up blogs, including a brief description of PyUtilib Plugins that I had developed.

However, I have realized that my blogs are more likely to befound through internet searches focused on a topic. Consequently, the Python Plugin Frameworkspost gets frequently read while the PyUtilib Plugins post rarely getsread. Readers are finding my blog postsafter searching for “python plugins”. The narrower topic covered by thePyUtilib Plugins post is not frequently referenced on the internet, andconsequently it is not strongly associated with the more general topic ofPython plugins; for example, I did not see it in the first three pages of agoogle search for “python plugin”.

This suggests a different model for writing blog posts thathas already begun to affect my blogging. Since blog posts are individual artifacts that may have enduring valueto readers, updating a blog post with new content makes more sense thancreating a new post that continues the previous discussion. For example, I’ve updated the Python PluginFrameworks post to include references to PyUtilib’s plugins. This may confuse readers of RSS feeds, and Ido not know that RSS feeds will automatically update their feed to capture updateslike this. I would assume not. However,this is clearly a strategy that will enhance the long-term impact of a blogpost on a specific topic.

The Pyomo Book is Coming Soon

2012-01-07T22:09:00.000-08:00

The Python Optimization Modeling Objects (Pyomo) package is an open source tool for modeling optimization applications in Python. Pyomo can be used to define symbolic problems, create concrete problem instances, and solve these instances with standard solvers. Pyomo provides a capability that is commonly associated with algebraic modeling languages such as AMPL, AIMMS, and GAMS, but Pyomo's modeling objects are embedded within a full-featured high-level programming language with a rich set of supporting libraries. Pyomo leverages the capabilities of the Coopr software library, which integrates Python packages for defining optimizers, modeling optimization applications, and managing computational experiments.

Of course, there is very little online documentation describing Pyomo. However, the first book on Pyomo is set to be published in February!

Pyomo - Optimization Modeling in Python. William E. Hart, Carl Laird, Jean-Paul Watson and David L. Woodruff. Springer, 2012.

Here are some links if you want to learn more:

Enjoy!

A Pythonic C++ Parser

2012-01-07T21:25:00.000-08:00

If you google for "python C++ parser", you will find a variety of internet discussions related to parsing C++ in Python. C++ cannot be parsed by a LALR parser and it is well-known that parsing C++ is a nontrivial task. Thus, these discussions generally fall into one of several categories:

It is too hard to parse C++ in Python, so use a package like GCC_XML that does this for you. If you really need to do something in Python, write a wrapper to GCC_XML.
It is too hard to perform a complete parse of C++ in Python, but we can use a LALR parser to collect gross structural information from C++ files. The CppHeaderParser is an example of this type of package, which uses the ply parser to collect information about classes in header files.

In the recent release of CxxTest, I included a LALR C++ parser that is similar to CppHeaderParser. CxxTest is a unit testing framework for C++ that is similar in spirit to JUnit, CppUnit, and xUnit. CxxTest is easy to use because it does not require precompiling a CxxTest testing library, it employs no advanced features of C++ (e.g. RTTI) and it supports a very flexible form of test discovery.

CxxTest performs test discovery by searching C++header files for CxxTest test classes. The default process fortest discovery is a simple process that analyzes each line in aheader file sequentially, looking for a sequence of lines thatrepresent class definitions and test method definitions.

I added a new test discovery mechanism in CxxTest 4.0 that is basedon the a parser for theFlexible ObjectGenerator (FOG) language, which is a superset of C++. The grammarfor the FOG language was adapted to parse C++ header files toidentify class definitions and class inheritance relationships,class and namespace nesting of declarations, and class methods.This allows CxxTest to identify test classes that are definedwith complex inheritance relationships.

As I noted earlier, the CxxTest FOG parser is similar to the parser in CppHeaderParser. Based on my limited knowledge of CppHeaderParser, here are some points of contrast between these two capabilities:

The FOG parser is embedded in CxxTest, while the CppHeaderParser is a stand-alone package. Although I implemented the FOG parser as a separate component in CxxTest, I did not have specific design requirements that led me to make this a separate package. (Interested parties should give me a buzz...)
The FOG parser is a specifically focused on the features required by CxxTest, and thus it does not parse out much of the information that CppHeaderParser provides (return values, argument types, etc).
The FOG parser was specifically designed to capture class inheritance relationships. It is not clear to me that the CppHeaderParser does this.
The FOG parser is based on a superset of C++. Thus, it can robustly parse C++ method and function definitions. The examples provided by CppHeaderParser suggest that it can parser function and method declarations, but not headers that include their definitions. (Of course, the FOG parser ignores these definitions, but that's the point. The parser can do that.)
The FOG parser has been tested on a large set of C and C++ test files that are used to test the ELSA compiler. This is a much more extensive test suite than is used to develop CppHeaderParser.

The point of this comparison is that the FOG parser may be of interest for other C++ parsing applications. It has not been developed for general use, but it could easily be adapted to provide a more general capability.

OptimJ is now free, but Ateji is closed

2011-10-05T23:14:00.000-07:00

Atjei, the creater of OptimJ, is now closed. The OptimJ product is a Java extension that supports a simplified syntax for specifying optimization models. It is sad to see this product be abandoned like this. I do not know of any other optimization modeling tool that directly supports Java.

Erwin Kalvelagen noted the demise of Ajeti, and commented that "I believe that some of the more complex data issues in practical modeling are often better (i.e. more efficiently) dealt with in a specialized language than in a traditional programming language." Pyomo is similar to OptimJ, in that it supports optimization modeling in Python. However, a premise that has guided Pyomo development is that users will want to perform modeling in a full-featured programming language.

Clearly, traditional programming languages are more verbose and complex than a domain-specific language. However, Python is arguably much simpler to use than Java. In fact, I have gotten feedback from Pyomo users that suggests that they were not aware that they were developing models in Python; they simply thought that it was another modeling language!

Of course, I am a programmer who likes to do optimization. My selfish reason for creating Pyomo is that I find domain-specific languages quite constraining. In fact, I had thought that the use of Python for modeling and optimization would be attractive to optimization researchers. Python is a great language for prototyping a complex idea, usually without losing too much performance. I and other Pyomo developers have implemented complex optimizers in Python that directly interface with Pyomo models, and in most cases the runtime is dominated by LP subproblems. Thus, there has been little motivation to develop custom, highly-optimized codes in languages like C++ based on these solvers.

Using AsciiDoc for Mathematical Publications

2011-09-23T22:26:00.000-07:00

Technical writing is an integral part of my research in computer science and operations research. I have a long history using LaTeX, which is very well suited for writing technical articles that contain mathematical equations as well as code snippets. Although LaTeX can readily generate postscript and PDF output files, I have been unimpressed with tools that generate HTML from LaTeX source. Thus, I was intrigued by AsciiDoc, which promises to generate PDF, HTML and eBook formats. AsciiDoc is used to provide online documentation for software projects, and authors can publish book through O'Rielly using this tool. Thus, this is a well-developed document generation tool.

I have successfully prototyped a draft book, Getting Started with Coopr, and you can browse the subversion repository for this document here. Note that the Makefile file specifies build targets for PDF, HTML and eBook files.

The advantage of AsciiDoc is that you can use a simple markup language to generate complex documents in a variety of formats. Since this is a generic document-generation process, it is reasonable to expect that there will be limited control of document formatting. (If you want a lot of control, you should just use LaTeX!) However, there are several major limitations to the document generation and format control that limit what you can do with AsciiDoc:

Portable Mathematical Equations: There is only limited support for generating eBook documents that contain mathematical equations. I noticed that the ePUB standard was just updated this month to support MathML, so it is not clear that e-readers can handline MathML right now. Additionally, AsciiDoc does not support the generation of the MathML XML from a high-level description (e.g. LaTeX math equations). Thus, a user cannot easily prepare a document that generates both PDF (using LaTeX under the hood) and ePUB (using MathML under the hood). I guess we will have to wait a few more years to see robust publishing of mathematics for eBooks.
Formatting Mathematics: For whatever reason, the default formatting of mathematical environments in HTML is not centered or indented (as it is in LaTeX). Thus, it is much more difficult to read HTML documents containing mathematics. I tried resolving this using an AsciiDoc filter, without luck. I wound up rewriting the LatexMath macros to enforce this different formatting in HTML. Unfortunately, these revised macros do not precisely match the syntax used by AsciiDoc. {sigh}
Document Authors: The AsciiDoc markup language does not provide a convenient way to create a document with multiple authors. Yes, I am not kidding. There is a docbook configuration file that you can provide, which only works if the document generation process goes through docbook; in my example, that works for ePUB and PDF files. Thus, there does not appear to be a single, portable way for specifying multiple authors.
Citations: It is noteworthy that none of the examples of online books referenced in the online AsciiDoc documentation contain citations or a bibliography. The default format for bibliographies in AsciiDoc PDF files is as a numbered chapter or section, which differs from the normal convention in LaTeX (which I much prefer). Thus, my AsciiDoc book uses the colophon section, which is not numbered. However, that means that it does not show up in the table of contents. {sigh}

Another issue with citations is that the examples provided by AsciiDoc do not correctly generate hyperlinks in the PDF file. Basically, the bibliography section type provided by AsciiDoc does not work well with the dblatex tool used to generate the PDF. My solution was to not use the bibliography section type!

Finally, the examples provided by AsciiDoc include citations in a list environment, which means that the PDF output contains a numbered list followed by a bracket citation reference. Again, my solution was to avoid using the list; the bibliography is simply a sequence of paragraphs, each of which is a citation with its associated anchor.

Despite these issues, I am planning to continue developing the Coopr documentation with AsciiDoc. The lack of support for mathematical equations is a problem for ePUB documents, but most readers will be using this document to refer to the examples in python. However, I would not consider using AsciiDoc for developing more complex documents, like a book intended for publication. There is too much customization that would be needed to get past the current limitations.

Coopr Download Fun

2011-08-05T06:03:00.000-07:00

I stumbled across the following site, which provides download statistics for PyPI Python optimization packages:

http://taichino.appspot.com/pypi_ranking/keyword/optimization

It was fun to see the different download package statistics. I'm quite curious that coopr.pysos has the highest number of downloads, since IMHO this package doesn't have much interesting functionality... Hmmm...

Another surprise for me is that so many optimization Python packages are _not_ on this list! I am maintaining the following list of links for Python optimization packages:

https://software.sandia.gov/trac/coopr/wiki/Documentation/RelatedProjects

Perhaps these packages were not tagged with the 'optimization' label ... or perhaps they were not downloaded enough to make the list?

Python Optimization Packages

2011-07-23T09:25:00.000-07:00

I have been maintaining a list of Python optimization packages for a while now on the Coopr Trac pages: see https://software.sandia.gov/trac/coopr/wiki/Documentation/RelatedProjects.Today, I noticed that if you google for "python optimization packages", this page does not show up right away. Perhaps Trac pages are index differently? I'm not sure.

Anyway, I thought I'd add this reference here to help others find this list that I'm maintaining...

Coopr 3.0.4362 Release

2011-07-23T09:21:00.000-07:00

We are pleased to announce the release of Coopr 3.0 (3.0.4362). Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

The following are highlights of this release:

- Solvers
* More sophisticated logic for solver factory to find ASL and OS solvers
* Various solver interface improvements
* New Solver results object for efficient representation of variable values
* New support for asynchronous progressive hedging

- Modeling
* Changes in rule semantics to limit rule return values
* Changes in the expected order of rule arguments
* Constant sums or products can now be used as constraint bounds
* Added full support for the !ConstraintList modeling component.

- Usability enhancements
* More explicit output from runph and runef commands
* Added support in runef to write the extensive form in NL format
* Add controls for garbage collection in PH

- Other
* Efficiency improvements in generation of NL and LP files.
* Significant efficiency improvements in parsing of Pyomo Data Files.
* More robust MS Windows installer (does not use virtual python
* environment)

Note that this is a major release of Coopr that changes the expected formulation of Coopr models. See the Coopr blog for further details about deprecated functionality, which will be disabled in future releases.

See https://software.sandia.gov/trac/coopr/wiki/GettingStarted for instructions for getting started with Coopr. Installers are available for MS Windows and Unix operating systems to simplify the installation of Coopr packages along with the third-party Python packages that they depend on. These installers can also automatically install extension packages from Coin Bazaar.

Enjoy!

- Coopr Developer Team
- coopr-developers@googlecode.com
- https://software.sandia.gov/trac/coopr/wiki/Documentation/Developers

-----------
About Coopr
-----------

Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

A key driver for Coopr development is Pyomo, an open source tool for modeling optimization applications in Python. Pyomo can be used to define symbolic problems, create concrete problem instances, and solve these instances with standard solvers. Thus, Pyomo provides a capability that is commonly associated with algebraic modeling languages like AMPL and GAMS.

Coopr has also proven an effective framework for developing high-level optimization and analysis tools. For example, the PySP package provides generic solvers for stochastic programming. PySP leverages the fact that Pyomo's modeling objects are embedded within a full-featured high-level programming language, which allows for transparent parallelization of subproblems using Python parallel communication libraries.

Coopr development is hosted by Sandia National Laboratories and COIN-OR:

* https://projects.coin-or.org/Coopr
* https://software.sandia.gov/coopr

See http://groups.google.com/group/coopr-forum/ for online discussions of Coopr.

2011-03-28T08:58:00.000-07:00

Coopr 2.5(2.5.3890) has just been released! Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

The following are highlights of this release:

- Solvers

* MIP solver interface updates to use appropriate objective names

* Added support for suffixes in GUROBI solver interface

* Improved diagnostic analysis of PH solver for the extensive form

- Usability enhancements

* Improved robustness of coopr_install

* Fixed Coopr installation problem when using easy_install

* Added a script to launch the CooprAge GUI.

* LP files now are written with the true objective name

* Rework of pyomo command line to create a concise output

* Many efficiency improvements during model generation!

* Many improvements to diagnostic output and error handling

* Expressions like "model.p > 1" can now be used within generation rules

- Modeling

* Added support for generalized disjunctive programs (in coopr.gdp)

* Constraints can now be specified in "compound" form: lb <= expr <= ub

* Significant robustness enhancements for model expressions

* Improved error handling for constraint generation

- Other

* Python 2.5 is deprecated due to performance issues

* Python versions 2.6 and 2.7 are supported

* New MS Windows installer is now available

See the Coopr wiki for further details!

Getting Started with a Virtual Python Installation

2010-11-26T16:59:00.000-08:00

Working with and developing Python software is complicated by several factors:

Many users do not have the administrative privileges that are needed to install packages in the Python site packages directory, where Python packages are most easily installed
Python developers often need to manage many Python projects in the same development environment

The Python virtualenv package resolves these issues by allowing users to generate a local Python installation. Thus, a user can create a Python installation into which they can install Python packages using standard tools like easy_install and pip.

Unfortunately, getting started with virtualenv is complicated by the fact that you need to install this package to create virtual Python installations. But, if you do not have administrative privileges, then you are stuck. This is the simplest process that I have seen:

hg clone http://bitbucket.org/ianb/virtualenv
virtualenv/virtualenv.py ENV

Unfortunately, the hg command may not be preinstalled on your machine. It is not available on any of mine...

The pyutilib.virtualenv package contains the vpy_install script, which can bootstrap the setup of virtualenv. This script extends the functionality of the virtualenv driver script to allow direct, and it customization of this initial environment. The vpy_install script can be easily downloaded from the PyUtilib wiki, or it can be downloaded with commands like wget or curl:

wget http://doiop.com/pyutilib/vpy_install
vpy_install ENV

Installing Python Software Packages: The Good, The Bad and the Ugly

2010-11-10T21:22:00.000-08:00

I almost gave the following presentation at the INFORMS Annual Meeting:

Installing Python Software Packages: The Good, The Bad and the Ugly

That is, I was scheduled to give this talk but my session co-organizer ran over and I had to summarize these slides in 5 minutes!

Anyway, these slides describe different strategies for installing Python software. Although I am a big fan of Python software development, robust strategies for software installation remains a challenge. This talk describes several different installation scenarios:

The Good: the user has administrative privileges

Installing on Windows with an installer executable
Installing with Linux application utility
Installing a Python package from the PyPI repository
Installing a Python package from source

The Bad: the user does not have administrative privileges

Using a virtual environment to isolate package installations
Using an installer executable on Windows with a virtual environment

The Ugly: the user needs to install an extension package from source

Installing a Python extension package from source
PyCoinInstall – Managing builds for Python extension packages

The last item referring to PyCoinInstall describes a utility being developed for the COIN-OR software, which is used within the operations research community. COIN-OR includes a variety of Python and C++ software packages, and this script uses a simple plug-in system to support the management of package builds and installation. Of course, this mostly does the easy packages right now...

While preparing these slides I realized that the vpy_install script I use for setting up virtual environments is probably of broader interest. I'll say more about this in a little bit. In the meantime, checkout the slides!

Reworking FAST

2010-08-31T19:31:00.000-07:00

The role of the FAST software repository has evolved over the past few years, and it is time to rethink what the goal of FAST is. See Rethinking the goal of FAST for some perspective about FAST. The upshot is that FAST has been reorganized to support an ensemble of independent software packages related to agile software development.

One important change in this reorganization has been the decomposition of the FAST Python software into independent components. Some elements of FAST are deprecated, and the rest have been spread out into various packages. See the FAST Blog for further details.

Update for gcovr

2010-08-29T13:20:00.000-07:00

The gcovr command provides a utility for running the gcov command and summarizing code coverage results. This command is inspired by the Python coverage.py package, which provides a similar utility in Python. Further, gcovr can be viewed as a command-line alternative of the lcov utility, which runs gcov and generates an HTML output.

Recently, the gcovr script has been broken out into a separate software package, which is managed at

https://software.sandia.gov/svn/public/fast/gcovr

This package has been uploaded to the Python PyPI repository to facilitate it installation with easy_install:

easy_install gcovr

Alternatively, the gcovr script can be downloaded directly:

https://software.sandia.gov/svn/public/fast/gcovr/trunk/scripts/gcovr

See the gcovr Trac page for further details about this tool. Although gcovr is increasingly used to generate coverage statistics within Hudson, the gcovr wiki documents a command-line text summary that I personally find very useful when developing tests to improve code coverage.

A New Python Package: pyutilib.autotest

2010-06-28T21:19:00.000-07:00

A while back I developed EXACT, a Python package for executing computational experiments using an XML-defined process. EXACT was designed to fill a particular niche in software testing: performing computational tests that involve the application of solvers to a suite of test problems. This sort of testing arises a lot when doing functionality testing for scientific software.

Unfortunately, EXACT was too complex:

The XML specification was complex and difficult to read
Experiments with many factors were assigned generic experiment IDs
It was hard to replication the execution of specific experiments
The experimental results were captured in XML results files that were difficult to browse

Even my close collaborators struggled to setup, run and analyze computational experiments! {sigh}

I have recently developed the pyutilib.autotest Python package to provide a simpler alternative to EXACT. This package uses a YAML test configuration file to specify the solvers and problems that are exercised in a test. The tests setup and executed with Python's unittest package, which allows the user to apply a rich set of testing methods. The user can specify a test driver in Python that defines how each test is executed, using the solver and problem options that are specified in the configuration file.

Here's a simple example of a YAML test specification, where the goal is to apply the UNIX cat command with different options to different test files:

driver: example

solvers:
    cat:
    cat2:
        name: cat
        cat_options: -n

problems:
    f1:
        file: file1.txt
    f2:
        file: file2.txt

suites:
    suite1:
        solvers:
            cat:
            cat2:
        problems:
            f1:
            f2:

See the pyutilib.autotest PyPI documentation for further details.

Dynamic Service Creation in the PyUtilib Component Architecture

2010-06-21T14:24:00.000-07:00

The PyUtilib Component Architecture (PCA) is a component architecture in Python that is derived from the Trac component framework. One important extension was to support both singleton and non-singleton plugins. Trac plugins are singletons that are created immediately when the plugin module is loaded (Python is a wonderful language for supporting this type of capability). Singleton plugins are well-suited for Trac, since it is a persistent application, but many other applications need to employ plugins "on demand". Consequently, the PCA supports non-singleton plugins, which need to be explicitly constructed by the end-user.

The PCA is widely used in the Coopr project, and most plugins are non-singletons. Until recently, the PCA did not directly support plugin construction on demand. That is, the user needed to know the plugin class name, and plugin construction was done explicitly by the user. However, most plugins in Coopr can be best described as named services. For example, Coopr optimizers are implemented as plugins and each optimizer has a unique name.

The PCA has recently been extended to support the alias function, which can be used to declare the name of a plugin with respect to a particular interface. For example, consider the following definitions of the MyPlugin and YourPlugin plugin classes:


class ITask(Interface):

  def print(self):

class MyPlugin(Plugin):

  implements(ITask)
  alias('my', ITask)

  def print(self):
      print "My Plugin"

class YourPlugin(Plugin):

  implements(ITask)
  alias('your', ITask)

  def print(self):
      print "Your Plugin"

These plugins are non-singletons, so they are only registered and used if they are constructed. The alias function allows these plugins to be constructed with a factory class that is supported by the PCA. For example:


factory = CreatePluginFactory(ITask)

p1 = factory('my')
p2 = factory('your')

The CreatePluginFactory class is provided by the PCA, and it provides a functor that manages the creation of plugins whose names are registered with the alias function.

Blogs for Coopr and PyUtilib

2010-06-21T12:19:00.000-07:00

This is just a heads-up that I have setup blogs for the Coopr and PyUtilib software projects:

Coopr: https://software.sandia.gov/trac/coopr/blog
PyUtilib: https://software.sandia.gov/trac/pyutilib/blog

These blogs will document releases and end-user advice and examples. Additionally, there will hopefully be other authors than just me adding content to these blogs. But, I guess we'll see.

PyUtilib Component Architecture

2010-04-16T14:19:00.000-07:00

I earlier mentioned that I developed a plugin framework within my PyUtilib software. This is now called the PyUtilib Component Architecture (PCA). The PCA is derived from the Trac component architecture, and it supports advanced features like nonsingleton components, namespaces and caching of component interactions. The PCA includes an independent, self-contained framework core that can be easily integrated into other applications, as well as a variety of extension packages with commonly used components.

See The PyUtilib Component Architecture for further details.

Recent Coopr Developments

2010-04-16T14:07:00.001-07:00

Coopr is a collection of Python optimization-related packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models. The following are key Coopr capabilities that are driving Coopr development:

Pyomo: Formulate algebraic models within Python's modern programming language
PySP: Generic solvers for stochastic programming problems
COLIN: Scripts that simplify IO between optimizers and black-box applications
SUCASA: Customize MIP solvers to expose model structure to the MIP solver engine

See https://software.sandia.gov/trac/coopr/wiki/GettingStarted for instructions for getting started with Coopr. An installation script, coopr_install, is provided to simplify the installation of Coopr packages along with the third-party Python packages that they depend on. This installer can also automatically install extension packages from Coin Bazaar. See http://groups.google.com/group/coopr-forum/topics for online discussions of Coopr.

Two recent Coopr developments are noteworthy:

I. Coopr development is now co-hosted by Sandia National Laboratories and COIN-OR:

Coopr includes wrappers for COIN-OR solvers, and Coopr directly leverages the COIN-OR Coin
Bazaar project to host plug-in packages for Coopr (e.g., see the coopr.neos package in Coin Bazaar).

II. We have recently released Coopr 2.3. This release includes

A preliminary Gurobi solver interface
Extended syntax for data command files:
o 'include' command to load other data command files
o 'import' command to load data from other sources
o namespaces to next data declarations
The coopr_install script can install packages from Coin Bazaar
New conversion scripts to generate LP or NL files from Pyomo models
Solvers now extract standard suffix information
Various fixes to PySP solvers
Full support for PyPI. You can install from PyPI using the 'Coopr' package name.

Enjoy!

MINLP Test Problems

2009-10-21T05:06:00.001-07:00

Ignacio Grossmann and Jon Lee recently announced the CMU-IBM Cyberinfrastructure Collaborative site for MINLP. The goal of this web site is to create a library of optimization problems in different application areas in which one or several alternative models are presented with their derivation. In addition, each model has one or several instances that can serve to test various algorithms. This effort is different from other test problem collections by requiring a description of the problem, and encouraging the contribution of alternate modeling formulations. Thus, the actual models in this collection may be MILP or NLP formulations that simplify a nonlinear problem, including simplifications of other MINLP formulations.

As it happens, Cindy Phillips, Regan Murray and I are working on a paper that describes our work on sensor placement for water security, where we describe various MILP formulations for this nonlinear application. I guess we should try to add our models to this repository!

Using easy_install to download source files

2009-10-20T15:16:00.001-07:00

Python's setuptools package includes the easy_install script, which provides a convenient mechanism for installing a Python package from the PyPi repository. Normally, easy_install installs a Python package in the Python site packages directory. However, I recently discovered that easy_install can download the source for Python package. For example, the following command downloads the Coopr optimization package into the coopr directory:

easy_install -q --editable --build-directory . Coopr

I had to browse a variety of web pages before I figured this syntax out. Enjoy!

Book Recommendation: Software IP

2009-10-14T19:04:00.001-07:00

I have been working with software-related intellectual property issues for several years now. I finally broke down and bought a book to help me get the big picture. The following book has been remarkably helpful:

Intellectual Property and Open Source: A practical guide to protecting code
Van Lindberg
O'Reilly, 2008

I have been quite surprised how well Lindberg describes the complex legal issues related to intellectual property law. Lindberg is a lawyer and software developer, and he uses computer science analogies that are quite straightforward.

Applying the CBC Presolver

2009-10-05T20:44:00.001-07:00

Here's a fun fact that I wanted to archive... In a recent COIN-OR email exchange on coin-discuss, John Forrest suggested the following command-line for applying the CBC preprocessor to an MPS file:

cbc xxxxx.mps -preprocess save -heuristic off -maxnode -1 -solve

This command will save the cbc-presolved model in the file presolved.mps. The -heuristic off and -maxnode -1 options make cbc stop as quickly as possible.

Using Open-Source Tools to Manage Software Quality

2009-07-17T11:15:00.000-07:00

At PyCon 2009, Aaron Maxwell gave a presentation about the use of BuildBot to support an automated software QA infrastructure. Listening to his talk (online) made me think more carefully about the reasons I am not using BuildBot, which I took a look at several years ago. After working with a custom automated build tool for a few years, I have recently begun using Hudson to automate software quality processes for a variety of open source software packages. Hudson automates the following QA activities for these packages:

portability tests - building packages with different compilers, language versions and compute platforms
continuous integration - rapid builds and software tests to provide developers continuous feedback
integration tests - builds that test the integration of different software tools
archiving QA statistics - test histories, code coverage statistics, build times, etc.
managing third-party builds - building third-party libraries that my codes depend on

Although I am reasonably happy with Hudson, I must admit that I did not immediately decide that it was perfect for my needs the first time I looked at it. However, as the scope of my QA needs has grown, it has become critical to have a flexible, extensible strategy for automating software QA activities. The following high-level issues have proven to be major considerations when assessing the viability of tools like BuildBot and Hudson:

GUI/web interface
GUI and web interfaces are key to ensuring that developers regularly use the QA data that is being generated. Interactive interrogation of QA current data facilitates effective use of this data, and GUI interfaces are very important when developers do not all have access to the same computing platforms. These interfaces can also convey valuable QA in a concise manner, such as graphical representations of QA history (e.g test failure/successes of time).

Extensibility
Any automation framework is going to need to be customized to adapt to local operating constraints. Thus, the extensibility of the automation framework is a key issue for end-users. A particularly effective strategy for supporting this flexibility is with plugin components, which are supported in Hudson.

Loosely Coupled QA Tools
Hudson uses a standards-based approach for integrating QA information. QA activities can be initiated in a very generic manner, using shell commands whose scope is not restricted. If the QA information is provided in a standard format, then Hudson can integrate it into its QA summaries. For example, Hudson recognizes testing results that are documented with the xUnit XML format, and code coverage results that are documented with the Cobertura XML format. This strategy supports a loose coupling between the QA processes and the use of Hudson, which allows for the application of a heterogeneous set of QA tools, including tools for different test harnesses and programming languages!

Compute Resource Management
Coordinating of a large number of QA activities requires scalable strategies for managing computing resources. Frameworks like Hudson provide basic resource management strategies, including dynamic scheduling of continuous integration builds on a build farm. More generally, scalable automated testing tools need to support strategies like fractional factorial test designs, which test many build options (configuration, platform, compiler, etc) with a small number of builds. Also, management of daemon clients also becomes an issue for large build farms (e.g. notification of exceptional events like running out of disk space).

Ease of Use
It is worth restating that ease-of-use is a major factor in practice. Developers will not use QA frameworks unless they add value to the development process. Further, it can be difficult to convince an organization to support the maintenance of automated QA frameworks on a large build farm.

As a final note, the Acro Developer Resources page summarizes the QA tools that the Acro project is using with Hudson to support software development. It is noteworthy that this effort includes QA processes for both C/C++ software and Python software. On another project, we have also used Hudson to summarize tests of Matlab code.

P.S. I want to thank John Siirola for brainstorming about this blog. John has done most of the work setting up the Hudson server that we are using for Acro and related open source software development.

Summarizing gcov Coverage Statistics with gcovr

2009-07-17T09:48:00.000-07:00

The gcovr command provides a utility for running the gcov command and summarizing code coverage results. This command is inspired by the Python coverage.py package, which provides a similar utility in Python. Further, gcovr can be viewed as a command-line alternative of the lcov utility, which runs gcov and generates an HTML output.

The gcovr command currently generates two different types of output:

Text Summary
For each file that generates gcov statistics, gcovr will summarize the number of lines covered, the percentage of coverage and enumerate the lines that are not covered.
Cobertura XML
An XML summary of the coverage statistics can be generated in a format that is consistent with Cobertura.

I find the text summary quite convenient for interactive assessment of coverage, especially as I design tests to improve coverage. The Cobertura summary can be used by continues build tools like Hudson. For example, see the acro-utilib coverage report that was generated with gcovr, using the Cobertura XML output option.

See the gcovr Trac page for further details about this tool. The gcovr command is currently bundled with the FAST Python package, which you can download from the FAST Trac site. However, gcovr is a stand-alone Python script. Thus, it is also convenient to download the latest development version here.

Videos for PyCon2009!

2009-07-17T06:16:00.000-07:00

I just discovered that the talks at PyCon 2009 were video taped! Excellent! I had fun browsing them last night, looking for clues to the challenges that I face managing several complex Python packages.

I am not sure how the PyCon organizers justified the cost for doing this, but I think that this was an excellent idea. I would love to see other conferences adopt this idea (or at least support online publishing of electronic slides). I suspect that this would discourage some people from attending a conference. However, people like me are already traveling too much. Thus, the PyCon organizers did not lose anything with me; I was already unable to attend. Further, having access to the presentations makes me more likely to adopt the techniques/approaches that they are presenting! This sounds like a win-win to me!!

PyUtilib Plugins

2009-07-02T12:33:00.001-07:00

After blogging about Python plugin frameworks earlier this year, I wound up implemented a new framework in the PyUtilib software package. The PyUtilib wiki provides a detailed description of the PyUtilib Plugin Framework, but here's a brief summary:

This framework is derived from the Trac plugin framework (a.k.a. component architecture)
Provides support for both singleton and non-singleton plugin instances
Includes utilities for managing plugins within namespaces
The core framework is defined in a single Python module, which can be used independently from PyUtilib
PyUtilib also includes commonly use plugins, such as
- A config-file reader/writer based on ConfigParser
- Loading utilities for eggs and modules
- A file manager for temporary files

Although I initially resisted the urge to develop my own framework, I was led to develop this because (1) I wanted a light-weight framework like that provided by Trac, but (2) Trac's framework is not particularlly modular within the Trac software repository. Also, I really needed a plugin framework that supported non-singleton plugins. Development of the PyUtilib Plugin Framework is mostly motivated by my work with Coopr, which extensively leverages plugins to support a flexible, extensible optimization tools.

Another Discussion of Python Plugins

2009-01-26T18:18:00.000-08:00

Here's a nice discussion and comparison of Python plugin frameworks that I ran across today: Design Docs Plugins - PiTiViWiKi. This notes that a big difference between Zope and Trac plugins is that Zope defines interfaces which allows for checking interface implementation/definition, as well as facilities for plugin adapters. In this respect, the Envisage Core plugins are similar to Zope.

Python Plugin Frameworks

2009-01-26T09:37:00.001-08:00

Updated to include pointers to the PyUtilib Component Architecture and PnP.

Various Python projects I am working on could benefit from the use of a Plug-in framework. However, there does not appear to be a standard Python plug-in framework, though there are some mature packages that support plug-ins.

Here's a summary of my recent web research:

yapsy - This is a simple plug-in framework that was designed specifically to support plug-ins with no external dependencies.
Mary Alchin describes a simple plugin framework, with a similar goal. His classes provide an API for the plugins, with few supporting features (e.g. searching for plugins).
André Roberge has a series of posts that describe the application of plugins to refactor a simple calculator application. The goal of this is to illustrate the requirements for plugin frameworks, with the goal of identifying best practices for plugins. There are some interesting replies to this post, which consider implementations of the plugins he proposes in zope and grok. Both of these pull in quite a few libraries, which begs the question of whether it makes sense for external users to rely on these components for only plugin support.
Enthought's Envisage project includes a framework for building extensible, pluggable applications. The enthough.envisage package defines these capabilities, and there is nice documentation here.
Trac and Zope are frameworks that incorporate plug-ins, and these capabilities may be modular enough for use in other applications. Trac's component architecture is detailed in the Trac wiki pages. Zope's plug-ins appear to be called products (see also here). Martin Aspeli describes his experience writing Trac plug-ins and contrasts them with Zope.
The PyUtilib Component Architecture (PCA) is a component architecture in Python that is derived from the Trac component framework. One important extension was to support both singleton and non-singleton plugins. Singleton plugins are created immediately when the plugin module is loaded, which is well-suited for persistent applications like Trac. However, many other applications need to employ plugins "on demand", which need to be explicitly constructed by the end-user. (See the PyUtilib wiki for further details.)
Plug n' PLay (PnP) is a Generic plug-in system inspired by Trac's internal component management. PnP is roughly a implementation of the Observer pattern (http://en.wikipedia.org/wiki/Observer_pattern).
```
 
```

These resources highlight one reason why there is not a standard Python plug-in framework: there are a variety of different capabilities that a user may want, and the complexity of the framework generally increases as these new capabilities are added (e.g. security, API validation, etc). Another item that seems clear is that while a variety of packages support plug-ins, many of them do not use them in a modular fashion. Thus, it is difficult to reuse sophisticated plug-in frameworks without incorporating a lot of extraneous code.

A Python Trick: Adding a Lambda Method to a Class

2009-01-20T09:38:00.001-08:00

It does not take much to add a lambda function to a Python class. For example, consider the following:


  >>> class A: pass
  >>> f = lambda self,x:x
  >>> setattr(A,"f",f)

This code adds the method f to class A. For example:


  >>> a=A()
  >>> a.f(1)
  1

However, the f method created this way does not have the expected Python name:


  >>> A.f.__name__
  ''

Further, defining this value is not possible; the instancemethod f does not have a __name__ attribute.

The trick is to name the lambda function before defining the class method:


  >>> class A: pass
  >>> f = lambda self,x:x
  >>> f.__name__ = "f"
  >>> setattr(A,"f",f)
  >>> f.__name__
'f'

This is simple, but it took too long to figure this out...

Interrupting the UNIX time command

2009-01-20T09:05:00.001-08:00

Consider the following use of the standard Unix time command:

/usr/bin/time ls -R /

If the SIGTERM signal is sent to the time process, then the ls process will continue! This is an unexpected behavior, which is not well-documented.

Normally, this is not much of an issue; the process that is monitored will simply terminate quietly. However, when the time utility is used in interactive applications, process interrupts can lead to many unexpected rogue processes.

The timer command is a modification of the UNIX timing utility that behaves as expected. When using timer, the SIGTERM signal is sent to the process, which terminates it as expected. The timer command is available in the UTILIB software library, but it can be compiled independently.

Monitoring Maximum Memory Usage in Linux

2009-01-19T22:39:00.001-08:00

There are many tools available that can be used to monitor memory usage in computer programs. However, there are few tools that can be applied to monitor the memory usage of a specific process in an automated manner. Most memory monitoring tools provide a gui that a user can monitor.

However, these tools are not useful in contexts where memory must be monitored repeatedly. For example, automated software tests may require checks to validate that the memory usage does not exceed expected limits.

The memmon command is a new memory monitoring tool that is included in the UTILIB software library. memmon provides a convenient mechanism to report the maximum amount of memory that a process uses.

The memmon command requires the absolute path to the command that will be executed. Beyond that, its default syntax is quite simple:

$ ./memmon /bin/sleep 1
53768 Kb used

The memmon command can also be used to terminate a process whose memory exceeds a specified threshold:


$ ./memmon -k 10 /bin/sleep 1
./memmon: Error: memory exceeded
53764 Kb used

At present, memmon only supports memory monitoring on Linux platforms. However, it is not clear how its capability could be ported to other operating systems. I am particularly interested in this capability on MS Windows, if anyone has ideas for how to do that...

Software Releases

2009-01-19T22:01:00.001-08:00

I have not blogged much this fall because I have been busy managing a variety of software releases. I plan to include further details in upcoming blogs, but I thought I would summarize these releases here:

acro 2.0 - Acro is A Common Repository for Optimizers that integrates a rich variety of optimization libraries and solvers that have been developed for large-scale engineering and scientific applications. Acro was developed to facilitate the design, development, integration and support of optimization software libraries. Thus, Acro includes both individual optimization solvers as well as optimization frameworks that provide abstract interfaces for flexible interoperability of solver components. Furthermore, many solvers included in Acro can exploit parallel computing resources to solve optimization problems more quickly.

utilib 4.0 - Utilib is a library of general-purpose C++ utilities, similar in spirit to the Boost libraries. While generally treated as an Acro package, Utilib is hosted in a separate subversion repository to facilitate use by projects outside of Acro.

PyUtilib 1.0 - PyUtilib is yet another a Python utility library. PyUtilib supports several Python projects under development at Sandia National Laboratories, including Acro, Coopr and FAST.

FAST 2.0 - FAST provides a collection of Python tools that support software testing. In it's current form, this does not really constitute a framework, but the plan is to develop a set of tools that support comprehensive testing of software tools.

Coopr 1.0 - The Coopr Python package integrates a variety of Python optimization-related packages. Most of these packages rely on externally built optimization solvers. In particular, the Acro software builds many optimizers used by Coopr packages.

The Trac wikis for these packages contain a variety of tools that I'll describe in more detail later...

Generating tests in Python unittest

2008-10-28T07:06:00.001-07:00

There are many applications where you want to apply a code to a variety of data sets, and verify that you get the correct output. In this context, what you want is a test generator, which can dynamically create tests, based on the set of data sets that are available for testing.

Unfortunately, this does not appear to be a feature of unittest. The closest I have seen to this, is the support for test generators in the nose package, which extends unittest to provide test discovery mechanisms. However, that test generation feature is somewhat limited; it only applies to test functions that are Python generators, and not to similar class methods.

The following example shows how to directly insert new test methods into a unittest.TestCase class:


#
# A simple example for generating tests in the Python unittest framework
#

import glob
import unittest

#
# Defining the class that will contain the new tests
#
class TestCases(unittest.TestCase): pass

#
# A generic function that performs a test on a particular file
#
def perform_test(self,file):
  if len(file) > 20:
      self.fail("Failing in file \""+file+"\" because its name is too long.")

#
# Insert test methods into the TestCases class
#
for file in glob.glob("*")+glob.glob("*/*"):
  tmp = file.replace("/","_")
  tmp = tmp.replace("\\","_")
  tmp = tmp.replace(".","_")
  setattr(TestCases, "test_"+tmp, lambda self,x=file: perform_test(self,x))

#
# Apply these unittests
#
if __name__ == "__main__":
  unittest.main()

In this example, the files in the current directory and in all subdirectories are used to create new test methods. For each file, a new test method is added to the TestCases class, which does a silly check to see if the file is too long.

Constraint Programming

2008-10-03T07:43:00.001-07:00

Nick Berger pointed me to the Global Constraint Catalog, a collection of constraints that are can be used for constraint programming formulations. This looks like a nice reference!

New Journal: Mathematical Programming Computation

2008-10-01T06:54:00.001-07:00

I have recently joined the editorial board of the new journal Mathematical Programming Computation, which publishes original research articles that are at the intersection of math programming and computing. This journal reflects the growing role of computation in operations research, where real-world applications often require the application of complex software packages to analyze mathematical models.

This journal will include articles that report on innovative software, comparative tests, modeling environments, libraries of data, and/or applications. A main feature of the journal is the inclusion of accompanying software and data with submitted manuscripts. The journal's review process includes the evaluation and testing of the accompanying software. Where possible, the review will aim for verification of reported computational results.

Topics covered in Mathematical Programming Computation include linear programming, convex optimization, nonlinear optimization, stochastic optimization, robust optimization, integer programming, combinatorial optimization, global optimization, network algorithms, and modeling languages.

Online Video Tutorials

2008-09-24T07:24:00.001-07:00

By necessity, I have become quite adept at digging through webspace with search engines like google to figure out "how to do X". But occasionally, it is difficult to get a sense of whether something is easy from written instructions. For example, I recently tried to install PyQT, a Python interface to the popular QT application interface library, and here's the error that I got when trying to use nmake to build the SIP library (which PyQT uses):

C:\Python25\sip-4.7.6\sip-4.7.6\siplib>nmake

Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

cl -c -nologo -Zm200 -O2 -MD -W0 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -I. -IC:\Python25\include -Fo @C:\DOCUME~1\wehart\LOCALS~1\Temp\nm271.tmp
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\bin\cl.EXE"' : return code '0xc0000135'
Stop.

I had more than a little difficulty figuring out what the return code 0xc0000135 meant, especially since this is turned out to be an nmake return error and not an error generated by cl. Go figure.

In many cases, it is much easier to look over someone's shoulder and have them show you the ropes. That is why I have been so impressed with the ShowMeDo tutorial site. This site provides video tutorials where someone walks you through common installation, setup and configuration examples.

I think that this site is particularly useful for an "average" computer user, who is not familiar with manual software installation and configuration. I work with a variety of such users in my work, and I have found that these tutorials provide a convenient reference that it quite accessible. If they cannot look over my shoulder, then at least they can view a video that provides a similar experience!

The site also includes video tutorials for how to create video tutorials! I have not tried this myself, but I hope this type of tutorial catches on.

Why Python?

2008-09-22T07:09:00.000-07:00

In the past year, I have increasingly been using Python to develop a variety of OR-related scientific software. In particular, the Coopr library has been a major focus of this software development.

Recently, I have written a paper that will appear in the proceedings of the INFORMS Computing Society Conference 2009:

W. Hart, Python Optimization Modeling Objects (Pyomo), Proc. INFORMS Computing Society Conference, 2009, (to appear).

In this paper, I describe Pyomo, an open-source tool for modeling optimization applications in Python. A key goal of Pyomo is to provide an open-source math programming modeling capability. Although open-source optimization solvers are widely available in packages like COIN-OR, surprisingly few open-source tools have been developed to model optimization applications.

Pyomo has been developed in Python because it is a well-used modern programming language that provides a robust foundation for developing and applying scientific software. In this paper, I noted that Python meets some basic criteria that relate to how Pyomo will be used and managed:

Open Source License: Python is freely available, and its liberal open source license lets you modify and distribute a Python-based application with few restrictions.

Features: Python has a rich set of datatypes, support for object oriented programming, namespaces, exceptions, and dynamic loading.

Support and Stability: Python is highly stable, and it is well supported through newsgroups and special interest groups.

Documentation: Users can learn about Python from extensive online documentation, and a number of excellent books that are commonly available.

Standard Library: Python includes a large number of useful modules.

Extendability and Customization: Python has a simple model for loading Python code developed by a user. Additionally, compiled code packages that optimize computational kernels can be easily used. Python includes support for shared libraries and dynamic loading, so new capabilities can be dynamically integrated into Python applications.

Portability: Python is available on a wide range of compute platforms, so portability is typically not a limitation for Python-based applications.

Another factor, not to be overlooked, is the increasing acceptance of Python in the scientific community. Large Python projects like SciPy and SAGE strongly leverage a diverse set of Python packages.

Several other popular programming languages were also considered for Pyomo. However, in most cases Python appears to have distinct advantages:

.Net: As mentioned earlier, the .Net languages are not portable to Linux platforms, and thus they were not suitable for Pyomo.

Ruby: At the moment, Python and Ruby appear to be the two most widely recommended scripting languages that are portable to Linux platforms, and comparisons suggest that their core functionality is similar. Our preference for Python is largely based on the fact that it has a nice syntax that does not require users to type weird symbols(e.g. \$, \%, @). Thus, we expect this will be a more natural language for expressing math programming models.

Java: Java has a lot of the same strengths as Python, and it is arguably as good a choice for Pyomo. However, two aspects of Python recommended it for Pyomo instead of Java. First, Python has a powerful interactive interpreter that allows realtime code development and encourages experimentation with Python software. Thus, users can work interactively with Pyomo models to become familiar with these objects and to diagnose bugs. Second, it is widely acknowledged that Python's dynamic typing and compact, concise syntax makes software development quick and easy. Although some very interesting optimization modeling tools have been developed in languages like C++ and Java, there is anecdotal evidence that users will not be as productive in these languages as they will when using tools developed in languages like Python (see Python vs Java).

C++: Models formulated with the FlopC++ package are similar to models developed with Pyomo. They are be specified in a declarative style using classes to represent model components (e.g. sets, variables and constraints). However, C++ requires explicit compilation to execute code, and it does not support an interactive interpreter. Thus, we believe that Python will provide a more flexible language for users.

INFORMS ICS Meeting

2008-09-21T21:16:00.001-07:00

If you are interested in the intersection of operations research and computing, then the INFORMS ICS Meeting will be of interest to you! I am organizing a session on open-source software for operations research. Contact me if you are interested in giving a presentation!

Why open-source software?

2008-09-08T15:39:00.001-07:00

Much of my work involves the development of open-source software. Recently, I have been challenged to justify this in several different projects.

I recently stumbled across Dave Wheeler's paper, which provides a nice quantitative analysis of the advantages of open-source software.

Testing ScribeFire

2008-09-06T14:58:00.001-07:00

I'm going to try using ScribeFire to generate these posts. This seems highly recommended. Also, I can work with it offline, which is a definite plus for me!

Starting to blog...?

2008-08-27T19:13:00.000-07:00

OK, this is really my second blogging experience. I'm currently the 'blogger in residence' for the INFORMS Computing Society. Though I'm still trying to figure out what that means, I blogged the last INFORMS Annual Meeting .

So, why this blog? I do a lot of software development at Sandia National Laboratories, mostly focused on scientific computing and optimization. The more I work with open-source projects, the more I realize that I should archive some of my 'lessons learned'. Although I like to publish papers, a blog is a better way to informally share information!