JBake

NYC Metrocard Fare Calculator

Mon, 18 Nov 2013 00:00:00 -0500

tl;dr

I made a fare calculator that will tell you how much money you should put on your card given your current balance.

Working in the city means having to travel within the city. Because the buildings are packed densely, you can choose from a wide array of transportation methods. Depending on a combination of parameters (distance, weather, $$$) you can choose how you will get from point A to point B. I’ve walked, biked, and taken the subway.

The subway tends to be a reliable and relatively cheap option that stretches across all five boroughs of the city. It’s not a 100% perfect solution but it gets the job done. There are however a list of grievances with using the subway. Fare hikes, crazy people, rude people, dirty stations, unplanned downtime are just a few items of note but for a low flat rate it’s not that bad.

With the latest fare hike of March 2013, there are a series of changes that prevent you from achieving a $0.00 balance without effort. You used to be able to walk up to an MTA MetroCard vending machine, feed it $20 and be able to use all of it. Now when you purchase a new card, it deducts $1 from your $20, applies a 5% bonus to the remaining $19 giving you a total balance of $19.95. A single subway ride is $2.50, meaning that a balance of $19.95 yields 7 rides. When those 7 rides are used, the remaining balance is $2.45. How annoying is that! That card is useless until you add more money. So you add another $20 and now your balance is $23.45 (good for 9 rides) which leaves you with a balance of $0.95 after those 9 rides are used. When are we ever going to have a $0 balance?

Unless you enjoy donating $2.45 to the MTA, you’re going to be holding onto that card. That card will always have some strange, left-over, unusable balance that will keep haunting you every time you use the subway. If you hope to zero out your MetroCard simply by adding $20 every time you go to the vending machine, it will never happen.

The Cycle

Initial $20 has unusable balance of $2.45
Another $20 yields $23.45 with unusable balance of $0.95
Another $20 yields $21.95 with unusable balance of $1.95
Another $20 yields $22.95 with unusable balance of $0.45
Another $20 yields $21.45 with unusable balance of $1.45
Another $20 yields $22.45 with unusable balance of $2.45

Oh look at that, you’re back to a useless $2.45! The MTA is profiting from the breakage of discarded cards with remaining balances and new card fees.

This isn’t a problem without a solution. If you take a look at the fare details, you get the high level view of how an MTA MetroCard vending machine works. You can only pay in increments of $0.05, any amount paid over $5 has a 5% bonus, and you must subtract $1 from the pre-bonus amount paid if the card you are crediting is a new card.

So in regards to the initial $2.45 remaining balance you could quickly zero your card out by adding $0.05. However, you wouldn’t be "benefiting" from the 5% bonus for payments over $5.

With these simple rules, I made a fare calculator using a small bit of javascript, that will tell you how much money you should put on your card given your current balance.

Here’s the source:

fare-calc.html

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>MTA Fare Calculator</title>
  <link rel="stylesheet" href="http://netdna.bootstrapcdn.com/bootstrap/3.0.2/css/bootstrap.min.css">
</head>
<body>
<div class="container">
  <div class="header">
    <h3>MTA Fare Calculator</h3>
  </div>
  <form class="form-horizontal" role="form">
    <div class="form-group">
      <div class="col-sm-offset-2 col-sm-10">
        <div class="radio">
          <label><input type="radio" name="cardType" value="new" checked> New Card ($1.00 fee)</label>
        </div>
      </div>
    </div>

    <div class="form-group">
      <div class="col-sm-offset-2 col-sm-10">
        <div class="radio">
          <label><input type="radio" name="cardType" value="existing"> Existing Card</label>
        </div>
      </div>
    </div>

    <div class="form-group">
      <label for="existingBalance" class="col-sm-2 control-label">Existing balance</label>
      <div class="col-sm-10">
        <input id="existingBalance" name="existingBalance" class="form-control" type="number" placeholder="Existing balance" disabled value="0" min=0 max=1000 step=0.01>
      </div>
    </div>

    <div class="form-group">
      <div class="col-sm-offset-2 col-sm-10">
        <button class="btn btn-primary" type="submit">Calculate</button>
      </div>
    </div>

  </form>

  <div class="row">
    <div class="col-sm-offset-2 col-sm-10">
      <table class="table table-condensed table-hover">
        <thead><tr><th>You should pay</th><th>With Bonus</th><th>For Balance</th><th>Number of rides</th></tr></thead>
        <tbody></tbody>
      </table>
    </div>
  </div>
</div>

