NumpyDotNet 0.9.83

There is a newer version of this package available.
See the version list below for details.
dotnet add package NumpyDotNet --version 0.9.83                
NuGet\Install-Package NumpyDotNet -Version 0.9.83                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="NumpyDotNet" Version="0.9.83" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add NumpyDotNet --version 0.9.83                
#r "nuget: NumpyDotNet, 0.9.83"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install NumpyDotNet as a Cake Addin
#addin nuget:?package=NumpyDotNet&version=0.9.83

// Install NumpyDotNet as a Cake Tool
#tool nuget:?package=NumpyDotNet&version=0.9.83                

NumpyDotNet

This is a 100% pure .NET implementation of the Numpy API. This library is ported from the real Numpy source code. The C and the Python code of Numpy have been ported to C#. This approach allows us to capture all of the nuances that are in the original Numpy libraries.

We have near 100% of the API ported and unit tested.

The result is a .NET library that is 100% compatible with the Numpy API. It can be run anywhere that .NET can run. There are no dependencies on having Python installed. There are no performance issues related to interoping with Python.

Since all of the underlying data are pure .NET System.Array types, they can be used like any other .NET array.

Our ndarray class is iterable, which means that it can be data bound to windows UI elements.

Nuget packaging

The built release mode libraries are available from here:

https://www.nuget.org/packages/NumpyDotNet/

The unit tests that demonstrate how to use use all of the APIs and features are available here:

https://www.nuget.org/packages/NumpyDotNet.UnitTests/

The simple sample apps that shows windows console and GUI apps using NumpyDotNet:

https://www.nuget.org/packages/NumpyDotNet.SampleApps/

Pure .NET data types

The underlying technology uses 100% .NET data types. If you are working with doubles, then an array of doubles are allocated. There is no worry about mismatching Python allocated C pointers to the .NET data type. There is no worry about interop 'marshalling' of data and the complexities and problems that can cause.

High performance calculations

We make use of .NET parallelization technologies as much as possible, and have optimized common code paths as much as possible. The result is a library that performs as well or better than the Python/C based NumPy in most cases. Coupled with our ability to multi-thread, we may be the fastest and most efficent NumPy in the industry.

To take full advantage of the optimizations, try to do calculations with same type arrays. For example, adding 2 large Float64/double arrays will typically be faster than adding 1 large double array and 1 large integer array. We are able to follow highly optimized paths if the data is the same type.

We do try to upscale smaller arrays internally before doing the calculations so that we can take advantage of the higher performance.

Full multi-threading support

Unlike most NumPy implementations, our library does not require the GIL (Global Interpreter Lock). This allows us to offer a fully multi-threaded library. You are free to launch as many threads as you want to manipulate our ndarray objects. If your application can take advantage of that, you may be able to achieve much higher overall performance.

Take note that if multiple threads are manipulating the same ndarray object, you may get unexpected results. For example, if one thread is adding numbers and another thread is dividing, you may get unexpected calculations. The original authors of NumPy did a fine job of isolating arrays from each other to make this feature possible. If you must manipulate the same ndarray from two different threads, it may be necessary to implement some sort of application layer locking on the ndarray object to get the expected results.

Our API has full support of the following .NET data types:
  • System.Boolean
  • System.Sbyte
  • System.Byte
  • System.UInt16
  • System.Int16
  • System.UInt32
  • System.Int32
  • System.UInt64
  • System.Int64
  • System.Single (float)
  • System.Double
  • System.Decimal (exclusive feature!)
  • System.Numerics.Complex (exclusive feature!)
  • System.Numerics.BigInteger (exclusive feature!)
  • System.Object (exclusive feature!) (a really cool feature!)
  • System.String (exclusive feature!)
  • System.DateTime/System.Timespan (implemented via System.Object data type)
np.random API:

We have ported the original "RandomState" random number generator and most of the distributions associated with that. Seed values produce the same exact output as python which should make porting applications easier.

Our version is implemented as an instantiable class, each with independent random engines so it can be used in multi-threaded applications.

NEW FEATURE! We now support user defined random number generators. Implement a interface class with your generator and pass that to the random constructor and use that to generate random numbers in all of the supported distributions.

