Open noughtmare opened 2 years ago
This seems like the sort of instance that V1
could have, but V{0,2,3,4}
couldn't, as I'm not sure what sensible Real
behavior would look like for the latter. This is a bit strange, since these types are typically meant to have the same API, but with different dimensions.
On the other hand, there are already some minor differences in the number of instances each vector type has (e.g., some have Field1
but not Field2
instances.) Perhaps this falls into the category of "minor differences" as well. If so, it would be worth mentioning that as a disclaimer in the Haddocks for the instance. A similar disclaimer would apply if you wanted to write a RealFloat
instance for V1
.
I think V0
could also have a trivial instance. And yes, if Real
is added then I see no reason not to add RealFrac
and RealFloat
too.
I think
V0
could also have a trivial instance.
What did you have in mind for an implementation of toRational
? I agree that any such implementation would be trivial, but at the same time, we'd have to make an opinionated choice of which Rational
to return, which gives me pause.
I'm a -0.2 to adding these instances. They don't feel right to me, largely for the reason that @RyanGlScott said that they're not possible for larger vectors, but also it doesn't feel at all a very vector-y typeclass, which I think is an important design consideration here.
What did you have in mind for an implementation of toRational?
Always returning zero. I think Nevermind, this would also imply toRational 0 = 0
should hold for any Real
(It should be a "Num
homomorphism", so to speak).toRational 1 = 1
, so I guess you're right that it is not obvious.
This works:
With this instance you can use
realToFrac
to convert any realV1
to any fractional type.