tbf it’s only approved for float and double today so that’s far more likely
tbf it’s only approved for float and double today so that’s far more likely
Talso imo a user wanting to use a vector type with a scalar type that fundamentally cannot represent the vector rules is kind of down to them hahaThe issue is in how it restricts our ability to version the types over time. Can we successful expose an API like
Hypot or DegreesToRadians 5 years after it ships, for example
Twell, rather not approved at all currenlty. It had previously been approved for just those though
TI had to completely pull the approval so we could take it back with generic math in mind
Phmm, but yeah this interesting stuff, this does sort of reassure me on the extension approach - Numerics vs silk.net.maths has seemed to be correctness vs flexibility, so I think that we’d be happy to make those sacrifices, but it obviously doesn’t help us get closer to the day where silk.net.maths doesn’t need to exist I guess. Helpful nonetheless though.
Pcc @khitiara mathsy stuff
Kcool
Mactually, i use int-based vector3 somewhat often
AMthe implementation of sin(x) for
byte should just be a cast to float, get the sine, then cast back to byteA(like you, i use them a lot)
Myou guys seem to be having an X/Y problem trying to implement trigonometric operations on integer types, when the actual use case is just that the result is an integer, not that the operation is performed using integers
Athere is literally no point performing trig operations on integer values
Asince they work in the range of 0 and 1
Mi was thinking degrees not radians
Aif you do it that way the returned value will always be 0 (unless you get lucky in the floating point calculation and it happens to return a perfect 1)
Aeven in degrees
Athey still operate in the range of 0 to 1
Asin(0) = 0
sin(180) = 1
sin(180) = 1
Mno the result would be a float
Mits a really shit sine but i've done it before for reasons
Athen cast back to bytei did not initially gather that from what you said here
Areturning a float would make more sense
Mthat was me being dumb
Mbut yeah you're right this wouldn't work in generic maths
Aalthough i still personally think that there is no point having trig functions on integer types
but yep returning a float/double value is literally the only way it would be remotely useful lol
but yep returning a float/double value is literally the only way it would be remotely useful lol
Mbecause you probably want sin on floats to return floats and sin on doubles to return doubles and you probably want those to work on rad not deg
Mwait
Ayep
Myou could implement the methods as extension methods
MSin(this Vector3<T>) where T : IFloatingPoint<T>M(ignore the method name i just mean the general idea)
Awhy not just
static T Vector3.Sin<T>() where T : INumber<T>, IFloatingPoint<T>?Aor is this not the point of what you are doing
Mthat does not look like valid C#
Ait isn't
Ai more meant
Ainstead of operating directly on the vector
Myeah that works
Meither or
Mthere are uses for both
Atrue, you could always do both
Mlike dot product you want a static method
Abut i'd recommend having the static method at a minimum, its what people using system.numerics, monogame math, opentk math, etc would expect there to be
Myea
Aanother question
Awould the extension method mutate the original vector or would it return a new one?
Mnever mutate
Malways return
Aalright cool
Ayeah