when aggressive isn't aggressive enough
when 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
Tthat's where I then go, what's the next closest thing where it does make sense for integers as well
and I arrive at
and I arrive at
Point/CoordinateAa lot of my reasoning for using generic math in the first place was to cut down on the number of stuff i'd need to write, i need integer vectors a lot and i simply need them to represent them as a 3-dimentional point, and its easier for me to just use a vector than create a point struct that does the same thing
for silk however I can understand why the distinction could and probably should be made
for silk however I can understand why the distinction could and probably should be made
Tnot really, since casts can only be defined on the
this is where I'd define an
Vector<T> and so must support any Vector<T>, which means it might be losslessthis is where I'd define an
.AsVector3() (or some qualified name that disambiguates here)Myeah
Munfortunate, but workable
Twith "extension everything", you might be able to define an implicit conversion that works like that
but I'm not sure if that's on the table or not
but I'm not sure if that's on the table or not
Myeah that'll be awesome when it comes out in 2036
TI think its in the working set for C# 13, so maybe sooner
but who knows, stuff gets pushed out all the time
but who knows, stuff gets pushed out all the time
Mooh
Ai do have a question - is there any plan for built-in integer vector/point types in system.numerics? i assume not but doesn't hurt to ask
Pwho needs it when you have System.Drawing.Point 
Alol