<script src="https://code.jquery.com/jquery.min.js"></script>
<script>
  (function() {

    var baseFare = 2.50;
    var newCardFee = 1.00;
    var minAmountForBonus=5;
    var bonus=0.05;
    var machineIncrements = 0.05;

    var cash = function(credit, existing) {
      existing = isNaN(existing) ? 0 : parseFloat(existing);
      var amountBonus = 0;
      if (credit >= minAmountForBonus) {
        amountBonus = parseFloat((credit * bonus).toFixed(2));
      }
      var newBalance = credit + amountBonus + existing;
      return  {
        whatToPay: credit,
        bonus: amountBonus,
        balance: newBalance
      };
    };

    $('body').on('submit', 'form', function(e) {
      e.preventDefault();

      var form = $(this).serialize().split("&");

      var existingBalance = $('#existingBalance:not([disabled])').val() || 0;

      var isNewCard = $('input[name="cardType"]:checked').val() === 'new';

      var tbody = $('tbody').empty();

      var amount = machineIncrements;
      var i = 0;
      while (amount < 120) {
        var credit = parseFloat((i++ * machineIncrements).toFixed(2));
        var card = cash(credit, existingBalance);
        var amount = card.whatToPay;
        if (isNewCard) {
          amount += 1;
        }

        if (amount > 0) {
          var trips = parseFloat(card.balance.toFixed(2)) / baseFare;
          if (trips > 0 && trips % 1 === 0) {
            var contents = ['$' + amount.toFixed(2), '$' + card.bonus.toFixed(2), '$' + card.balance.toFixed(2), trips].join('</td><td>');
            tbody.append(['<tr><td>', contents, '</td></tr>'].join(''));
          }
        }
      }
    });

    $('body').on('change', 'input[name="cardType"]', function() {
      var existing = this.value ==='existing';

      if (existing && $(this).is(':checked')) {
        $('#existingBalance').removeAttr('disabled').focus();
      } else {
        $('#existingBalance').attr('disabled', true);
      }

    });

  })();
</script>
</body>
</html>

If you plan on traveling frequently within a given week or month, there are additional ways to optimize your MTA expenditure. The 7 day unlimited is $30 and the 30 day unlimited is $112. If you find yourself paying more than these amounts on your card you should consider getting an unlimited card if your card is going to be used very frequently.

Notes

As I was testing my fare calculator, I assumed that the MTA would simply truncate values after the hundredth’s place. It turns out they are rounding to the nearest hundredth place, so at least the bonus calculation is fair.

MySQL and Merge Tables

Sat, 9 Nov 2013 00:00:00 -0500

tl;dr

If you use MySQL as prescribed, everything should be OK. Failing that, you can learn some interesting things about how MySQL works.

Background

MySQL’s MERGE storage engine is a neat way to address a specific type of problem. With the MyISAM storage engine, you lose INSERT performance as the table grows. Seeing that MyISAM uses table level locks for reads and writes, you’ll quickly find that all your processes lock trying to query that table. Your application hangs while waiting for those queries to return and your site is now completely unusable.

Fortunately, the MERGE storage engine is here to save the day. The actual MERGE table acts as a facade that unites a set of different tables that must share identical schemata. The MERGE schema itself differs only in that it must provide the MERGE storage engine type and declare insertion strategy. When your table is sufficiently large and you notice that your INSERT s start to stack up, all you have to do is create another table and append it to the list of merge tables defined in the MERGE table.

One thing I didn’t mention is that MERGE tables come with a long list of problems and caveats.

The most important thing to note is that MERGE tables cannot enforce uniqueness constraints across the set of tables that form the MERGE table. Uniqueness is enforced on a per table basis, but there is nothing stopping you from INSERT -ing an entry with a key that violates a uniqueness constraint in a neighboring table.

If you happen to miss this caveat, you will see some strange behavior.

Setup

We’ll create our database, two tables and a MERGE table that ties them together.

DROP DATABASE IF EXISTS a; CREATE DATABASE a; USE a;
CREATE TABLE `a_0` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `b` bigint(20) NOT NULL DEFAULT '0',
  `c` varchar(512) NOT NULL,
  PRIMARY KEY (`b`,`c`),
  KEY `c` (`c`(32)),
  KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
INSERT INTO a_0 (b, c) VALUES (1, 'hi'), (1, 'hi'), (1, 'hi');
CREATE TABLE `a_1` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `b` bigint(20) NOT NULL DEFAULT '0',
  `c` varchar(512) NOT NULL,
  PRIMARY KEY (`b`,`c`),
  KEY `c` (`c`(32)),
  KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=latin1;
