TestingandCI_solutions.ipynb

{
 "cells": [
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "from __future__ import print_function, division, absolute_import"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Code Testing and CI\n",
    "\n",
    "**Version 0.1**\n",
    "\n",
    "The notebook contains problems about code testing and continuous integration.\n",
    "\n",
    "* * *\n",
    "\n",
    "E Tollerud (STScI)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Problem 1: Set up py.test in you repo"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "In this problem we'll aim to get the [py.test](https://docs.pytest.org/en/latest/) testing framework up and running in the code repository you set up in the last set of problems.  We can then use it to collect and run tests of the code."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1a: Ensure py.test is installed\n",
    "\n",
    "Of course ``py.test`` must actually be installed before you can use it. The commands below should work for the Anaconda Python Distribution, but if you have some other Python installation you'll want to install `pytest` (and its coverage plugin) as directed in the install instructions for ``py.test``."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!conda install pytest pytest-cov"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1b: Ensure your repo has code suitable for unit tests\n",
    "\n",
    "Depending on what your code actually does, you might need to modify it to actually perform something testable.  For example, if all it does is print something, you might find it difficult to write an effective unit test.  Try adding a function that actually performs some operation and returns something different depending on various inputs.  That tends to be the easiest function to unit-test: one with a clear \"right\" answer in certain situations."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Also be sure you have `cd`ed to the *root* of the repo for `pytest` to operate correctly."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1c: Add a test file with a test function\n",
    "\n",
    "The test must be part of the package and follow the convention that the file and the function begin with ``test`` to get picked up by the test collection machinery.  Inside the test function, you'll need some code that fails if the test condition fails.  The easiest way to do this is with an ``assert`` statement, which raises an error if its first argument is False.\n",
    "\n",
    "*Hint: remember that to be a valid python package, a directory must have an ``__init__.py``*"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!mkdir #complete\n",
    "!touch #complete"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "%%file <yourpackage>/tests/test_something.py\n",
    "\n",
    "def test_something_func():\n",
    "    assert #complete"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1d: Run the test directly\n",
    "\n",
    "While this is not how you'd ordinarily run the tests, it's instructive to first try to execute the test *directly*, without using any fancy test framework.  If your test function just runs, all is good.  If you get an exception, the test failed (which in this case might be *good*).\n",
    "\n",
    "*Hint: you may need to use `reload` or just re-start your notebook kernel to get the cell below to recognize the changes.*"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "from <yourpackage>.tests import test_something\n",
    "\n",
    "test_something.test_something_func()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1e: Run the tests with ``py.test``\n",
    "\n",
    "Once you have an example test, you can try invoking ``py.test``, which is how you should run the tests in the future.  This should yield a report that shows a dot for each test. If all you see are dots, the tests ran sucessfully.  But if there's a failure, you'll see the error, and the traceback showing where the error happened."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!py.test"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1f: Make the test fail (or succeed...)\n",
    "\n",
    "If your test failed when you ran it, you should now try to fix the test (or the code...) to make it work.  Try running"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "(Modify your test to fail if it succeeded before, or vice versa)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!py.test"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 1g: Check coverage\n",
    "\n",
    "The coverage plugin we installed will let you check which lines of your code are actually run by the testing suite."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!py.test --cov=<yourproject> tests/ #complete"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This should yield a report, which you can use to decide if you need to add more tests to acheive complete coverage.  Check out the command line arguments to see if you can get a more detailed line-by-line report."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Problem 2: Implement some unit tests"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The sub-problems below each contain different unit testing complications.  Place the code from the snippets in your repository (either using an editor or the ``%%file`` trick), and write tests to ensure the correctness of the functions.  Try to achieve 100% coverage for all of them (especially to catch some hidden bugs!).\n",
    "\n",
    "Also, note that some of these examples are not really practical - that is, you wouldn't want to do this in *real* code because there's better ways to do it.  But because of that, they are good examples of where something can go subtly wrong... and therefore where you want to make tests!"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 2a\n",
    "\n",
    "When you have a function with a default, it's wise to test both the with-default call (``function_b()``), and when you give a value (``function_b(1.2)``)\n",
    "\n",
    "*Hint: Beware of numbers that come close to 0... write your tests to accomodate floating-point errors!*"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "#%%file <yourproject>/<filename>.py #complete, or just use your editor\n",
    "\n",
    "# `math` here is for *scalar* math... normally you'd use numpy but this makes it a bit simpler to debug\n",
    "\n",
    "import math \n",
    "\n",
    "inf = float('inf')  # this is a quick-and-easy way to get the \"infinity\" value \n",
    "\n",
    "def function_a(angle=180):\n",
    "    anglerad = math.radians(angle)\n",
    "    return math.sin(anglerad/2)/math.sin(anglerad)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Solution (one of many...)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "def test_default_bad():\n",
    "    # this will fail, although it *seems* like it should succeed...  the sin function has rounding errors\n",
    "    assert function_a() == inf  \n",
    "\n",
    "def test_default_good():\n",
    "    assert function_a() > 1e10\n",
    "    \n",
    "def test_otherval_bad():\n",
    "    # again it seems like it should succed, but rounding errors make it fail\n",
    "    assert function_a(90) == math.sqrt(2)/2\n",
    "    \n",
    "def test_otherval_good():\n",
    "    assert abs(function_a(90) - math.sqrt(2)/2) < 1e-10"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 2b\n",
    "\n",
    "This test has an intentional bug... but depending how you right the test you *might* not catch it...  Use unit tests to find it! (and then fix it...)\n"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "#%%file <yourproject>/<filename>.py #complete, or just use your editor\n",
    "\n",
    "def function_b(value):\n",
    "    if value < 0:\n",
    "        return value - 1\n",
    "    else:\n",
    "        value2 = subfunction_b(value + 1)\n",
    "        return value + value2\n",
    "    \n",
    "def subfunction_b(inp):\n",
    "    vals_to_accum = []\n",
    "    for i in range(10):\n",
    "        vals_to_accum.append(inp ** (i/10))\n",
    "    if vals_to_accum[-1] > 2:\n",
    "        vals.append(100)\n",
    "    # really you would use numpy to do this kind of number-crunching... but we're doing this for the sake of example right now\n",
    "    return sum(vals_to_accum) "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Solution (one of many...)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "def test_neg():\n",
    "    assert function_b(-10) == -11\n",
    "    \n",
    "def test_zero():\n",
    "    assert function_b(0) == 10\n",
    "    \n",
    "def test_pos_lt1():\n",
    "    res = function_b(.5) \n",
    "    assert res > 10\n",
    "    assert res < 100\n",
    "    \n",
    "def test_pos_gt1():\n",
    "    res = function_b(1.5) \n",
    "    assert res > 100\n",
    "    \n",
    "# this test reveals that `subfunction_b()` has a ``vals`` where it should have a ``vals_to_accum``"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 2c\n",
    "\n",
    "There are (at least) *two* significant bugs in this code (one fairly apparent, one much more subtle).  Try to catch them both, and write a regression test that covers those cases once you've found them.\n",
    "\n",
    "One note about this function: in real code you're probably better off just using [the Angle object from `astropy.coordinates`](http://docs.astropy.org/en/stable/coordinates/angles.html).  But this example demonstrates one of the reasons *why* that was created, as it's very easy to write a buggy version of this code.\n",
    "\n",
    "*Hint: you might find it useful to use `astropy.coordinates.Angle` to create test cases...*"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "#%%file <yourproject>/<filename>.py #complete, or just use your editor\n",
    "\n",
    "import math\n",
    "\n",
    "# know that to not have to worry about this, you should just use `astropy.coordinates`.\n",
    "def angle_to_sexigesimal(angle_in_degrees, decimals=3):\n",
    "    \"\"\"\n",
    "    Convert the given angle to a sexigesimal string of hours of RA.\n",
    "    \n",
    "    Parameters\n",
    "    ----------\n",
    "    angle_in_degrees : float\n",
    "        A scalar angle, expressed in degrees\n",
    "    \n",
    "    Returns\n",
    "    -------\n",
    "    hms_str : str\n",
    "        The sexigesimal string giving the hours, minutes, and seconds of RA for the given `angle_in_degrees`\n",
    "        \n",
    "    \"\"\"\n",
    "    if math.floor(decimals) != decimals:\n",
    "        raise ValueError('decimals should be an integer!')\n",
    "    \n",
    "    hours_num = angle_in_degrees*24/180\n",
    "    hours = math.floor(hours_num)\n",
    "    \n",
    "    min_num = (hours_num - hours)*60\n",
    "    minutes = math.floor(min_num)\n",
    "    \n",
    "    seconds = (min_num - minutes)*60\n",
    "\n",
    "    format_string = '{}:{}:{:.' + str(decimals) + 'f}'\n",
    "    return format_string.format(hours, minutes, seconds)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Solution (one of many...)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "def test_decimals():\n",
    "    assert angle_to_sexigesimal(0) == '0:0:0.000'\n",
    "    assert angle_to_sexigesimal(0, decimals=5) == '0:0:0.00000'\n",
    "    \n",
    "\n",
    "def test_qtrs():\n",
    "    assert angle_to_sexigesimal(90, decimals=0) == '6:0:0'\n",
    "    assert angle_to_sexigesimal(180, decimals=0) == '12:0:0'\n",
    "    assert angle_to_sexigesimal(270, decimals=0) == '18:0:0'\n",
    "    assert angle_to_sexigesimal(360, decimals=0) == '24:0:0'\n",
    "    # this reveals the major bug that the 180 at the top should be 360\n",
    "    \n",
    "def test_350():\n",
    "    assert angle_to_sexigesimal(350, decimals=0) == '23:20:00'\n",
    "    # this fails, revealing that sometimes the values round \n",
    "\n",
    "def test_neg():\n",
    "    assert angle_to_sexigesimal(-7.5, decimals=0) == '-0:30:0'\n",
    "    assert angle_to_sexigesimal(-20, decimals=0) == angle_to_sexigesimal(340, decimals=0)\n",
    "    # these fail, revealing a \"debatable\" bug: that negative degrees give negative RAs that are \n",
    "    # nonsense.  You could always tell users not to give negative values... but users, particularly \n",
    "    # future you, probably won't listen.\n",
    "    \n",
    "def test_neg_decimals():\n",
    "    import pytest\n",
    "    \n",
    "    with pytest.raises(ValueError):\n",
    "        angle_to_sexigesimal(10, decimals=-2)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 2d\n",
    "\n",
    "*Hint: numpy has some useful functions in [numpy.testing](https://docs.scipy.org/doc/numpy/reference/routines.testing.html) for comparing arrays.*"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "#%%file <yourproject>/<filename>.py #complete, or just use your editor\n",
    "\n",
    "import numpy as np\n",
    "\n",
    "def function_d(array1=np.arange(10)*2, array2=np.arange(10), operation='-'):\n",
    "    \"\"\"\n",
    "    Makes a matrix where the [i,j]th element is array1[i] <operation> array2[j]\n",
    "    \"\"\"\n",
    "    if operation == '+':\n",
    "        return array1[:, np.newaxis] + array2\n",
    "    elif operation == '-':\n",
    "        return array1[:, np.newaxis] - array2\n",
    "    elif operation == '*':\n",
    "        return array1[:, np.newaxis] * array2\n",
    "    elif operation == '/':\n",
    "        return array1[:, np.newaxis] / array2\n",
    "    else:\n",
    "        raise ValueError('Unrecognized operation \"{}\"'.format(operation))"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Solution (one of many...)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": false
   },
   "outputs": [],
   "source": [
    "def test_minus():\n",
    "    array1 = np.arange(10)*2\n",
    "    array2 = np.arange(10)\n",
    "    \n",
    "    func_mat =  function_d(array1, array2, operation='-')\n",
    "    \n",
    "    for i, val1 in enumerate(array1):\n",
    "        for j, val2 in enumerate(array2):\n",
    "            assert func_mat[i, j] == val1 - val2\n",
    "            \n",
    "def test_plus():\n",
    "    array1 = np.arange(10)*2\n",
    "    array2 = np.arange(10)\n",
    "    \n",
    "    func_mat =  function_d(array1, array2, operation='+')\n",
    "    \n",
    "    for i, val1 in enumerate(array1):\n",
    "        for j, val2 in enumerate(array2):\n",
    "            assert func_mat[i, j] == val1 + val2\n",
    "            \n",
    "def test_times():\n",
    "    array1 = np.arange(10)*2\n",
    "    array2 = np.arange(10)\n",
    "    \n",
    "    func_mat =  function_d(array1, array2, operation='*')\n",
    "    \n",
    "    for i, val1 in enumerate(array1):\n",
    "        for j, val2 in enumerate(array2):\n",
    "            assert func_mat[i, j] == val1 * val2\n",
    "            \n",
    "def test_div():\n",
    "    array1 = np.arange(10)*2\n",
    "    array2 = np.arange(10)\n",
    "    \n",
    "    func_mat =  function_d(array1, array2, operation='/')\n",
    "    \n",
    "    for i, val1 in enumerate(array1):\n",
    "        for j, val2 in enumerate(array2):\n",
    "            assert func_mat[i, j] == val1 / val2\n",
    "    #GOTCHA! This doesn't work because of floating point differences between numpy and python scalars \n",
    "    # This is where that numpy stuff is handy - see the next function\n",
    "\n",
    "def test_div_npt():\n",
    "    from numpy import testing as npt\n",
    "    \n",
    "    array1 = np.arange(10)*2\n",
    "    array2 = np.arange(10)\n",
    "    \n",
    "    func_mat =  function_d(array1, array2, operation='/')\n",
    "    \n",
    "    test_mat = np.empty(((len(array1), len(array2))))\n",
    "    for i, val1 in enumerate(array1):\n",
    "        for j, val2 in enumerate(array2):\n",
    "            test_mat[i, j] =  val1 / val2\n",
    "            \n",
    "    npt.assert_array_almost_equal(func_mat, test_mat)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Problem 3: Set up travis to run your tests whenever a change is made"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Now that you have a testing suite set up, you can try to turn on a continuous integration service to constantly check that any update you might send doesn't create a bug.  We will the [Travis-CI](https://travis-ci.org/) service for this purpose, as it has one of the lowest barriers to entry from Github."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3a: Ensure the test suite is passing locally\n",
    "\n",
    "Seems obvious, but it's easy to forget to check this and only later realize that all the trouble you thought you had setting up the CI service was because the tests were actually broken..."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!py.test"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3b: Set up an account on travis\n",
    "\n",
    "This turns out to be quite convenient.  If you go to the [Travis web site](https://travis-ci.org/), you'll see a \"Sign in with GitHub\" button.  You'll need to authorize Travis, but once you've done so it will automatically log you in and know which repositories are yours."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3c: Create a minimal ``.travis.yml`` file.\n",
    "\n",
    "Before we can activate travis on our repo, we need to tell travis a variety of metadata about what's in the repository and how to run it.  The template below should be sufficient for the simplest needs."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "%%file .travis.yml\n",
    "\n",
    "language: python\n",
    "python:\n",
    "  - \"3.6\"\n",
    "# command to install dependencies\n",
    "#install: \"pip install numpy\"  #uncomment this if your code depends on numpy or similar\n",
    "# command to run tests\n",
    "script: pytest"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Be sure to commit and push this to github before proceeding:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": [
    "!git #complete"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3d: activate Travis\n",
    "\n",
    "You can now click on your profile picture in the upper-right and choose \"accounts\".  You should see your repo listed there, presumably with a grey X next to it.  Click on the X, which should slide the button over and therefore activate travis on that repository. Once you've done this, you should be able to click on the name of the reposository in the travis accounts dashboard, popping up a window showing the build already in progress (if not, just be a bit patient)."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "collapsed": true
   },
   "source": [
    "Wait for the tests to complete.  If all is good you should see a green check next to the repository name.  Otherwise you'll need to go in and fix it and the tests will automatically trigger when you send a new update."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3e: Break the build\n",
    "\n",
    "Make a small change to the repository to break a test.  If all else fails simply add the following test:\n",
    "\n",
    "```\n",
    "def test_fail():\n",
    "    assert False\n",
    "```"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "collapsed": true
   },
   "source": [
    "Push that change up and go look at travis.  It should automatically run the tests and result in them failing."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### 3f: Have your neighbor fix your repo\n",
    "\n",
    "Challenge your nieghbor to find the bug and fix it.  Have them follow the Pull Request workflow, but do *not* merge the PR until Travis' tests have finished (they *should* run automatically, and leave note in the github PR page to that effect).  Once the tests have finished, they will tell you if the fix really does cure the bug.  If it does, merge it and say thank you.  If it doesn't, ask your neighbor to try updating their fix with the feedback from Travis...\n",
    "\n",
    "*Hint: it may be late in the day, but keep being nice!*"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Challenge Problem 1: Use py.test \"parametrization\""
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "``py.test`` has a feature called test parametrization that can be extremely useful for writing easier-to-understand tests. The key idea is that you can use one simple test *function*, but with multiple inputs, and break that out into separate tests.  At first glance this might appear similar to just one test where you interate over lots of inputs, but it's actually much more useful because it doesn't stop at the *first* failure.  Rather it will run all the inputs ever time, helpinf you debug subtle problems where only certain inputs fail.\n",
    "\n",
    "For more info and how to actually *use* the feature, see [the py.test docs on the subject](https://docs.pytest.org/en/latest/parametrize.html).  In this challenge problem, try adapting the Problem 2 cases to use this feature. 2c and 2d are particularly amenable to this approach."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Challenge Problem 2: Test-driven development"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Test-driven development is a radically different approach to designing code from what we're generally used to.  In test-driven design, you write the tests *first*.  That is, you write how you expect your code to behave before writing the code.\n",
    "\n",
    "For this problem, try experimenting with test-driven desgin.  Choose a problem (ideally from your science interests) where you know some clear cases that you could write tests for.  Write the full testing suite (using the techniques you developed above).  Then run the tests to ensure all the new ones are  failing due to lack of implementation, and then write the new code.  A few ideas are given below, but, again, for a real challenge try to come up with your own problem."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "* Compute the location of Lagrange points for two arbitrary mass bodies.  (Good test cases are the Earth-Moon or Earth-Sun system, which you can probably find on wikipedia.)  Consider solving the problem numerically instead of with formulae you can look up, but use the formulae to concoct the test cases.\n",
    "* Write a function that uses one of the a clustering algorithm in [scikit-learn](http://scikit-learn.org/stable/modules/clustering.html) to identify the centers of two 2D gaussian point-clouds.  The tests are particularly easy to formulate before-hand because you know the right answer at the outset if you generate the point-clouds yourself."
   ]
  }
 ],
 "metadata": {
  "anaconda-cloud": {},
  "kernelspec": {
   "display_name": "Python [default]",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.5.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}