Numpy Histogram API:

We have implemented the numpy histogram API. https://numpy.org/doc/stable/reference/routines.statistics.html

Numpy Financial API:

We have implemented the latest numpy financial API with full support of decimal data types. https://numpy.org/numpy-financial/latest/

Future plans include support for:

System.Objects - A really cool feature.

As the base class of all .NET classes, System.Object can hold anything.

You can mix and match data types within the same ndarray such as Int32, Floats, BigInts, strings or custom data objects. If you try to perform math or comparision operations on these objects we do our best effort to make the operation work. If you try something like dividing a string by a integer, the system will throw an exception to let you know it can't be done.

Most NumPy operations have been shown to work really well with these object arrays. We were pleasantly suprised by how well it worked. Check out the latest unit tests for examples of what can be done.

It is very possible to build custom data types and have them processed by the NumpyDotNet system. If you want the ability to add an integer to your custom data object or to add two custom data objects together, simply define your custom data object class to overide the + sign. This holds true for all of the operators allowed by the C# language (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/operator-overloading).

Please see our latest unit tests and sample apps for examples on how to build custom data types with object arrays.

Accessing the underlying array

We have extended the Numpy API to allow you to access the underlying System.Array type data.

ndarray O = np.arange(0, 12, dtype: np.Int32);  // create Int32 ndarray   
ndarray A = (ndarray)O["2:6"];                  // create a view of this middle 4 elements, starting at index 2   

Int32[] O1 = O.AsInt32Array();                  // Int32[] {0,1,2,3,4,5,6,7,8,9,10,11}  reference to real data   
Int32[] A1 = A.AsInt32Array();                  // Int32[] {2,3,4,5}  The view was copied into a new array.   
Int16[] A2 = A.AsInt16Array();                  // Int16[] {2,3,4,5}  The view was copied into a new array.   

Accessing a scalar return value

Many Numpy operations can return an ndarray full of data, or a single scalar object if the resultant is a single item. Python, not being a strongly typed language, can get away with that. .NET languages can't. .NET functions need to specify the exact return type. In most cases, our API will always return an ndarray, even if the resultant is a single data item. To help with this issue, we have extended the ndarray class to have the following APIs.

ndarray A = np.array(new int[] {1,2,3});  

int I1 = (int)A.GetItem(1);  // I1 = 2;  
A.SetItem(99, 1);  
int I2 = (int)A.GetItem(1);  // I2 = 99;  

NEW FEATURE! We now support explicit casting of numpy arrays 0 index element to specific data types. For example:

ndarray A = np.array(new int[] {1,2,3});  

int I1 = (int)A;        // I1 = 1  
int I2 = (double)A;     // throws an exception because the data is not a double  

Array Slicing

Numpy allows you to create different views of an array using a technique called (array slicing). As an interpreted language, python can use syntax that C# can't. This necessitates a small difference in NumpyDotNet.

In the example of python slicing array like this:

A1 = A[1:4:2, 10:0:-2]    

NumpyDotNet supports the slicing syntax like this:

var A1 = A["1:4:2", "10:0:-2"];  

or like this:

var A1 = A[new Slice(1,4,2), new Slice(10,0,-2)];  

In the example of python slicing array with index like this:

A1 = A[1:4:2, 2]    

NumpyDotNet supports the slicing syntax like this:

var A1 = A["1:4:2", 2];  

or like this:

var A1 = A[new Slice(1,4,2), 2];  

We also support Ellipsis slicing:

var A1 = A["..."];  

Documentation

We have worked hard to make NumpyDotNET as similar to the python NumPy as possible. We rely on the official NumPy manual.

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (5)

Showing the top 5 NuGet packages that depend on NumpyDotNet:

Package Downloads
RL.Env

RL.Env is an open source dotnet library for developing and comparing reinforcement learning algorithms by providing a standard API to communicate between learning algorithms and environments, as well a standard set of environments compliant with that API.

MxNet.Sharp

