there isn't any way to make an implicit cast from Vector3<float> to System.Numerics.Vector3, is ther
there 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
length
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
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()
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>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>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>and that will also come alongside
Vector3/4<T>Quaternion<T>Plane<T>Matrix4x4<T>and
Complex<T>plus the general
TensorPrimitives@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
TensorPrimitiveshttps://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
TensorPrimitivesbut over
Span<T>and 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>i 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
fsinand SSE/SSE2 has been faster for nearly 25
for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so
addssaddpsi 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
Logand 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
Tthink about it this way, a
3 of them is then
where-as a
because SIMD is implemented by having
scalar floating-point divide is [11; 12] cycles3 of them is then
[33; 36] cycleswhere-as a
packed floating-point divide is also [11; 12] cyclesbecause SIMD is implemented by having
count parallel unitsTbut those units aren't separate ports; and so you can't dispatch count scalar instructions to them at the same time
because they logically execute together, so you can't have two cores trying to compete for them (how hyperthreading works)
because they logically execute together, so you can't have two cores trying to compete for them (how hyperthreading works)
Mhm.