why do you need conversion and division to be together?
why 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 / floatalright, 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)NaNlikewise 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
Distancethis is where I was discussion that a
Vectorand 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
VectorPointbecause a
Vectorwhile the core things people do with
PointCoordinateso, 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>i 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
vectorlengthand so if you don't expose
lengthyeah 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
PointCoordinatea 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>Vector<T>this is where I'd define an
.AsVector3()yeah
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
TI still plan on pushing through
I'd really like to also support integers, but convincing API review that a
I don't have enough time to do everything of course, so I'm not sure what will get done in 9 vs not
and the Arm64 has SVE work that will likely happen in .NET 9
I'm going to try and finish the design proposal for
and that will also come alongside
and
plus the general
Vector2<T> where T : IFloatingPointIeee754<T>I'd really like to also support integers, but convincing API review that a
Point2<T> where T : INumber<T>I don't have enough time to do everything of course, so I'm not sure what will get done in 9 vs not
ISimdVector<TSelf, T> is the thing I really want to finish next (might be internal only until language features come along)and the Arm64 has SVE work that will likely happen in .NET 9
I'm going to try and finish the design proposal for
Vector2<T> in Decemberand that will also come alongside
Vector3/4<T>, Quaternion<T>, Plane<T>, Matrix4x4<T>and
Complex<T>plus the general
TensorPrimitives workM@grifon.petre can you send over your generic math lib, just for me to look
P(this is what Silk.NET.Windowing used before Silk.NET.Maths existed)
Mno proposal yet, but i wonder if it'd be worth it to implement more methods on the Vector3<T> (like what Unity does) or just do the System.Numerics ones
TThere is a proposal up already (via xoofx, from unity) for expanding Vector2/3/4 and Vector64/128/256/512<T> with the rest of the missing IFloatingPointIeee754<T> functions
and that will likely happen in .NET 9, since we're implementing them anyways for
and that will likely happen in .NET 9, since we're implementing them anyways for
TensorPrimitivesAhttps://github.com/piegfx/Warp/tree/main/src/Warp.Math matrix and quaternion have varying levels of implementation (and a generic quaternion supporting int sounds frankly stupid so i'm not even sure i'll bother supporting it), but the rest i'm pretty sure is good