Ah wait there's no way to do dependent implementations right? You can't say implement X if T is X?
Ah 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 
KWell shit
Mi guess i could add interface requirements for the required operators only
Mbut if we want Vector3<T> to implement INumber<Vector3<T>> we need that constraint
Munless i can work around it
KSpitballing - have we considered doing
if (T is ISomeInterface)...? Similar to 2.X?
Kcant call static abstracts/virtuals from that
K? Not sure I get that
Kso lose all the benefit of generic maths over the 2.X approach
KI mean... Yeah, that'd be more just a modernization of the 2.X approach tbh
Kyou can also only do that comparison without an instance using reflection
Kbut if you want to call
IMultiplicativeIdentity.MultiplicativeIdentity then you cant without reflection unless thats a required generic constraintKINumber adds clamp, max, min, and comparison stuff over INumberBase
TSystem.Numerics was done by a separate team in 2014 and was not following the general BCL design guidelines, and deviated in several places from normal expectations
Koh and INumber adds the
% operator over INumberBase
Mah, noted
KHrm that's unfortunate
Myeah, c# limitation
KIdk I'm just not a fan of loosing the well loved Vector3<DateTime>
Kfun fact
Zero and One are defined in INumberBase and the higher level interfaces use AdditiveIdentity and MultiplicativeIdentityKdatetime doesnt implement any of these generic interfaces
Kso you cant even get addition from it using this setup
KI know, but I should be allowed to declare that :/
KAlso they do have comparable
KINumber extends IComparable
Kas does DateTime 
TI’d strongly recommend against this. The design guidelines are T in, T out for a reason
KCan you explain what that reason is? Pretty common in Ai stuffs iirc
Krn our only solid option for Length is to either allow specifying an intermediate root-supporting type or have it as an extension that also requires root support on T and the former is in the current working proposal
TINumber is comparable, so real numbers
INumberBase is not, and so includes Complex numbers
INumberBase is not, and so includes Complex numbers
Mi see
Kyup
Kwell-ordering is the difference, to pull out my abstract math side lmao
TBecause it leads to bugs. Conversions need to be explicit so you’re aware of the domain change and semantics that entails
KIs specifying a generic argument not specfic enough?
TNo, because that doesn’t tell the user how the data is being used and hurts its ability to be composed, especially across other generics
Kalso why do we want comparability on the core VectorN types? comparing vectors isnt a very well defined operation generally speaking
Ayeah. this is why in my generic math library, functions that have a floating point output also must have an input type of float too. integer vectors lose the majority of functions. it just removes the potential for bugs and issues. having float output on an integer vector made me feel a bit uncomfortable when i thought about it, which is why i chose to do things the way i did
Aif you need to perform floating point operations on an integer vector, you must explicitly cast to a floating point vector
Agives the user a much better idea of what's going on as well
Tlikewise, something like
nor does
Vector3<DateTime> doesn't make sensenor does
Vector3<T> implementing INumber<T>, vectors aren't numbersTvectors are, at best, a set of numbers
Kok the abstract math nerd in me has questions about the statement "vectors arent numbers" for technical reasons involving the ambiguity of the word number but in context yeah youre right
Tthere's a big difference between a
Vector3<T> and a Tuple3<T>Tjust remember, Computer Math != Real Math
Kyeah
Kim still sad that i only found out that the one core tensor library had a sparse matrix/tensor datatype until after it was removed lmao
Tit's a loose abstraction within the confines of a bounded and finite system
and thus needs to redefine many basic rules, invariants, etc
needs to account for new concepts like wrapping, rounding, or per operation error
etc
and thus needs to redefine many basic rules, invariants, etc
needs to account for new concepts like wrapping, rounding, or per operation error
etc