Coordinates tweaks - #7

@iguananaut - this looks fine except for one thing: changing the trig functions to np.sin and such. It's using math right now because this currently never gets an array, and using np.sin on a single value vs. math.sin is a 2000x slowdown. So we have to adjust this once we bring in the arrays, but for now I think it's better to keep using math.

Also, some of my recent changes are now conflicting with this, although I think nothing too crucial.

So in the interest of moving forward, I will resolve the conflict with a manual merge. And I will also rebase your branch here to just remove the one commit that does the numpy changes. I'll be curious to see how github interprets that... Fun git times!

Interesting... so it's showing a reference, but did not close it, despite the fact that 3 of the four commits are now merged in. I'm going to go ahead and close this, since its (mostly) merged, but @iguananaut - if you disagree with my actions re: numpy vs. math, feel free to continue discussing it here. Or, alternatively, wait until astropy#471 is merged and then issue a PR against master.

Fine by me--I'm surprised the np. math functions are so much slower--I always assumed that for scalar input they would just fall back to the simple non-vectorized implementations. For the record I'm seeing something like a 10x slowdown rather than 2000x but I don't know what tests that's based on.

Hmm, I'm now seeing more like 20x, as well, so I'm not sure why the 2000x was happening earlier. But 20x is still enough that it makes sense for now.

But yeah, it's weird how much slower they are. We'll have to consider how we want to work around this later (when we put in arrays), I suppose.