Conflict with new num::Float::epsilon

[cuviper]

Just a heads up -- we recently added Float::epsilon in rust-num/num#231, and then a Crater run showed that glm broke due to call ambiguity. See the logs here:
https://tools.taskcluster.net/task-inspector/#ytvixlBAQzCMhtWXQCM3fA/0

The ambiguous call is in your ApproxEq::is_approx_eq, where Self::BaseType::epsilon could now either mean Float::epsilon or your BaseFloat::epsilon. You could change it to a more explicit call to one of these choices. Or since you seem to just be extending Float, you might remove your epsilon. (Float also now has to_degrees and to_radians, if you like.)

[dche]

Fixed by removing fn epsilon() from BaseFloat.
Thanks for reporting.