I booked some international flights on Orbitz tonight, and I was shocked to find an email about $137.37 in travel insurance I knew nothing about. Apparently, they have an opt-out insurance offer from a company called AccessAmerica on all their international tickets. I didn't see it among all the rental car and hotel offers I ignore trying to buy my tickets.
I had to call and wait on hold with Orbitz in order to get my money back. I wonder how many people they trick, adding big fees for fairly worthless, narrow insurance.
I guess now I have a reason to choose among Expedia, Travelocity, and Orbitz. I had always used all three, but now I guess I'm down to two.
If you follow the field of Operations Research at all, you've probably heard of the new company Gurobi. Started by three big CPLEX guys who left to go out on their own, it is trying to be the new state-of-the-art solver for linear programming (LP) and mixed integer programming (MILP). Their stand alone solver should be released any day now. (You can already get it embedded in other modeling systems.)
I'm looking forward to it for a couple of reasons. The first is that they promise an object oriented Python interface. I like Python as a language, and there isn't a really slick interface to a good solver.
However, I have another, bigger hope. I hope I can get Gurobi by the hour. Their website says:
That could mean lots of things. What I really want is to be able to use their solver on an Amazon EC2 instance, and pay by the hour.
Amazon EC2 lets you fire up a computer on demand, paying only for the resources you use. Their "High-CPU Extra Large Instance" has ideal specs for solving math models. It has 7GB of memory and 8 cores of CPU, all for only $0.80/hour. You can get Windows or Ubuntu Linux (among others), which are the initial two operating systems Gurobi is supporting. The 8 core machine should be a great test bed for the shared memory parallelism that is built into Gurobi.
If Gurobi is smart, they'll create a custom Amazon Machine Image (AMI) with their software already installed. Amazon already has a system called DevPay that (I think) lets you bill for your software by the hour. What if you just paid $3/hour for this instance, with $2.20 going to Gurobi, and the $0.80 paying Amazon for the hardware.
That would be a complete game changer in the delivery of optimization. Instead of having to buy a big multicore box, and get a $5,995 license, you just fire up an EC2 instance, and pay them by the hour. It hugely lowers the bar to experimenting.
It also allows your run parallel instances without breaking the bank. We used to use CPLEX on a single PC. However, we switched in the end to running COIN-OR open source software on a cluster, because there were times we needed to run lots of independent jobs in parallel. I imagine that would be true of most customers. CPLEX charges insane money for parallel licenses. With an hourly license scheme, you could just fire off 50 EC2 instances, and get all that work done at once.
It would be the perfect way to sell a program like Gurobi. Instead of having to deal with demo licenses that restrict problem size, just rent out the full version. If you price is right, then heavy users will still want a perpetual license. If you amortize the $6000 over 2 years, and 250 work days a year, you get $12/day in revenues. At $2.20/hour, you would break even in 5.5 hours per day. Heavy users will still buy perpetual licenses, but you'll get a bunch of "casual" optimization customers that would otherwise turn to COIN, who will pay $20 bucks to solve a particular problem.
There's a good visual comparison of programming fonts over on Coding Horror.
I have to cast my vote for Pragmata, in 11 pt as he shows. Yes, it is expensive for a font, but then I look at a screen full of it for 40+ hours a week. It paid for itself long ago.
i'm writing this post on my iPhone, using the new i.typepad.com application.
I am on the commuter rail.
I'll just see if this works before I hunt and peck too much.
It is the first iphone webapp I've tried, and it seems really slick.
Keeping with the topic of geekiness from my last post, here an excellent article for the statistics geeks out there.
The Guardian has a story about how statisticians used the serial numbers of captured tank in WWII to accurately estimate the number of tanks being produced by the Germans.