Because it leads to bugs. Conversions need to be explicit so you’re aware of the domain change and s
Because it leads to bugs. Conversions need to be explicit so you’re aware of the domain change and semantics that entails
KIs specifying a generic argument not specfic enough?
TNo, because that doesn’t tell the user how the data is being used and hurts its ability to be composed, especially across other generics
Kalso why do we want comparability on the core VectorN types? comparing vectors isnt a very well defined operation generally speaking
Ayeah. this is why in my generic math library, functions that have a floating point output also must have an input type of float too. integer vectors lose the majority of functions. it just removes the potential for bugs and issues. having float output on an integer vector made me feel a bit uncomfortable when i thought about it, which is why i chose to do things the way i did
Aif you need to perform floating point operations on an integer vector, you must explicitly cast to a floating point vector
Agives the user a much better idea of what's going on as well
Tlikewise, something like
nor does
Vector3<DateTime>nor does
Vector3<T>INumber<T>vectors are, at best, a set of numbers
Kok the abstract math nerd in me has questions about the statement "vectors arent numbers" for technical reasons involving the ambiguity of the word number but in context yeah youre right
Tthere's a big difference between a
Vector3<T>Tuple3<T>just remember, Computer Math != Real Math
Kyeah
Kim still sad that i only found out that the one core tensor library had a sparse matrix/tensor datatype until after it was removed lmao
Tit's a loose abstraction within the confines of a bounded and finite system
and thus needs to redefine many basic rules, invariants, etc
needs to account for new concepts like wrapping, rounding, or per operation error
etc
and thus needs to redefine many basic rules, invariants, etc
needs to account for new concepts like wrapping, rounding, or per operation error
etc
Tyou can't even rely on
x + 1 > xbut yeah id restrict T : INumberBase, have Vector3<T> implement the IXXXOperators and IXXXIdentity operations and have anything requiring more be extensions tbh
Myeah i agree, i'm tearing it all down
KI think that's pretty fair. Thinking about it a bit I can get behind LengthSquared<T, TResult> being ambiguous.
I want to say it's for perf and users can just expect it's the same as
I want to say it's for perf and users can just expect it's the same as
((VectorN<TResult>)vec). LengthSquaredPersonally, I'd define
then separately define a
public readonly struct Vector3<T> : IEuclideanVector<Vector3<T>, T>where T : IFloatingPointIeee754<T>then separately define a
public readonly struct Point3<T>where T : INumberBase<T>keep what works and is well definable for actual vectors as vectors, which requires floating-point like support
and separately define the concepts that work well for any number types, including integers
and separately define the concepts that work well for any number types, including integers
Khaving a unified type between ints and floats and complex etc as elements might as well be a design requirement at this point sadly
Kbecause of how graphics programmers think
Tyou're ultimately just going to expose something that is harder to use
and more confusing than 2 types, IMO
this is really like
and more confusing than 2 types, IMO
this is really like
DateTimeTimeSpanDateOnlyTimeOnlyyou have 2 logically distinct, but similar, concepts
KHrm.
I really want the ability to do a Minecraft-esque thing where I do Vector3<ChunkDimension> and chunk position implements the relevant interfaces over some
I really want the ability to do a Minecraft-esque thing where I do Vector3<ChunkDimension> and chunk position implements the relevant interfaces over some
int Chunk; float/Half Offset;you wouldn't want data like that though, that's really inefficient/bad 
Kthe thing is we often use int vectors in graphics programming to limit imprecision and then cast to floats later when needed for float-only ops, at least in my experience
KIt just makes so much sense for game dev and restricting to the full number + floating point is hard then
KUnfortunately... I'd love if there's be a way to make that efficient automatically
Tyou provide tooling that helps instruct users on how to setup AoS like data systems
Tor which manages it ECS style
KWell... There's ways that make that more 
magic but that's way out of scope and also I don't want to derail this further
magic but that's way out of scope and also I don't want to derail this furtherTeven things like
doubleand that's largely done because game engines like Unity don't provide tooling or instructions on how to properly handle concepts like floating origin
and world chunking
and world chunking
Tso people naively do the worse thing
KYeah. I'm not that concerned with Vector3<Complex> working well, but I'm somewhat concerned with Vector3<sbyte> at least being viable
TWhat real world scenario is there for a
Vector3<sbyte>You're probably still doing something wrong and Vector3<float> is probably 90% + another like 2-5% being Vector3<Half> but...
Aproblem is, how do you express global positions without using a double. sure, at a local scale, the chunking works absolutely fine, but especially to multiplayer, having a global position is pretty important. i thought about ways of trying to get around it but couldn't come up with anything that worked well.
KConsole games, small cellular automata, that kind of thing
Tyou specify it as a 2 part system
1 is the coordinate of the cell you're in
2 is the position in that cell
1 is the coordinate of the cell you're in
2 is the position in that cell
Toften the coordinate of the cell is integer based, and the position in the cell is floating
Mtanner is right
Tit makes it highly efficient and works well with proper world chunking systems
oct trees, quad trees, binary space partitioning, ECS, etc
oct trees, quad trees, binary space partitioning, ECS, etc
Myou store a chunk position and a position within the chunk
Ai managed to get that working at a local scale, but not a global one. i couldn't find a way to make it work well in a server
the problem wasn't the positioning, it was the physics engine
the problem wasn't the positioning, it was the physics engine
Myou wouldn't want ints for that either!
Ayou'd need to have separate simulations for each chunk, and then that leads to a whole load of problems for when two chunks overlap
Myou need a complex system of constraints
Mthis is a hard problem