where we have a loosely constrained type with few members and a bunch of extensions as we have been
where we have a loosely constrained type with few members and a bunch of extensions as we have been considering the whole time
Athat's how my math library works
Aand it works well for me
Ai can't say on a global scale but
Kyeah and that was the thing being worked on hours ago
KRight, but if Point2<T>.Distance returns Point2 again, then we can't really say Point is the absolute type, since that returned point is meaningless without the source it came from
Kit'll find us some point on the grid that just doesn't have any meaning at all
Kbefore the argument started on whether vector3<int> should be permissable out of almost nowhere
Ahave we considered that we may be overthinking this
Kyeah im with just continuing as is, allowing vector3<int> is easy within the framework as proposed and anything more involved is probably overthinking imo
Tdivision isn't often used for things like computing averages, at least not for integers
you typically use floating/fixed point (user facing apps, they expect fractional results)
in practice it gets used for things like bucketing and finding the relevant offset in an array
which includes using the remainder to get the actual final offset
you typically use floating/fixed point (user facing apps, they expect fractional results)
in practice it gets used for things like bucketing and finding the relevant offset in an array
which includes using the remainder to get the actual final offset
Tthere ends up having to be some allowances in the type system, in a way that makes sense
nothing is going to be perfect, it's more a question of can you separate the two core needs enough
so that you aren't ending up with a type that can do 10% of the functionality if you have an integer and 100% with a float
nothing is going to be perfect, it's more a question of can you separate the two core needs enough
so that you aren't ending up with a type that can do 10% of the functionality if you have an integer and 100% with a float
Tbecause having a type where the user doesn't have access to 90% of the functionality, isn't good design
Tespecially if that is expected/common functionality
Ki feel like you might be overestimating how much gamedevs expect a vector-ish type to have length
Kis that because gamedev has bad conventions? yes
Kbut still
Kidk for sure
Tmaybe I'm contrasting AAA vs indie development too much
but, length is a core need for using vectors correctly and efficiently
but, length is a core need for using vectors correctly and efficiently
Pthis is the closing remark on which my brain has shut off here
Pbut these are all important discussion points, as it's bad to have a preconceived conlusion without considering all relevant factors
Tas is normalization, if you aren't normalizing your vectors and local coordinate space
then you're likely losing precision and introducing physics and rendering bugs/quirks
then you're likely losing precision and introducing physics and rendering bugs/quirks
T(and lots of rubber banding/jitter)
KYeah I mean this I fully agree with. I'm just not sure separating into multiple types is the way I want out of this.
I like the 2.X idea of allowing anything on anything, but obviously "try it and see what happens" isn't great.
The current 3.0 design IMO goes too much into having too many things unavailable.
Having more types is of course a solution, but then we have to somehow get the user to choose the correct types.
I like the 2.X idea of allowing anything on anything, but obviously "try it and see what happens" isn't great.
The current 3.0 design IMO goes too much into having too many things unavailable.
Having more types is of course a solution, but then we have to somehow get the user to choose the correct types.
TAnother alternative is to force users to use floating-point (it's better/more appropriate anyways)
and provide some specialized functions for creating a
and provide some specialized functions for creating a
Vector2/3/4<T> from integer typesKseparate types would actually make my reflection-based vertex attribute stuff easyer tbh, it just feels awkward and the integer one doesnt have a natural name imo since point overlooks a bunch of uses for integer tuples supporting some basic vector ops
KThis is true IMO, but I like the rational for
Half a lot. If you choose the type you likely know of the trade offs and putting further barriers in place just to confirm you actually know what you're doing is unecessary. Similar for VectorN<byte> etc.K(also - ignoring any arguments around naming here, idk if I would feel good about Point either, given we also have line and other geometry but that's irrelevant right now)
Punless we explicitly decide on multiple types the name is irrelevant really
Tthe other benefit of this, is that it also better meshes with GPU compute
doing integers on the GPU is generally a bad time, and not always well supported
doing integers on the GPU is generally a bad time, and not always well supported
Pit's worth noting there is some precedent to multiple types in silk maths e.g. see
Box2D vs RectangleT(not well supported meaning, GPUs don't often have many integer compute units; so you're often getting 25% of the throughput by using integers)
KThat's the other thing, and I'd need to do have a look around there. How important is it to have
@Perksey do you have a clue? I'm fairly confident that there's a couple of cases in Vk that take Vector3<T> and you get to put whatever type
Vector3<T> including integers to avoid extra overloads in bindings?@Perksey do you have a clue? I'm fairly confident that there's a couple of cases in Vk that take Vector3<T> and you get to put whatever type
Koh hmm
Kim not remembering anything
KCause Silk isn't just about extending the BCL maths to vectors here, we also (and maybe primarily) want this to work with bindings so CPUGPU is fairly painless
Textending the BCL maths to vectors here(this is happening in .NET 9, it's already been partially started in an OOB in 8)
Kgiven your preferred design I'm assuming float only 
Tfor the .NET 8 OOB feature it's float
but for .NET 9 it will be all floating-point types
but for .NET 9 it will be all floating-point types
Pwe haven't discussed this in terms of SilkX yet. for OpenGL i know there are a lot of manual overloads today, i'll check BT to see if there's any automated ones
Tthe OOB feature is
in .NET 9, that will expand to
and also to
TensorPrimitives, which is math APIs over ROSpan<T> (so TensorPrimitives.Log(ROSpan<float> x, Span<float> destination))in .NET 9, that will expand to
where T : IFloatingPointIeee754<T>and also to
Vector128.Log(Vector128<float> x) and friends (+ double overloads)Kfloating-point typesyeah that's sort of what I ment
Kooooh that is really cool
Tah, well then yes
because
because
Cos(int) doesn't make sense Pdoesn't appear to be any automated ones
Pso there is technically no precedent here
Knot because we will generate 10 overloads for each possible T? Or because the APIs don't have any
PBuildTools does not generate any Silk.NET.Maths or System.Numerics overloads today
Twe'll likely have some APIs where it can minimally make sense for integers though
like
like
Log2(int) (and already have these for scalars, of course)Khrm I'll think this over but it's annoyingly a great argument for making more types. Hard to imagine what the rest of the types look like if we were to have Point + Vector. There is some interesting properties if we separate there also 
KAlso thanks as always Tanner for discussing all this and sharing your wisdom :)
