dot product can be implemented for int, so LengthSquared can be implemented for int, but the BCL has

dot product can be implemented for int, so LengthSquared can be implemented for int, but the BCL has decided we should not be able to square root an int, so we should not implement length

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

Or multiply? The argument is that squaring a byte is likely to overflow?

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

ok, so pick one

both LengthSquared<T> and LengthSquared<T, TReturn>
only LengthSquared<T>

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

both but no type restriction, because the treturn version can be good to implement length with

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

is my vote

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

okay

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

i'm just asking because i don't want the proposal to have 8000 combinations

PPerksey dot product can be implemented for int, so LengthSquared can be implemented for ...

PerkseyOP•10/21/23, 9:07 PM

now, i'm not against figuring out an API that allows the user to specify that they want an implicit upcast/downcast for a given operation, as this is what we did for some ops in some cases without the user knowing, but this way it codifies intent.

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

noted

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

I like that I can specify the return type, but I don't understand restricting to floating point

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

yeah

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

that restriction makes no sense to me either

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

for the squared

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

because i could just as easily do a Vector3<short> and the do .LengthSquared<long>.LengthSquared<long>

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

or whatever

PerkseyOP•10/21/23, 9:08 PM

for LengthSquared no restriction makes sense for the return, you can implement Dot on any INumber and therefore any INumber is a valid return.

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

yeah

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

for normal not either - the root restriction makes sense.
If BCL adds root capabilities to sbyte we should get it implicitly

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

yeah

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

requiring IRootFunctions for Length makes sense instead of specifically requiring IFloatingPoint because it lets other non-float types that have sqrt well defined can use it

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

like complex probably could for instance

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

if that ever gets that

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

in general my opinion is we want the actual generic constraints to be as loose as possible

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

^^^^^^^

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

but still while respecting what the BCL have decided (i.e. "oh well i'm just going to require INumber for everything and reimplement everything that's not allowed myself because we want it to be as loose as possible" is not a valid take)

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

yeah

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

if the natural implementation of a (probably extension) function requires an operation imo we should have the generic constraint be the loosest interface for that, so just INumber and IRootFunctions for length for example

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

im fine with requiring either inumber or inumberbase on everything but beyond that keep as loose as possible

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

if we had true generic specialization or the extension objects thing id want to go all-out on the looseness bit

PerkseyOP•10/21/23, 9:14 PM

but then you have Silk.NET.Maths 2.X haha

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

detroit become C++

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

Kind of fundamental - why have we decided to restrict base Vector to INumber?

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

Vector2<Texture2D>Vector2<Texture2D> when

PerkseyOP•10/21/23, 9:15 PM

tbh yeah base vector should probably just be usable as a storage type for anything that has the super fundamental operations like add, subtract, multiply, divide (and ofc the Min/Max/Zero/One)

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

Ah wait there's no way to do dependent implementations right? You can't say implement X if T is X?

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

what's teh diff between INumber and INumberBase again

KKai Ah wait there's no way to do dependent implementations right? You can't say impl...

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

nope

KKai Ah wait there's no way to do dependent implementations right? You can't say impl...

PerkseyOP•10/21/23, 9:16 PM

nope this is not rust

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

Well shit

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

i guess i could add interface requirements for the required operators only

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

but if we want Vector3<T> to implement INumber<Vector3<T>> we need that constraint

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

unless i can work around it

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

Spitballing - have we considered doing if (T is ISomeInterface)...if (T is ISomeInterface)...? Similar to 2.X?

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

cant call static abstracts/virtuals from that

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

? Not sure I get that

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

so lose all the benefit of generic maths over the 2.X approach

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

I mean... Yeah, that'd be more just a modernization of the 2.X approach tbh

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

you can also only do that comparison without an instance using reflection

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

but if you want to call IMultiplicativeIdentity.MultiplicativeIdentityIMultiplicativeIdentity.MultiplicativeIdentity then you cant without reflection unless thats a required generic constraint

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

INumber adds clamp, max, min, and comparison stuff over INumberBase

MMaxine no system.numerics uses SquareRoot. huh

tannergooding•10/21/23, 9:19 PM

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

dot product can be implemented for int, so LengthSquared can be implemented for int, but the BCL has

Similar Threads