my only concern is that it would complicate developing libraries that depend on silk

P

Perksey•10/21/23, 7:57 PM

so consider: we simply create an archive containing all the generated syntax, you install

Silk.NET

Silk.NET

Silk.NET

Silk.NET, and the source generator contains the same mod pipeline as in SilkTouchX

P

Perksey•10/21/23, 7:57 PM

i mean... yeah that's a valid concern

P

Perksey•10/21/23, 7:57 PM

idk how CsWin32 does this

P

Perksey•10/21/23, 7:57 PM

is sergio in here?

P

Perksey•10/21/23, 7:57 PM

it appears not

P

Perksey•10/21/23, 7:57 PM

bare with

P

Perksey•10/21/23, 8:00 PM

ok sergio is on the Eurasian plate so I will assume that he is winding down for the evening and will take a while to respond

P

Perksey•10/21/23, 8:00 PM

but it's a valid concern

P

Perksey•10/21/23, 8:04 PM

i suppose we could do MSBuild magic and have it as an MSBuild task instead of a source generator

P

Perksey•10/21/23, 8:05 PM

a Silk.NET.dll would be created at build time, all the prebuilt dependencies already referencing that, and each dependent containing metadata on the configuration needed to generate the source that goes into that DLL

P

Perksey•10/21/23, 8:06 PM

but that is no longer Super Easy, Barely an Inconvenience

MMaxine my only concern is that it would complicate developing libraries that depend on ...

P

Perksey•10/21/23, 8:15 PM

it appears CsWin32 exposes an option to expose the bindings as public

P

Perksey•10/21/23, 8:15 PM

so i guess the idea is you make your own common package

M

MaxineOP•10/21/23, 8:15 PM

i hate that

P

Perksey•10/21/23, 8:15 PM

not really great if you want to make an ecosystem

P

Perksey•10/21/23, 8:15 PM

yeah

P

Perksey•10/21/23, 8:15 PM

like how would SilkCommunity work

M

MaxineOP•10/21/23, 8:16 PM

with sourcegen it seems unavoidable that you'd end up with tons of duplicate internal types

P

Perksey•10/21/23, 8:17 PM

the only other possible alternative i can think of is having a mega Silk.NET.dll that contains every possible combination of overloads and bindings, and then just generating a ref assembly on the fly so you don't see the ones you don't want

M

MaxineOP•10/21/23, 8:17 PM

that's horrible but also kinda great

M

MaxineOP•10/21/23, 8:17 PM

type forwarding?

M

MaxineOP•10/21/23, 8:17 PM

can we use that?

P

Perksey•10/21/23, 8:19 PM

don't need to, the assembly that roslyn uses would just be a shim or even just a cut down version of the big assembly

P

Perksey•10/21/23, 8:19 PM

and then once roslyn has read that, we swap it out for the full-fat one using MSBuild

M

MaxineOP•10/21/23, 8:19 PM

will it kill the CLR to have that many overloads?

P

Perksey•10/21/23, 8:19 PM

only if they're used

M

MaxineOP•10/21/23, 8:19 PM

hmmmmm

M

MaxineOP•10/21/23, 8:19 PM

yeah this seems kinda workable

P

Perksey•10/21/23, 8:21 PM

the user would have no idea that those other functions even exist, but they'll still be there for the libraries that do need them

P

Perksey•10/21/23, 8:21 PM

the only thing that'd be hell would be trimming times would go

P

Perksey•10/21/23, 8:21 PM

but thinking about it i don't think we'd even need a mega Silk.NET.dll for this

P

Perksey•10/21/23, 8:21 PM

we could just have it as standard in our packages, but dormant unless you turn it on
i.e. the default experience is you get the reference assemblies for Ptr etc, but you can configure it Not To Do That

M

MaxineOP•10/21/23, 8:22 PM

btw did you check the generic math proposal

P

Perksey•10/21/23, 8:23 PM

will do now

K

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

first comment from me already is why does LengthSquared need a new type? requiring INumber is enough

K

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

Id rename SquareRoot for consistency with existing symbols in the bcl

Kkhitiara Id rename SquareRoot for consistency with existing symbols in the bcl

M

MaxineOP•10/21/23, 8:30 PM

System.Numerics uses Sqrt

M

MaxineOP•10/21/23, 8:30 PM

wait

M

MaxineOP•10/21/23, 8:30 PM

no system.numerics uses SquareRoot. huh

Kkhitiara first comment from me already is why does LengthSquared need a new type? requiri...

M

MaxineOP•10/21/23, 8:31 PM

what do you mean by new type

M

MaxineOP•10/21/23, 8:31 PM

(x*x)+(y*y)+(z*z) is very likely to overflow with integer types

M

MaxineOP•10/21/23, 8:31 PM

so yeah i could jsut leave that burden onto the user, but that is 90% likely a mistake

M

MaxineOP•10/21/23, 8:32 PM

same as DistanceSquared

P

Perksey•10/21/23, 8:37 PM

