System.Numerics missing Vector2 and others

[ghost]

I'm trying to move library code from "Framework" to "Standard 2.0/Core 2.1" so that I can then reference the standard/core dll from the remaining legacy framework programs. Overall that process, despite all the marketing material available, has been a confusing mess of opaque names and broken dreams.

In any event, I believe everything I have read (per the .NET implementation support table) indicates that the current Standard version and Core version should work together without issue. Yet the above pictured problem has added another layer of aggravation. I have looked, without success, to find a way to marry this dependency error.

Possibly related to #250.

According to the .NET Portability Report:

[ghost]

@weshaggard very curious about your thoughts on how to address this issue. Thanks

[weshaggard]

System.Numeric.Vectors is not part of .NET Standard but does provide a package that builds on top of netstandard2.0. So if you need to use it from a netstandard library you need to reference the package https://www.nuget.org/packages/System.Numerics.Vectors/.

[ghost]

I don't understand how the reported purpose of the .NET Standard as a common interface conforms given the above portability report. I've read all the old issues and discussions here (including in the dotnet/corefx discussions). If my comprehension of your comments and @tannergooding is correct, this gaping hole is based on an early-2017 issue with Vector<T>. A problem that remains unresolved here far in the future.

If Vector<T> is the issue, how does that invalidate Vector2, etc.?

I have not found where these other Numerics structures are dependent on .Net Core's Vector<T> (...or the more critical lack Span<T>).

The whole point of this exercise, I would think, is so that we don't have to load or worry about a list of desynchronized nuget external packages and dependencies.

[weshaggard]

I don't understand how the reported purpose of the .NET Standard as a common interface conforms given the above portability report.

It is a common set of APIs but not necessarily the full intersection of all APIs for a given set of platform versions. We want to try and maximize this common api set across as many platforms as possible but there is a balance to ensure it is usable on more platforms.

If Vector is the issue, how does that invalidate Vector2, etc.?

We decided to keep the entire System.Numeric.Vector assembly/package out of netstandard for the current version instead of having only part of that assembly in the standard. We will consider putting everything into a future version of the standard but until that happens we have the nuget package that targets netstandard to help fill in the gap.

[ghost]

I can certainly understand that there will not be a full intersection across all implementations. However, we are looking at numerics structures here that are implemented across ALL platforms -- except for your "Standard" interface.

The reason appears to be Vector<T> would be lonely.

How can this Standard interface be the guidon for a level of quality to attain if it's the one not meeting the actual standard?

Considering the time past since this issue appeared, I'm sorry that I have little confidence it is being considered at all.

Microsoft keeps reminding us how much faster .NET Core has become (as of this week); yet Microsoft purposefully designed a block from Framework programs using Core dependencies without this Standard in place. Disingenuous.

My kingdom for want of a nail.

[weshaggard]

@TheRealMal please have a read over #764 if you haven't already. .NET Standard by nature is about sharing/reach and will naturally move slower than .NET Core will move but it will move forward overtime.

While Vector2 exists in .NET Core and .NET Framework it doesn't exist in Xamarin platforms which is also a target for the standard.

As for the coupling of Vector<T> and Vector2, we did ship them already in the System.Numerics.Vectors.dll assembly and so their destiny must remain together in order to remain compatible with existing binaries that have built on top of them. We can play some tricks to split them and put Vector2 in netstandard.dll and keep Vector<T> in System.Numerics.Vectors.dll but that causes other versioning and coupling issues that complicate consumption. We have done similar things in other cases and it has causes numerous issues and so we decided not to do that in this case.

Again there is nothing stopping you from targeting .NET Standard 2.0 and consuming Vector2, you just have to reference the nuget package to do so.

[akoeplinger]

While Vector2 exists in .NET Core and .NET Framework it doesn't exist in Xamarin platforms which is also a target for the standard.

Vector2,3,4 are in Xamarin:

standard/platforms/xamarin.ios/System.Numerics.cs

