this is why my generic math vectors only implement certain operations for floating point types, such
this 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 example
Mi 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 vector
Ayeah 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
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> is appropriate won't be as easyI 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
Mthanks, tanner, i'll look into it
Ai'm currently reworking my engine from scratch as i've changed the way i do things a bit, so this code will soon officially be MIT
Mi won't copy your code, just your ideas :^)
Aoh right cool, that would be awesome to have in base .net
Tyep! The
but over
TensorPrimitives are all nice too, since its going to be the full set of math functionsbut over
Span<T> rather than fixed size vectorsTand then expanded to basic BLAS/LAPACK functions as well
Mif the goal is to vectorize all of the implementations, i'm going to be here for the rest of my life
T(doesn't have acosh, asinh, or atanh atm; but has the other 3 + exp + log + a few others)
Awhat is a tensor primitive 
Mholy cow, is this actually fast?
Tit's "tensor operations" but directly over a
Span<T>Ai see
Mi feel like for Vector3, using FPU operations in serial is still faster than doing all of this SIMD stuff
Ttensors being just the abstract terminology encompassing scalar + vector + dense matrix + sparse matrix
AIn mathematics, a tensor is an algebraic object that describes a multilinear relationship between sets of algebraic objects related to a vector space.
why is mathTnot even close 
Mreally?
Mfor 3 components?
Tyeah, the x87 FPU (assuming you're referring to
and SSE/SSE2 has been faster for nearly 25
for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so
fsin and friends) has been effectively deprecated for 20 yearsand SSE/SSE2 has been faster for nearly 25
for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so
addss rather than addps)Mi hate computers
Tso the SIMD algorithm is basically the scalar one, just doing 3 at once
so it takes the same amount of time
so it takes the same amount of time
Mdoes this apply for all operators?
Mi would think serial divide vs SIMD divide would not make a difference
Tthe one exception is you replace branching with ConditionalSelect
and so you still relegate the exceptional cases
for example, with
and only if we have a special case (zero, infinity, nan, subnormal) do we do the extra computation
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/TensorPrimitives.netcore.cs#L11004-L11047
and so you still relegate the exceptional cases
for example, with
Log we have the fast path which is the normal scalar algorithmand only if we have a special case (zero, infinity, nan, subnormal) do we do the extra computation
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/TensorPrimitives.netcore.cs#L11004-L11047
Mhmm interesting
Tthe exceptional cases are expected to be exceptional, so the branch is fine for the majority case where we don't encounter them
and no worse than we'd have for scalar anyways
and no worse than we'd have for scalar anyways