<https://github.com/piegfx/Warp/tree/main/src/Warp.Math> here's my current generic math implementati
https://github.com/piegfx/Warp/tree/main/src/Warp.Math here's my current generic math implementations if its of any use
K(not mentioning the horrible IDE support for this pattern but...)
Kyeah that works just means things like Length cant be properties
Pyeah I think maybe we should just have a bunch of generic static methods that conditionally enable. a weird consequence of Silk.NET.Maths implementing a proxy over the base ops itself is that all ops were defined in terms of that proxy, allowing strange things like
Sin<byte>
Anote the use of extension methods for things like
Length()
Kno reason length isn't well defined on integers?
PI can live with that, we already have static functions like
Vector2.Length in a lot of places anyway
Ksqrt
Khow is that not well defined on integers?
Ksqrt(4) = 2?
Athe square root of 2 is like 1.4whatever
Pthis is a bad suggestion, we can't have silk contributors looking at this due to the license. they'd become radioactive and we won't be able to take any of their contributions for legal reasons.
Ait only works for some integers
Awhile this code is technically gpl license its so generic (haha im unfunny) that i don't care if it gets copied verbatim
Agiven that i just copied stuff from other people anyway
Kand choosing a floating type to coerce to for sqrt-ing ints is always a choice being made
A(system.numerics mainly)
Pthat's irrelevant, we have to respect the license. DNF can't accept that liability.
Ksqrt(2) won't be precise on floating point either
Kjust like sqrt(2) won't be precise* on integers. Sure one is more precise, but either one will be inaccurate
K^ this has essentially been the stance on 2.X. I still stand by that a lot, as I think without this VectorN<int> is just utterly useless
Psee that's the thing,
Scalar.Sqrt<byte>(64) would do the correct thingP(i think)
Kyes, it will. Otherwise that's a big bug but ye
Keither way the issue is implementation here; cant use generic maths with supporting that
Pi think go with what generic maths is using, the BCL team (tanner) have made these decisions for a reason
Kbecause eg IRootFunctions is only implemented by floats for this case
Pas much as you could do more whacky things with Maths 2.X, doesn't mean that you should in every use case (but mostly the respecting BCL team's decision, that's the most pertinent reason)
Kreturn (T) (object) (sbyte) (float) Math.Sqrt((float) (sbyte) (object) x); its not optimized - but should work fineAi almost made mine support all these functions by all types by converting to double under the hood and then doing the calculations, before casting back to int etc
but i thought
there's a reason why it is like this
so best to do it how its been designed
but i thought
there's a reason why it is like this
so best to do it how its been designed
KIt will even do this beauty
return (T)(object)(sbyte)(float)Sse.SqrtScalar(Vector128.CreateScalarUnsafe((float)(sbyte)(object)x)).ToScalar();Pyeah i've just seen this as well.
Pnot every function is implemented to automatically upcast though, iirc Length is weird
K(does this code predate Math.Sqrt having an intrinsic?)
Kid believe that it predats math(f).sqrt having that yeah
K
P(i believe so, although there is the
MATHF preprocessor define that is used in some places)KRight this actually predates MathF in some cases
Pi'm so happy to be using .NET 8
Kgod it's been a hot second
PIKR
Pcome work on SilkX
Pjoin the dark side
Klol
Kdotnet 8 is real nice here yeah
K
I just had my second day of uniPoh nice how's it going
Kgods i wish there was easier generic specialization in dotnet
Koh nice!
KI don't know tbh
Kseems like I will have a horrendous amount of math shoved down my throat