Closed YakoYakoYokuYoku closed 3 years ago
Successfully updated to 0.2.3 :wrench:
fix #2
cc @cuviper
@YakoYakoYokuYoku are you still working on this? If not I would be willing to take over trying to get this in.
I left this for two years already because it hasn't got any review (no hard feelings to the maintainers) and failed earlier. Still I'm interested for a trait that implements Float
functionalities while excluding PartialOrd
and similar. You are free to work upon this.
Following my attempts to tackle this issue, I've found an idea that @aplund has purposed may be the solution:
This wasn't a good plan to do at first considering that creating the
Complex<T>
trait conflicts in every way with the widely adoptedComplex<T>
struct type. So we need another name and to separate the trait, and I've come with it::tada:
ComplexFloat
:tada:So why
ComplexFloat
and notComplexNumber
orComplexFooBar
? The answer is, as obvious as it sounds, that the name implies that the methods that are employed takes complex numbers with real and imaginary parts that are floating point numbers. The trait also has an associated namedOutput
so if we want to bound the first with aSelf
we can useOutput
to control the output type of some methods e.g. there()
outputs aFloat
no matter what if you implemented on af64
or aComplex<U>
. The name also leaves room for a futureComplexInteger
trait that has methods for Gaussian Integers.As a note: Huge shoutout to @aplund for suggesting the idea.