this is definitely going way over my head
this is definitely going way over my head
Pthat's about as clear as i can make it
Kah ok cool
Mkai if you understand what he means, please explain it to me in baby words
Kstatic T LengthSquared<T>(this Vector3<T> vec) where T : INumber<T>, IFloatingPoint<T>;
???
???
Mthere is more than one of those!
Mcheck Vector3<T>
Mpublic readonly TReturn LengthSquared<TReturn>() where TReturn : INumber<TReturn>Kyeah
Mthis is an instance method (but it can be an extension method)
Kits a shortcut where TReturn and T are the same
Pbasically if ever we find ourselves constrained by the generic maths constraints, then we probably shouldn't be working to allow whatever you're trying to do
Mhm.
Mwhat is that comment about, though?
KI don't really get why there's two?
Why is the one without a return arg restricted to floating point? Seems like extra typing for user for nothing?
Why is the one without a return arg restricted to floating point? Seems like extra typing for user for nothing?
Mbecause there is no use of calling Length<T> if the result is not a decimal
Kthe one without a result is a shortcut if T is already floating
Kand you just want to use that
Mand because there is no square root for integers
Pbasically no rules were defined for generic maths when Silk.NET.Maths when it was created, and we made no attempt to define them, instead allowing everything in the absence of rules set by an ecosystem authority (a la .NET API Review).
this led to us defining our own Add, Subtract, etc in Scalar.BaseOps, and implementing every algorithm under the sun in terms of those fully generalised BaseOps regardless of whether its correct, makes sense, or would yield the correct results for a given type.
this led to us defining our own Add, Subtract, etc in Scalar.BaseOps, and implementing every algorithm under the sun in terms of those fully generalised BaseOps regardless of whether its correct, makes sense, or would yield the correct results for a given type.
KOn 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