f64 featuers makes incompatible changes to the API

[TheButlah]

Features in rust are not supposed to change the signatures of the API, because it means that turning on the feature is a breaking change. This is the problem because cargo's choice of features as additive across the dependency tree.

For example suppose I have library A that doesn't use f64, and another library B that does. If I add both as a dependency, the KDE crate will be compiled with the f64 enabled. This will cause library A to not compile, because it was using f32.

From the cargo book:

features should be additive. That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features. A feature should not introduce a SemVer-incompatible change

[seatonullberg]

Thanks for bringing this to my attention, I hadn't considered the case of adding dependencies with separate feature constraints. After some investigation it seems that the num-traits crate may be the correct way to handle this. All user-facing signatures could use the Float trait to support both f32 and f64 data. I will add this fix to v0.1.1 and yank v0.1.0.