INSERT INTO a_1 (b, c) VALUES (11, 'ho'), (12, 'ho'), (13, 'ho');
CREATE TABLE `a` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `b` bigint(20) NOT NULL DEFAULT '0',
  `c` varchar(512) NOT NULL,
  PRIMARY KEY (`b`,`c`),
  KEY `c` (`c`(32)),
  KEY `id` (`id`)
) ENGINE=MRG_MyISAM DEFAULT CHARSET=latin1 INSERT_METHOD=LAST UNION=(`a_0`, `a_1`);

Poking around

Let’s insert a row that violates the unique constraint defined by PRIMARY KEY (b,c)

INSERT INTO `a` (b, c) VALUES (1, 'hi');
Query OK, 1 row affected (0.00 sec)

Ok no surprises there. MySQL warned us that this would happen. Let’s try some additional queries.

SELECT * FROM a WHERE b=1;
+----+---+----+
| id | b | c  |
+----+---+----+
|  1 | 1 | hi |
| 14 | 1 | hi |
+----+---+----+
2 rows in set (0.00 sec)

Again no surprises. Let’s try a query with the explicit primary key defintion.

SELECT * FROM a WHERE b=1 and c='hi';
+----+---+----+
| id | b | c  |
+----+---+----+
|  1 | 1 | hi |
+----+---+----+
1 row in set (0.00 sec)

That’s interesting… what happened to my other row that also had b=1 and c='hi'?

SELECT * FROM a WHERE b=1 and c='hi' AND id > 1;
Empty set (0.00 sec)

We know that a row with the same key exists in a_1 but it’s not being returned. What gives?

mysql> EXPLAIN SELECT * FROM a WHERE b=1 and c='hi' AND id > 1;
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                                                |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------------+
|  1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Impossible WHERE noticed after reading const tables  |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------------+
1 row in set (0.00 sec)

Impossible WHERE noticed after reading const tables

OK well what is a const table? It’s a table of 0 or 1 rows that allows the query optimizer to treat the search parameters as constants.

const is used when you compare all parts of a PRIMARY KEY or UNIQUE index to constant values.

So it looks like as long as your query contains all parts of a primary/unique constraint, the query optimizes to select against a table with 0 or 1 rows.

Let’s test that using queries that use all parts of the PRIMARY KEY. What do you think the following queries will return?

SELECT * FROM a WHERE b=1 and c LIKE 'hi';
SELECT * FROM a WHERE b LIKE 1 and c = 'hi';
SELECT * FROM a WHERE b LIKE 1 and c LIKE 'hi';

They all return both rows!

+----+---+----+
| id | b | c  |
+----+---+----+
|  1 | 1 | hi |
| 14 | 1 | hi |
+----+---+----+
2 rows in set (0.12 sec)

This gives us some insight into differences between LIKE and =. It seems LIKE will not use the const table. To use the const table, it’s not enough to query using all parts of the PRIMARY KEY, but you must query using =.

Let’s go back to this query: SELECT * FROM a WHERE b=1 and c='hi' AND id > 1;

What if we altered the MERGE table to switch the ordering of the underlying tables?

ALTER TABLE `a` ENGINE=MRG_MyISAM DEFAULT CHARSET=latin1 INSERT_METHOD=LAST UNION=(`a_1`,`a_0`);

SELECT * FROM a WHERE b=1 and c='hi' AND id > 1;
+----+---+----+
| id | b | c  |
+----+---+----+
| 14 | 1 | hi |
+----+---+----+
1 row in set (0.00 sec)

We can conclude that SELECT`s against `MERGE tables using const table will stop searching subsequent tables in the MERGE list as long as it finds a row that satisfies the PRIMARY KEY.

To verify that conclusion let’s "undo" the ALTER to the MERGE table, DELETE the first row in a_0 then force MySQL to use the const table.

ALTER TABLE `a` ENGINE=MRG_MyISAM DEFAULT CHARSET=latin1 INSERT_METHOD=LAST UNION=(`a_0`,`a_1`);
DELETE FROM `a_0` WHERE b=1 and c='hi';
SELECT * FROM a WHERE b=1 and c='hi' AND id > 1;
+----+---+----+
| id | b | c  |
+----+---+----+
| 14 | 1 | hi |
+----+---+----+
1 row in set (0.00 sec)

As expected.

One more thing

I should note that I DELETE d from a_0 and not a. DELETE -ing from a will find all rows that match and DELETE them.

mysql> INSERT INTO `a_0` (id,b,c) VALUES (1, 1, 'hi');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM `a` WHERE b=1 and c='hi' AND id > 1;
Empty set (0.00 sec)

mysql> DELETE FROM `a` WHERE b=1 and c='hi';
Query OK, 2 rows affected (0.00 sec)

DELETE s do not use the const table!