like have any of you seen the `feature/math-simd` branch
like have any of you seen the
feature/math-simd branch
Ti'm scared. what did tanner invent this time
Pnono this was the WIP work to vectorize silk.net.maths
Pso much work whereas now we don't have to care about the individual ISA
Toh yeah, basically exactly what net8 does
Tno wait, did we get crossplat in net7?
Ti'm too tired for code rn
Pnet7
Pbut yeah we were essentially writing our own
Vector128 xplat helper until the real thing came alongT"my" software rasterizer got quite a nice boost in net8, although it may be the avx512 doing... something, rather than JIT improvements
Tbut that code is completely destroyed by inlining limits 
Pwhen aggressive isn't aggressive enough
Myou can't do extension operators, can you
Mshame
TJIT literally gives up in the middle of my hot methods 
Mincredibly disgusting
Mi'll make it an instance method at least
Kwhy do you need conversion and division to be together?
Klike an as method should be good enough and then implement division using the same type
Mhm.
Mmy thought is
Vector3 / float is a very common pattern and useless with most integer valuesMalright, yeeted
Mdesign RFC: should static methods be provided
- on Vector3<T> (when doing generics, it'd be Vector3<T>.Lerp<TFloat> for instance)
- on static Vector3 (Vector3.Lerp<T, TFloat>, but for non-generic methods it wouldn't require specifying the <T>)
- on both (pick whichever you want)
- on static Vector3 only if the method is generic, otherwise on Vector3<T> (what i'm currently doing, but may be confusing to some)
Moh no, i've invoked tanner
Pi don't know what's happening
Pis this for silk
Msomeone was talking about generic Vector3, so i made a PoC
Mi think it's for silk?
Mi'm just entertained by things like this, and it's late on a friday
Tthe problem here isn't how to do the computation
yes, it is very much intended to be done as floating-point and then cast to integer
(compute the infinitely precise result and round to the nearest representable result)
the problem comes in from how to implement that support generically and correctly
especially over time using where DIM implementations need to be provided
there also lies a slightly more general issue in that not everything can be represented equivalently
for example,
likewise you end up not being able to represent infinites for trig functions
you end up with many other computations resulting in 0 or 1, regardless of input, due to it requiring fractional results
and so many operations functionally end up "pointless" for integrals
yes, it is very much intended to be done as floating-point and then cast to integer
(compute the infinitely precise result and round to the nearest representable result)
the problem comes in from how to implement that support generically and correctly
especially over time using where DIM implementations need to be provided
there also lies a slightly more general issue in that not everything can be represented equivalently
for example,
Sqrt(-1.0f) produces NaN, but it would have to throw for integerlikewise you end up not being able to represent infinites for trig functions
you end up with many other computations resulting in 0 or 1, regardless of input, due to it requiring fractional results
and so many operations functionally end up "pointless" for integrals
Mgood point
Mi ended up not implementing cast to integer, though
Ma function like Vector3.Distance, you obviously want a float
Pi feel like if this is for silk we'd need a proposal-style API summary, this is really hard to visualise
MVector3.DistanceSquared, that just gives you an integer, but it doesn't call sqrt at all
Mi can do that
MPoC was just to see if this was realistically possible
Pi managed to nerdsnipe someone in the Ryujinx Discord to add Obj-C support to ClangSharp btw
Phopefully that goes well
Twell
this is where I was discussion that a
and so it is well suited to representing "euclidean" (straight line) distance
when you start getting to integers, this swaps and what you want is more the manhattan (or taxi cab) distance
or even representing the distance as a tuple
Distance depends on if it's something like straight line distance or notthis is where I was discussion that a
Vector represents what is functionally a magnitude (length) + directionand so it is well suited to representing "euclidean" (straight line) distance
when you start getting to integers, this swaps and what you want is more the manhattan (or taxi cab) distance
or even representing the distance as a tuple
Twhere it represents the edges of the triangle, rather than the hypotenuse
Mmy past uses of vector3int were just a float rounded to zero, so i never took that into consideration
Tand that's where having the distinction between
because a
while the core things people do with
Vector and Point can be usefulbecause a
Vector is largely only beneficial with floating-point, due to the operations it has to supportwhile the core things people do with
Point (or Coordinate or ...) are less mathematical and can have core functionality filled in nicely stillMso, you're proposing having both as generic types?
Athis is why my generic math vectors only implement certain operations for floating point types, such as distance, and even length
Tright.
and
and allow conversion between them for cases like
Vector2<T> where T : IFloatingPoint<T>and
Point2<T> where T : INumber<T>and allow conversion between them for cases like
Point2<int> -> Vector2<float> for exampleMi like that
Mthere isn't any way to make an implicit cast from Vector3<float> to System.Numerics.Vector3, is there
TI get that
but a fundamental component of a
and so if you don't expose
but a fundamental component of a
vector is that it has a lengthand so if you don't expose
length, you don't have a vectorAyeah fair enough
