System.Numerics was done by a separate team in 2014 and was not following the general BCL design gui

System.Numerics was done by a separate team in 2014 and was not following the general BCL design guidelines, and deviated in several places from normal expectations

khitiara•10/21/23, 9:20 PM

oh and INumber adds the %% operator over INumberBase

Ttannergooding System.Numerics was done by a separate team in 2014 and was not following the ge...

Maxine•10/21/23, 9:20 PM

ah, noted

Kkhitiara but if you want to call `IMultiplicativeIdentity.MultiplicativeIdentity` then yo...

Kai•10/21/23, 9:21 PM

Hrm that's unfortunate

Maxine•10/21/23, 9:21 PM

yeah, c# limitation

Kai•10/21/23, 9:21 PM

Idk I'm just not a fan of loosing the well loved Vector3<DateTime>

khitiara•10/21/23, 9:22 PM

fun fact ZeroZero and OneOne are defined in INumberBase and the higher level interfaces use AdditiveIdentityAdditiveIdentity and MultiplicativeIdentityMultiplicativeIdentity

khitiara•10/21/23, 9:22 PM

datetime doesnt implement any of these generic interfaces

khitiara•10/21/23, 9:22 PM

so you cant even get addition from it using this setup

Kai•10/21/23, 9:22 PM

I know, but I should be allowed to declare that :/

Kai•10/21/23, 9:22 PM

Also they do have comparable

khitiara•10/21/23, 9:23 PM

INumber extends IComparable

khitiara•10/21/23, 9:23 PM

as does DateTime when

KKai Where a/b are VectorN<i8> and the output is f8

tannergoodingOP•10/21/23, 9:23 PM

I’d strongly recommend against this. The design guidelines are T in, T out for a reason

Ttannergooding I’d strongly recommend against this. The design guidelines are T in, T out for a...

Kai•10/21/23, 9:24 PM

Can you explain what that reason is? Pretty common in Ai stuffs iirc

Ttannergooding I’d strongly recommend against this. The design guidelines are T in, T out for a...

khitiara•10/21/23, 9:24 PM

rn our only solid option for Length is to either allow specifying an intermediate root-supporting type or have it as an extension that also requires root support on T and the former is in the current working proposal

MMaxine what's teh diff between INumber and INumberBase again

tannergoodingOP•10/21/23, 9:25 PM

INumber is comparable, so real numbers
INumberBase is not, and so includes Complex numbers

Maxine•10/21/23, 9:25 PM

i see

khitiara•10/21/23, 9:25 PM

yup

khitiara•10/21/23, 9:26 PM

well-ordering is the difference, to pull out my abstract math side lmao

KKai Can you explain what that reason is? Pretty common in Ai stuffs iirc

tannergoodingOP•10/21/23, 9:26 PM

Because it leads to bugs. Conversions need to be explicit so you’re aware of the domain change and semantics that entails

Ttannergooding Because it leads to bugs. Conversions need to be explicit so you’re aware of the...

Kai•10/21/23, 9:27 PM

Is specifying a generic argument not specfic enough?

tannergoodingOP•10/21/23, 9:28 PM

No, because that doesn’t tell the user how the data is being used and hurts its ability to be composed, especially across other generics

khitiara•10/21/23, 9:28 PM

also why do we want comparability on the core VectorN types? comparing vectors isnt a very well defined operation generally speaking

Ttannergooding Because it leads to bugs. Conversions need to be explicit so you’re aware of the...

Aqua•10/21/23, 9:29 PM

yeah. 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

Aqua•10/21/23, 9:30 PM

if you need to perform floating point operations on an integer vector, you must explicitly cast to a floating point vector

Aqua•10/21/23, 9:30 PM

gives the user a much better idea of what's going on as well

tannergoodingOP•10/21/23, 9:31 PM

likewise, something like Vector3<DateTime>Vector3<DateTime> doesn't make sense
nor does Vector3<T>Vector3<T> implementing INumber<T>INumber<T>, vectors aren't numbers

tannergoodingOP•10/21/23, 9:31 PM

vectors are, at best, a set of numbers

khitiara•10/21/23, 9:32 PM

ok 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

tannergoodingOP•10/21/23, 9:32 PM

there's a big difference between a Vector3<T>Vector3<T> and a Tuple3<T>Tuple3<T>

tannergoodingOP•10/21/23, 9:32 PM

just remember, Computer Math != Real Math

khitiara•10/21/23, 9:33 PM

yeah

khitiara•10/21/23, 9:33 PM

im 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

tannergoodingOP•10/21/23, 9:34 PM

it'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

tannergoodingOP•10/21/23, 9:34 PM

you can't even rely on x + 1 > xx + 1 > x

khitiara•10/21/23, 9:35 PM

but yeah id restrict T : INumberBase, have Vector3<T> implement the IXXXOperators and IXXXIdentity operations and have anything requiring more be extensions tbh

Maxine•10/21/23, 9:35 PM

yeah i agree, i'm tearing it all down

Kai•10/21/23, 9:36 PM

I 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 ((VectorN<TResult>)vec). LengthSquared((VectorN<TResult>)vec). LengthSquared but then the perf win is small and that's a lot of mental overhead

tannergoodingOP•10/21/23, 9:36 PM

Personally, I'd define public readonly struct Vector3<T> : IEuclideanVector<Vector3<T>, T>public readonly struct Vector3<T> : IEuclideanVector<Vector3<T>, T> and where T : IFloatingPointIeee754<T>where T : IFloatingPointIeee754<T>

then separately define a public readonly struct Point3<T>public readonly struct Point3<T> and where T : INumberBase<T>where T : INumberBase<T>

tannergoodingOP•10/21/23, 9:37 PM

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

khitiara•10/21/23, 9:37 PM

having a unified type between ints and floats and complex etc as elements might as well be a design requirement at this point sadly

khitiara•10/21/23, 9:37 PM

because of how graphics programmers think

tannergoodingOP•10/21/23, 9:38 PM

you're ultimately just going to expose something that is harder to use
and more confusing than 2 types, IMO

this is really like DateTimeDateTime and TimeSpanTimeSpan (and now DateOnlyDateOnly and TimeOnlyTimeOnly)

tannergoodingOP•10/21/23, 9:38 PM

you have 2 logically distinct, but similar, concepts

Kai•10/21/23, 9:39 PM

Hrm.
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;int Chunk; float/Half Offset;

tannergoodingOP•10/21/23, 9:39 PM

you wouldn't want data like that though, that's really inefficient/bad

khitiara•10/21/23, 9:40 PM

the 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

Kai•10/21/23, 9:40 PM

It just makes so much sense for game dev and restricting to the full number + floating point is hard then

Ttannergooding you wouldn't want data like that though, that's really inefficient/bad 😄

Kai•10/21/23, 9:40 PM

Unfortunately... I'd love if there's be a way to make that efficient automatically

tannergoodingOP•10/21/23, 9:41 PM

you provide tooling that helps instruct users on how to setup AoS like data systems

System.Numerics was done by a separate team in 2014 and was not following the general BCL design gui

Similar Threads