On length I understand the roots interface, but on that and on square I don't get the floating point
On length I understand the roots interface, but on that and on square I don't get the floating point arg
Kthe one with a result could be like
Vector3<int>.Length<float>()Koh yeah the static lengthsquared has the float bit
Kidk why
Kmight be a mistake
Malright
so are you for or against Vector3<int>?
so are you for or against Vector3<int>?
Pi am against not looking at it at an individual operation level
KLike imo we need a really good argument for restricting T beyond what's required for the implementation
Mon square, it's because it's a likely overflow
KBut so is add...
Mnot really?
Kthat shouldnt be a generic restriction though
Klike thats an at your own risk thing
Pdot product can be implemented for int, so LengthSquared can be implemented for int, but the BCL has decided we should not be able to square root an int, so we should not implement length
KOr multiply? The argument is that squaring a byte is likely to overflow?
Mok, so pick one
- both LengthSquared<T> and LengthSquared<T, TReturn>
- only LengthSquared<T>
Kboth but no type restriction, because the treturn version can be good to implement length with
Kis my vote
Mokay
Mi'm just asking because i don't want the proposal to have 8000 combinations
Pnow, i'm not against figuring out an API that allows the user to specify that they want an implicit upcast/downcast for a given operation, as this is what we did for some ops in some cases without the user knowing, but this way it codifies intent.
Mnoted
KI like that I can specify the return type, but I don't understand restricting to floating point
Kyeah
Kthat restriction makes no sense to me either
Kfor the squared
Kbecause i could just as easily do a Vector3<short> and the do
.LengthSquared<long>Kor whatever
Pfor LengthSquared no restriction makes sense for the return, you can implement Dot on any INumber and therefore any INumber is a valid return.
Kyeah
Kfor normal not either - the root restriction makes sense.
If BCL adds root capabilities to sbyte we should get it implicitly
If BCL adds root capabilities to sbyte we should get it implicitly
Kyeah
Krequiring IRootFunctions for Length makes sense instead of specifically requiring IFloatingPoint because it lets other non-float types that have sqrt well defined can use it
Klike complex probably could for instance
Kif that ever gets that
Kin general my opinion is we want the actual generic constraints to be as loose as possible
P^^^^^^^
Pbut still while respecting what the BCL have decided (i.e. "oh well i'm just going to require INumber for everything and reimplement everything that's not allowed myself because we want it to be as loose as possible" is not a valid take)
Kyeah
Kif the natural implementation of a (probably extension) function requires an operation imo we should have the generic constraint be the loosest interface for that, so just INumber and IRootFunctions for length for example
Kim fine with requiring either inumber or inumberbase on everything but beyond that keep as loose as possible
Kif we had true generic specialization or the extension objects thing id want to go all-out on the looseness bit
Pbut then you have Silk.NET.Maths 2.X haha
Mdetroit become C++
KKind of fundamental - why have we decided to restrict base Vector to INumber?
AVector2<Texture2D> 
Ptbh yeah base vector should probably just be usable as a storage type for anything that has the super fundamental operations like add, subtract, multiply, divide (and ofc the Min/Max/Zero/One)
KAh wait there's no way to do dependent implementations right? You can't say implement X if T is X?
Mwhat's teh diff between INumber and INumberBase again
Mnope
Pnope this is not rust 