Given that we have both Point and Vector, surely the latter is assumed to be euclidean and therefore should have length stuff ergo being float only, not just any INumber?
readonly structs all the way, especially now we have withers
definitely prefer static methods on non-generic types, this was an explicit choice in Silk.NET.Maths so that you wouldn't need to repeat the generic unless you absolutely had to
```
thing = Vector2.Abs(thing)
```
thing = Vector2.Abs(thing)
```
thing = Vector2.Abs(thing)
```
thing = Vector2.Abs(thing)
is much cleaner than
```
thing = Vector2<T>.Abs(thing)
```
thing = Vector2<T>.Abs(thing)
```
thing = Vector2<T>.Abs(thing)
```
thing = Vector2<T>.Abs(thing)
. in most cases extension methods just work also, but you do raise a good point that sometimes you will have to repeat the generic but i'm okay with this.
not related to the proposal, but do BigInteger and Complex have the generic maths interfaces implemented? Silk.NET.Maths supports these today.
```
#if NET8_0
```
#if NET8_0
```
#if NET8_0
```
#if NET8_0
this is assumed if we're targeting 3.0. 3.0 will target the latest even-numbered SDK at time of release.
happy with
```
Sqrt
```
Sqrt
```
Sqrt
```
Sqrt
instead of
```
SquareRoot
```
SquareRoot
```
SquareRoot
```
SquareRoot
. generally prefer the names that we've used in
```
Silk.NET.Maths
```
Silk.NET.Maths
```
Silk.NET.Maths
```
Silk.NET.Maths
because we've already bikeshedded these.
```
Because the type of T has to be narrowed to IFloatingPointIeee754<T>, we can't actually implement the interface on Vector3<T>.
```
Because the type of T has to be narrowed to IFloatingPointIeee754<T>, we can't actually implement the interface on Vector3<T>.
```
Because the type of T has to be narrowed to IFloatingPointIeee754<T>, we can't actually implement the interface on Vector3<T>.
```
Because the type of T has to be narrowed to IFloatingPointIeee754<T>, we can't actually implement the interface on Vector3<T>.
I don't think Silk.NET.Maths ever did support Vector-as-Scalar as we had once thought of doing (i.e. allowing
```
Scalar.Add<Vector3<float>>(l, r)
```
Scalar.Add<Vector3<float>>(l, r)
```
Scalar.Add<Vector3<float>>(l, r)
```
Scalar.Add<Vector3<float>>(l, r)
) so we can live with this. it's cursed anyway.
```
Ideally, this should be vectorized. In practice, that's a lot of work.
```
Ideally, this should be vectorized. In practice, that's a lot of work.
```
Ideally, this should be vectorized. In practice, that's a lot of work.
```
Ideally, this should be vectorized. In practice, that's a lot of work.
no more work than we were prepared to do for 2.0
```
Extension 3: INumber<Vector3<T>> Implementation
```
Extension 3: INumber<Vector3<T>> Implementation
```
Extension 3: INumber<Vector3<T>> Implementation
```
Extension 3: INumber<Vector3<T>> Implementation
yeah I guess?
```
Extension 4: Directional static properties
```
Extension 4: Directional static properties
```
Extension 4: Directional static properties
```
Extension 4: Directional static properties
if we're doing something like this it should be an extension method that allows the specification of the coordinate system, not a simple property.
```
Extension 5: Convenience methods
```
Extension 5: Convenience methods
```
Extension 5: Convenience methods
```
Extension 5: Convenience methods
yep fine
```
Extension 6: IUtf8SpanFormattable (.NET 8)
```
Extension 6: IUtf8SpanFormattable (.NET 8)
```
Extension 6: IUtf8SpanFormattable (.NET 8)
```
Extension 6: IUtf8SpanFormattable (.NET 8)
if someone's willing to do it then yeah
```
Implicit cast to Vector2<T>, drop the Z component
```
Implicit cast to Vector2<T>, drop the Z component
```
Implicit cast to Vector2<T>, drop the Z component
```
Implicit cast to Vector2<T>, drop the Z component
should be explicit
generally make sure you have API parity with Silk.NET.Maths. Silk.NET.Maths is the one area where we don't actually need to do any surface API changes (generic maths notwithstanding) because it's pretty solid, and changing anything here would do weird things to user expectations.

obviously none of the above is the official working group stance, make sure you follow the proposal process documented in

documentation/proposals

documentation/proposals

documentation/proposals

documentation/proposals and make a more formal proposal like the WIP one in #1727, making rationale and alternatives (and the discussion points thereof) clear; if you want this in 3.0

P

Perksey•10/21/23, 8:39 PM

cc @kaijellinghaus the maths lord wrt https://gist.github.com/uwx/ee881028f5068f5c0ff29485051a1209

M

MaxineOP•10/21/23, 8:42 PM

The motivation with all of this was to allow Vector3<T> to use int for storage while still returning float for methods like Length(), which is a rare but useful use-case. The extension methods for IFloatingPoint<T> allow you to not have to specify the return type
ok
so from options 1-4 which is your personal preference?
yes for BigInteger, Complex only implements INumberBase, i can broaden the scope of T if desired
noted
noted
noted
i don't understand what you meant by this
noted
noted
noted
i already implemented it
noted
noted

K

Kai•10/21/23, 8:43 PM

I'll look once home.
Only thing I want to point out is that Silk maths is the only lib were we didn't really pay attention in the working group tbh. We've revised and been unhappy with many things so do also take everything there with a grain of salt. Overall it's solid of course.

M

MaxineOP•10/21/23, 8:43 PM

"no more work than we were prepared to do for 2.0" does that mean you're open to implementing it, or don't want to do it because it's not worth it?

P

Perksey•10/21/23, 8:43 PM

yes open to implementing, vectorization is actually called out in the approved 3.0 SDP

M

MaxineOP•10/21/23, 8:44 PM

we can copy tanner's existing code for some operators, others will have to be done from scratch

my only concern is that it would complicate developing libraries that depend on silk

Similar Threads

Similar Threads

Similar Threads