Line 418 in e7b708a

public partial struct Vector2 : System.IEquatable<System.Numerics.Vector2>, System.IFormattable

[weshaggard]

Thanks for the confirmation @akoeplinger, looks like our api catalog needs updating as https://apisof.net/catalog/System.Numerics.Vector2 doesn't show them. We still have the coupling from the same assembly problem though.

[akoeplinger]

Yeah, I'd love to update apisof.net, it seems to have a pretty outdated dataset for mono/xamarin. Who would we need to talk to?

[ghost]

please have a read over #764 if you haven't already. .NET Standard by nature is about sharing/reach and will naturally move slower than .NET Core will move but it will move forward overtime.

I have now read #764. Thank you very much for bringing it to my attention.

Obviously as an old and simple developer I cannot agree with @terrajobst @karelz et al.

You build implementations to an agreed upon interface, not the other way around. The contract starts here in Standard.

You don't make a Ubiquitous .NET model building a federated interface after the fact. That is clearly a governance model designed and selected to fit your organizational makeup first and foremost. In other words, it makes your internal teams happy.

I believe more than 10,500 votes of user voice feedback supports my position here.

System.Numerics.Vectors.dll

As far as I can tell, the only team talking about the sanctity of this file is you. The Vector2, etc. structures are built in other files in every other implementation and carried under System.Numerics.

I might be harping about some little structures here with very little impact at large, but take my comments as a message from cassandra to your future selves-- you are making a small decision now that is later going to become a major distraction and obstacle to your firm's overall stated goals.

[karelz]

I would just like to call out that there are many (older) standards in our industry which were built first, before (serious) reference implementation and they didn't end well. Many real successful standards these days are built after significant efforts are put into implementation(s) to prove them 'right'. Both cases can be found around network standards (e.g. HTTP).

I believe more than 10,500 votes of user voice feedback supports my position here.

You assume that all 10K users have same view on what comes first - standard vs. implementation. I would challenge that and claim that most people don't care, as soon as it works. How it is created is implementation detail.

[ghost]

I would just like to call out that there are many (older) standards in our industry which were built first, before (serious) reference implementation and they didn't end well. Many real successful standards these days are built after significant efforts are put into implementation(s) to prove them 'right'. Both cases can be found around network standards (e.g. HTTP).

@karelz I could counter with a list a failures along the same lines, but I think it's more telling that you don't recognize the more than 10+ years of .NET Framework development and stabilization as a serious reference implementation on which to establish a standard and work moving forward.

After all, I'm not talking about the intrinsic or platform specific "man behind the curtain" here. I'm talking about the public API users like me must learn and work.

Software engineers are tinkers. Businessmen require predictability. We need to understand our nature if we are to succeed. Many very logical and rational texts are written in all social domains. The methods that work are the ones that account for actual human nature, not just the best of intentions. I caution you to not be naive because its immediately expedient.

I ended up here in the first place because I'm trying to leverage the best parts of .NET Core moving forward without suffering other foolishness that has yet to be sorted. I doubt I'm alone. Nobody wants to be the person who wasted money with betamax, HD DVD, or Silverlight.

You assume that all 10K users have same view on what comes first - standard vs. implementation. I would challenge that and claim that most people don't care, as soon as it works. How it is created is implementation detail.

Fair point. I withdraw the assertion.

[timdoke]

For what it's worth, this issue sort of correlates to where another conversation went: #682. @davidfowl put lots of interesting assertions in the other post..

[ghost]

@timdoke I suspect we are all ineffective here; pleading our cases to the tower guards so to speak.

It would be great to use .NET Core moving forward, but clearly there is some not so subtle manipulation going on here. I would switch to .NET Core just for the speed, compartmentalization/containers, and better user security (explicit permissions). Experience suggests those benefits are being used as a siren song -- at least in terms of making programs to run in windows.

[danmoseley]

@akoeplinger to answer your question, Immo owns apisof.net.