C# Binding for the Apache MxNet library. NDArray, Symbolic and Gluon Supported MxNet is a deep learning framework designed for both efficiency and flexibility. It allows you to mix symbolic and imperative programming to maximize efficiency and productivity. At its core, MXNet contains a dynamic dependency scheduler that automatically parallelizes both symbolic and imperative operations on the fly. A graph optimization layer on top of that makes symbolic execution fast and memory efficient. MXNet is portable and lightweight, scaling effectively to multiple GPUs and multiple machines. MXNet is more than a deep learning project. It is a collection of blue prints and guidelines for building deep learning systems, and interesting insights of DL systems for hackers.

PdfOcr

Pdf OCR library based on paddle OCR

lafd4net

A port of light-anime-face-detector to .NET 5.0, which is based on LFFD, a Light and Fast Face Detector for Edge Devices

Onnx.Net

Open Neural Network Exchange (ONNX) is an open ecosystem that empowers AI developers to choose the right tools as their project evolves. ONNX provides an open source format for AI models, both deep learning and traditional ML. It defines an extensible computation graph model, as well as definitions of built-in operators and standard data types. Currently we focus on the capabilities needed for inferencing (scoring).

GitHub repositories (2)

Showing the top 2 popular GitHub repositories that depend on NumpyDotNet:

Repository Stars
deepakkumar1984/MxNet.Sharp
.NET Standard bindings for Apache MxNet with Imperative, Symbolic and Gluon Interface for developing, training and deploying Machine Learning models in C#. https://mxnet.tech-quantum.com/
Quansight-Labs/numpy.net
A port of NumPy to .Net
Version Downloads Last updated
0.9.86.2 8,467 1/20/2024
0.9.86.1 2,034 10/11/2023
0.9.86 321 9/29/2023
0.9.85.1 2,546 5/15/2023
0.9.85 184 5/11/2023
0.9.84 776 4/9/2023
0.9.83.9 290 4/2/2023
0.9.83.8 247 4/2/2023
0.9.83.7 227 3/31/2023
0.9.83.6 52,771 12/28/2022
0.9.83.5 351 12/27/2022
0.9.83.4 324 12/27/2022
0.9.83.3 396 12/10/2022
0.9.83.2 338 12/9/2022
0.9.83.1 332 12/8/2022
0.9.83 357 12/7/2022
0.9.82.1 3,142 10/28/2022
0.9.82 435 10/25/2022
0.9.81 417 10/23/2022
0.9.80.5 517 10/21/2022
0.9.80.4 1,240 9/26/2022
0.9.80.3 668 9/10/2022
0.9.80.2 450 9/9/2022
0.9.80.1 427 9/9/2022
0.9.80 487 9/3/2022
0.9.79 5,196 5/29/2022
0.9.78 558 5/15/2022
0.9.77 751 4/10/2022
0.9.76 525 3/25/2022
0.9.75 1,966 10/19/2021
0.9.74 2,952 4/25/2021
0.9.73 438 4/18/2021
0.9.72 379 4/16/2021
0.9.71 407 4/15/2021
0.9.70 1,227 3/10/2021
0.9.63 751 2/13/2021
0.9.62 974 1/24/2021
0.9.61 513 12/30/2020
0.9.60 469 12/22/2020
0.9.55 558 11/27/2020
0.9.54 477 11/22/2020
0.9.53 512 11/13/2020
0.9.52 704 9/30/2020
0.9.50 621 8/10/2020
0.9.42 4,360 3/12/2020
0.9.40 642 3/4/2020
0.9.35.3 656 3/3/2020 0.9.35.3 is deprecated because it has critical bugs.
0.9.35.2 641 3/2/2020 0.9.35.2 is deprecated because it has critical bugs.
0.9.35.1 635 3/2/2020 0.9.35.1 is deprecated because it has critical bugs.
0.9.35 673 3/1/2020 0.9.35 is deprecated because it has critical bugs.
0.9.30 759 2/23/2020 0.9.30 is deprecated because it has critical bugs.
0.9.21 615 2/12/2020
0.9.14.3 529 2/8/2020
0.9.14.2 490 2/7/2020
0.9.14.1 563 2/5/2020
0.9.14 813 1/30/2020
0.9.12 681 1/13/2020
0.9.10 672 1/7/2020
0.9.8 590 12/27/2019
0.9.5 613 12/18/2019

rework ndarray.ToArray() to support returning multi-dimensional arrays. Slight API change.