This version requires developers to be using at least .NET Core 2.0 or at least .NET Framework 4.6.1. Adding support of .NET Core to NMath has been in the works for over a year and was done at the request of many of our active developers.

Future development work will concentrate on the .NET Standard based NMath 7.0. However, NMath 6.2, build on .NET 4.0, but not supporting the .NET Standard Library, will be available for years to come.

Below is a list of major changes released in NMath 7.0:

• 32-bit support has been dropped. Demand has been waning for years for this. Dropping it has made usage simpler and easier.
• GPU support has been dropped. As developers, we liked the automatic GPU offloading. However, the technical advantages have dissipated as multi-core processors have improved. We believe that this is no longer compelling for a general math library.
• NMath Stats has been merged into NMath. This is for ease of use for our users.
• In summer of 2019, our pricing will be streamlined to reflect these changes. There will be one price for a perpetual NMath license and there will be one price for annual NMath maintenance which includes technical support and all upgrades available on NuGet. NMath Stats will no longer be sold separately.
• We have merged the four NMath namespaces into one, CenterSpace.NMath.Core, to simplify development. Originally, CenterSpace had four NMath products and four namespaces, these namespaces CenterSpace.NMath.Core, CenterSpace.NMath.Matrix, CenterSpace.NMath.Stats, CenterSpace.NMath.Analysis reflect that history. We have left stubs so users won’t have any breaking changes.
• We have dropped charting. The ecosystem is full of powerful visualization packages. We have only three main data structures in NMath, vectors, matrices and data frames, and all can be easily used with different charting packages.
• Some of our optimizations use Microsoft Solver Foundation. If you use these, you’ll need to be on the .NET Framework track and not on the .NET Core track.
• We have dropped the installers. The compelling ease of NuGet for our users has made these obsolete.

NMath 7.0 on Windows and Linux

NMath 7.0 on Windows

NMath 7.0 on Linux

NMath 7.0 on OSX

Please try the new versions on NuGet. Feedback welcome as always.

The post NMath 7.0 & the .NET Standard Library appeared first on CenterSpace.

With the release of NMath 6.2.0.41, on March 10, 2018, NMath no longer supports OSX or the Linux x86 operating systems. We are dropping the support of these operating systems due to a decline of demand by our customers. Please contact us with any concerns regarding this change. This release is currently available on NuGet.

Going forward NMath and NMath Premium will naturally continue to support both the 32-bit and 64-bit Windows and 64-bit Linux.

Adding .NET Standard and .NET Core Support

By the end of 2018, NMath will support both the .NET Core and .NET Standard. Supporting both of these .NET standards have been increasingly requested by our customers. If you are unfamiliar with these newest additions to the .NET world, the following briefly defines them.

• .NET Core: This is the latest .NET implementation. It’s open source and available for multiple OSes. With .NET Core, you can build cross-platform console apps and ASP.NET Core Web applications and cloud services.
• .NET Standard: This is the set of fundamental APIs (commonly referred to as base class library or BCL) that all .NET implementations must implement. By targeting .NET Standard, you can build libraries that you can share across all your .NET apps, no matter on which .NET implementation or OS they run.

For further reading on these .NET standards see this MSDN magazine article for an introduction.

Please don’t hesitate to contact us in the comments below or via email with any questions regarding these changes to the CenterSpace .NET NMath library.

The post NMath is Adding .NET Core Support and has Dropped Support of OSX and Linux86 appeared first on CenterSpace.

To do so:

1. Add references to these namespaces: System.Windows.Forms
   System.Windows.Forms.Integration
   
2. In the XAML markup for your WPF window (MainWindow.xaml for example), add a WindowsFormsHost element at the desired location, e.g:<Grid>
   <WindowsFormsHost Name=”ChartHost”/>
   </Grid>
   
3. In the code-behind for the window (MainWindow.xaml.cs for example), set the Child property of the WindowsFormsHost to a Chart. For example:public MainWindow()
   {
   InitializeComponent();
   ChartHost.Child = NMathChart.ToChart(NMathFunctions.CosFunction,
   -Math.PI, Math.PI, 100 );
   }

To see this in action, check out the sample code in the new Visualization Examples solution included in NMath 5.3. For more information about visualization of NMath data types, see:

• Whitepaper: NMath Visualization Using the Microsoft Chart Controls
• Whitepaper: NMath Stats Visualization Using the Microsoft Chart Controls
• the API docs for the CenterSpace.NMath.Charting.Microsoft namespace

The post NMath Charts in WPF appeared first on CenterSpace.

Referencing NMath

To use NMath types in your application, add a reference to NMath.dll, just as you would with other types of .NET applications. If you are using web projects in Visual Studio, you can simply right-click the References folder and select the Add Reference… command. If you specify Copy Local = true in the reference’s properties, then the assembly will be copied to the /bin directory of the web application, facilitating deployment to a web server.

If you are not using web projects in Visual Studio (e.g. using the “Open Web Site” command in Visual Studio, or using other development tools), then you can alternatively specify the reference in the web.config file, like this:

<configuration>
<system.web>
<compilation>
<assemblies>
<add assembly=”NMath, Version=<Version>, Culture=neutral, PublicKeyToken=<Token>”/>
</assemblies>
</compilation>
</system.web>
</configuration>

We recommend that you do not add references to the kernel assemblies, as the appropriate kernel assembly for your platform is loaded at runtime and the appropriate native DLL is linked to the kernel.  Instead, place the kernel assemblies in the same location as the native DLLs, as described below.

Note: when the web server launches an ASP.NET application for the first time, the assemblies in the /bin directory are loaded into memory. If the /bin directory contains a mixture of 32-bit and 64-bit assemblies (for example, both NMathKernelx86.dll and NMathKernelx64.dll), then depending on the configuration of the web server, the application may fail to start and instead throw an exception like this: “An attempt was made to load a program with an incorrect format.”

Kernel Assemblies and Native DLLs

For ASP.NET applications, Microsoft recommends that the /bin directory contain only .NET assemblies, not native DLLs.

If the deployment web server may not have NMath installed directly, then we recommend that the appropriate kernel assembly (NMathKernelx86.dll or NMathKernelx64.dll) and the appropriate native DLLs (e.g. nmath_native_x86.dll or nmath_native_x64.dll) be placed in a folder within the web application root directory, such as /NativeBin. This folder should then be copied to the deployment web server along with the rest of your application.

NMath Configuration

NMath settings can be configured as described in Chapter 1.5 of the NMath User’s Guide. However, when deploying web applications — especially to a shared hosting environment — it’s quite common not to know the details about the physical structure of the file system, and to have restricted access to the system’s environment variables. The references to resources within web apps are typically relative to the root of the virtual directory for the website, regardless of where they might physically reside on disk.

For this reason, starting in NMath 5.3, the ASP.NET ~ operator can be used to specify the location of the NMath native libraries and the log file, relative to the web application root. That is, these can be specified in the web.config file like this:

<add key=”NMathNativeLocation” value=”~/NativeBin” />
<add key=”NMathLogLocation” value=”~/Logs” />

It is not sufficient to use relative paths (e.g. “bin/”), since the executing assembly is usually the ASP.NET worker process, and depending on the web server configuration, the working directory will usually be a subdirectory of the Windows system directory (e.g. c:\windows\system32).

The ~ operator can only be used in ASP.NET applications; specifying this in a Windows application will cause the path to be resolved incorrectly.

The post Building ASP.NET web applications with NMath appeared first on CenterSpace.

Pre .NET 4.5

Until 2012 all Microsoft 32-bit .NET processes were limited to 1.2GB of memory. Theoretically a matrix could take up most of that space. Let’s suppose it’s feasible in our application to have a 1 GB matrix. That matrix would contain 134,217,728 doubles or 268,435,456 floats — for example, a 11,585 x 11,585 square DoubleMatrix or a 16,384 x 16,384 square FloatMatrix.

There is a workaround in 32-bit .NET to increase the process memory to 2.4GB.

1. Add the /3GB switch to boot.ini.
2. After building the application, run the linker as follows:

link -edit -LARGEADDRESSAWARE application.exe

Increasingly, our customers are switching to 64-bit computing in part to get around these memory limitations. Although a 64-bit .NET process’s memory is only limited by the available RAM, the .NET runtime nevertheless limits any one object to 2GB. For that reason, our matrices are limited to a theoretical maximum of 402,653,184 doubles or 805,306,368 floats —for example, a 20,066 x 20,066 square DoubleMatrix or a 28,377 x 28,377 square FloatMatrix.

The good news is that this memory limit has finally been lifted with the release of .NET 4.5. A big thanks to the Microsoft GC .NET team! As they well know many developers have been requesting this change.

.NET 4.5

With the .NET 4.5 release developers can now create objects that exceed the 2 GB per object limit only in x64 environments. In order create these large objects the application must enable the element gcAllowVeryLargeObjects in the run-time schema. This run-time schema controls the behavior of the .NET garbage collection system.

<configuration>
  <runtime>
    <gcAllowVeryLargeObjects enabled="true" />
  </runtime>
</configuration>

These very large objects are subject to the following reasonable restrictions

1. The maximum number of elements in an array is UInt32.MaxValue.
2. The maximum index in any single dimension is 2,147,483,591 (0x7FFFFFC7) for byte arrays and arrays of single-byte structures, and 2,146,435,071 (0X7FEFFFFF) for other types.
3. The maximum size for strings and other non-array objects is unchanged.

The brief Microsoft documentation note can be found here.

What does this mean for NMath?

First NMath has not yet been released with .NET 4.5 (as of July 2012) so all of the following will hold in the future under such a release. All current releases are still subject to the limits outlined above. So looking to the near future, underlying all NMath vectors and matrices is a contiguous 1-D array. This means that for matrices the number of elements must be less than 2,146,435,071. The same holds for vectors. The following table summarizes the maximum size of various NMath objects under .NET 4.5 on a x64 OS with gcAllowVeryLargeObjects enabled.

 Class object
           
 Maximum size - elements 
           
 Memory size - bytes 
 
 
  FloatVector  
 
  2,146,435,071 
       
 7.996 GBytes 
 
  DoubleVector  
 
  2,146,435,071 
       
 15.992 GBytes 
 
  FloatMatrix  
 
  2,146,435,071 
       
 7.996 GBytes 
 
  DoubleMatrix 
 
  2,146,435,071 
       
 15.992 GBytes 
 

The Complex versions of these classes would have the same maximum number of elements but occupy twice the memory. This also means that we will soon be able to allocate a square matrix with a maximum size of [ 46329 x 46329 ].

– Trevor & Paul

NMath 5.3

We have confirmed that the currently shipping version of NMath (version 5.3) can handle very large objects if you use gcAllowVeryLargeObjects and you are targeting .NET 4.5. We have created DoubleMatrix objects as large as 30,000 x 30,000 in this way. That’s a 6.7GB object.

– Trevor

Large Matrices in a Web Environment

It was reported to CenterSpace that the configuration change did not work in web environments. We confirmed this to be true. The good news is that there’s a workaround developed by Microsoft. A Microsoft developer says:

Essentially, the reason it can’t be done at the application-level Web.config is that this particular setting can only be set per-process and only when the CLR is initializing. Since the CLR is already initialized by the time we start reading your Web.config, it’s too late to do anything about it at that time. Using CLRConfigFile should work around this by allowing you to specify an intermediate configuration file that the CLR can use for initialization. Then once the CLR is up, ASP.NET will read your Web.config and run your application as normal.

More info here: here

We have verified that this works.

– Trevor

The post Large matrices and vectors appeared first on CenterSpace.

For those not familiar with the usage and definition of Func<> types within .NET there is a short primer at the end of this post.

Compiler Warning for [Obsolete] NMath defined delegates

All of our NMath delegate types have been deprecated using the .NET [Obsolete()] attribute. The generated compiler warnings will provide the suggested Func type replacement.

Warning 52 'CenterSpace.NMath.Core.NMathFunctions.FloatUnaryFunction'
   is obsolete: 'Use Func< float, float >'   ...

To further clarify, the following table lists the deprecated NMath float delegate types side by side with their replacements. All NMath delegates should be redefined in your code using the generic Func types.

 List of float-precision deprecated NMath delegate types


Old NMath delegates
Replacement


float FloatFunction()
Func< float >


float FloatUnaryFunction( float x )
Func< float, float >


float FloatBinaryFunction( float x, float y )
Func< float, float, float >


float FloatIntFunction( float x, int y )
Func< float, int, float >


float FloatVectorFloatFunction( FloatVector v )
Func< FloatVector, float >


FloatVector
  FloatVectorFloatVectorFunction( FloatVector x )
Func< FloatVector, FloatVector >

There are many other deprecated NMath delegates that should be similarly replaced in your code.

Code examples for updating your code

Where previously you might have created a delegate that takes a double argument and returns a double like this:

NMathFunctions.DoubleUnaryFunction soln =
   delegate(double x) {return (x*x*x) / 3.0 + y0; };

you should now do it like this:

Func soln =
   new Func< double, double >(  x => (x*x*x) / 3.0 + y0 );

All methods in NMath and NMath Stats now take Func<> type delegates. If you use the old NMath delegates types to call a NMath method, an obsolescence warning will be issued by the compiler.

NMath and NMath Stats contain many functors that have now been obsolesced and redefined using a generic Func<> type. The new functor naming convention simply drops the “tion” from “Function” to make the new name. For example, the delegate NMathFunctions.AtanFunction should now be replaced with NMathFunctions.AtanFunc. The old delegate has a type of NMathFunctions.DoubleUnaryFunction, and the new delegate has a type of Func< double, double >. This kind of replacement can be done safely with a global search and replace operation to rid yourself of compiler obsolescence warnings. The table below list a few functor redefinitions that demonstrate the renaming pattern that was applied across the API.

 Sampling of deprecated NMath functors


Old NMath functor
Replacement


DoubleUnaryFunction AbsFunction
Func< double, double > AbsFunc


DoubleUnaryFunction AcosFunction
Func< double, double > AcosFunc


DoubleUnaryFunction AsinFunction
Func< double, double > AsinFunc


DoubleBinaryFunction PowFunction
Func< double, double, double > PowFunc


DoubleIntFunction RoundFunction
Func< double, int, double > RoundFunc


DoubleVectorDoubleFunction
  DoubleNaNMedianFunction
Func< DoubleVector, double > DoubleNaNMedianFunc

Potential Issues

The deprecation process requires us to maintain the old custom delegate defintions in the API methods while introducing the new Func<> based API. As a result, every method call in our API which previously consumed a custom NMath delgate type, a functionally identical signature was added which consumes a Func<> based delegate. This duplication can cause an easy-to-fix compiler error in situations when an anonymous delegate was used instead of a NMath delegate type. Consider the follow line of code which inverts the singular values of a SVD.

      DoubleVector wInverse =
         svDecomp.SingularValues.Apply(
              delegate( double w )
                 { return w < eps ? 0.0 : 1.0 / w; }
         );

Written this way will now cause the following compiler error.

Error	43
The call is ambiguous between the following methods or properties:
'CenterSpace.NMath.Core.DoubleVector.Apply(
    CenterSpace.NMath.Core.NMathFunctions.DoubleUnaryFunction )'
and
'CenterSpace.NMath.Core.DoubleVector.Apply( System.Func )' ....

In this error message, the first Apply() is the old method signature and the second Apply() is the new Func<> based signature. The C# compiler can't choose between the two when provided an anonymous delegate. Exactly why this ambiguity error is generated by the compiler is carefully explained by Eric Lippert over on stackoverflow. Briefly, the ambiguity error arises because both methods equally satisfy the Apply() method signature and the C# standard does not provide a way to judge which would be 'better', and so reports an error. The fix is simple, we just specified explicitly that we want to use the method that takes a generic Func<>.

      DoubleVector wInverse =
         svDecomp.SingularValues.Apply(
              new Func< double, double >
                 ( delegate( double w )
                    { return w < eps ? 0.0 : 1.0 / w; }
                 )
         );

Or, somewhat more concisely using a lamda expression.

      DoubleVector wInverse =
         svDecomp.SingularValues.Apply(
              new Func< double, double >
                 ( w => w < eps ? 0.0 : 1.0 / w  )
         );

A brief Func<> & Action<> primer

The generic delegate types, Func<> and Action<>, were introduced with the .NET 3.5 framework to unify delegate types across various .NET libraries. This allows a .NET library developer like CenterSpace to create an API that accepts generic delegates that are defined elsewhere in client code. The Func and Action are differentiated by their return values: Actions have no return value, Funcs always have a single return value of type TResult. For each of them, the .NET framework defines a type signature that takes between 0 and 16 generically typed arguments.

 .NET Func<> and Action<> definitions


Func
Action


TResult Func()
void Action<>()


TResult Func( T arg )
void Action( T arg )


...
...


TResult Func(
	T1 arg1,
	T2 arg2,
	...
	T15 arg15,
	T16 arg16 )
void Action(
	T1 arg1,
	T2 arg2,
	...
	T15 arg15,
	T16 arg16 )

This is still all abstract. Here's how we create a Func using a lambda expression.

Func mySquaringFunc =
   new Func< double, double> ( x =>  x*x ); 

double xSquared = mySquaringFunc( 45 );  // xSquared = 2025

This Func delegate takes single double value and returns a double value. Lamda expressions are commonly used today to generate delegates, however an anonymous delegate could also be used for the same purpose.

Func mySquaringFunc =
   new Func< double, double> ( delegate( double x ) { return x*x; } ); 

double xSquared = mySquaringFunc( 45 );  // xSquared = 2025

I find the lambda syntax to be more expressive and succinct. From the table above, T1 = double, and TResult = double.

Action types are not used within the NMath API because we are always dealing with functions and return values. However, Actions are similarly defined, and may be used for example in queuing code where a queue manager takes work in the form of Action delegates.

Action< DoubleVector > FFTWorker =
   new Action< DoubleVector >( v =>
      {
         DoubleComplexForward1DFFT fft = new DoubleComplexForward1DFFT( v.Length );
         fft.FFTInPlace( v );
       } );
...
QueueManager.AddWork( FFTWorker, bigDataVector );

The Action above computes the in-place FFT, and the QueueManager can now generically schedule this work on the queue.

Happy Computing,
Paul Shirkey

The post NMath API updated with .NET Func<> delegates appeared first on CenterSpace.

Silverlight is a great way to build line of business applications, but at its core, Silverlight runs within a sandboxed environment, typically within a browser, and usually within a networked intranet or Internet environment.  NMath, on the other hand, uses native libraries to provide high-performance math capabilities to managed code.  While it’s possible to build a Silverlight application that calls NMath functions, it’s worth taking a step back to look at what you really want to accomplish with your software project.

Most often, we find that developers are tasked with building dashboard-style business applications that allow the user to initiate some sort of data analysis, and then see a visualization of results.  In these cases, we generally recommend:

1) Use Silverlight (or HTML5) on the client, perform the analysis on one or more servers, and expose web services to initiate the analysis and deliver the results.

This is probably the most favorable approach, and usually the architecture to default to unless there’s a compelling reason to the contrary.  Some of the advantages of this approach:

• It’s consistent with typical Silverlight application architecture; capabilities in Silverlight and ASP.NET make it easy to build this kind of application.
• It retains the deployment advantages of Silverlight: there’s no need to distribute and install native components to every client machine.
• It retains the cross-platform advantages of Silverlight: the application will work smoothly regardless of client hardware (including on Mac OS).
• Centralizing the analysis on a server makes it easier to scale up with improved server hardware and/or server farms.
• It makes efficient use of network bandwidth: usually there’s little need to transfer all of the source data between client and server, just the results of the analysis.

The primary disadvantages of this approach include:

• This might drive an architectural shift if it’s not already working in a client-server environment.
• It doesn’t take maximum advantage of available computing resources on the client, at least for the analysis (although the application can potentially use the client’s GPU for the visualization).

If you’re certain that you want to perform the analysis on the client using a Silverlight application, you can:

2) Use Silverlight 4+, and use COM interop to invoke COM components that were previously installed on the client.

3) Use Silverlight 5, and use Platform Invoke (P/Invoke) to invoke native components.

There are significant disadvantages to these approaches, in particular:

• You would need to separately distribute your components and get them preinstalled on the local machine.
• The client applications will only run on Windows; you cannot invoke native code on Mac OS from Silverlight.
• Users will need to explicitly grant elevated trust to the Silverlight application.
• You would also need to build your application with out of browser support (if you’re using COM interop).

For the COM interop approach you would use ComAutomationFactory.CreateObject() to instantiate dynamic COM objects, which would also mean that you would require C# 4, Silverlight 4, and Visual Studio 2010.  This approach is less than ideal for new applications; it’s primarily intended for interaction within controlled environments (e.g. interop with Microsoft Office).  For more about this, see:

• Silverlight and Desktop .NET Integration
• Cutting Edge Silverlight4 COM+ Features

For information about P/Invoke in Silverlight 5, see:

• How to: Call Unmanaged Code from Trusted Applications

However, if you’re certain that you want to build a rich client application to perform the analysis on Windows, then you should also evaluate whether Silverlight is the best choice for doing so.  Some alternatives include:

4) Create a rich client application using Windows Presentation Foundation, and run in within the browser using XBAP.

XBAP applications are WPF applications that run in partial trust inside a web browser.  You do have access to more local resources than you do in Silverlight, and you can request the user to grant additional trust if needed.  You’re restricted to using Internet Explorer and Firefox.  For more about this, see:

• WPF XAML Browser Applications Overview
• Wikipedia: XAML Browser Applications
• XBap.org

5) Create a rich client application using Windows Presentation Foundation or Windows Forms, and distribute it via ClickOnce Deployment.

In this scenario, you’re running a full client application within Windows, but taking advantage of some of the deployment advantages of the web, including initial distribution and facilities for automatic application updates.  Generally speaking, this is the preferred way to build rich client applications on Windows.  For more about ClickOnce, see:

• ClickOnce Security and Deployment
• Wikipedia: ClickOnce

Our experienced consulting team is available to help you work through the architectural options that would make the most sense for your specific application; just contact us at consulting@centerspace.net.

The post NMath and Silverlight appeared first on CenterSpace.

The following tests were performed on a DoubleVector of length 10,000,000.

1) Create a new vector. This isn’t really clearing out an existing vector but we thought we should include it for completeness.

 DoubleVector v2 = new DoubleVector( v.Length, 0.0 );

The big drawback here is that you’re creating new memory. Time: 419.5ms

2) Probably the first thing to come to mind is to simply iterate through the vector and set everything to zero.

for ( int i = 0; i < v.Length; i++ )
{
  v[i] = 0.0;
}

We have to do some checking in the index operator. No new memory is created. Time: 578.5ms

3) In some cases, you could iterate through the underlying array of data inside the DoubleVector.

 
for ( int i = 0; i < v.DataBlock.Data.Length; i++ )
{
  v.DataBlock.Data[i] = 0.0;
}

This is a little less intuitive. And, very importantly, it will not work with many views into other data structures. For example, a row slice of a matrix. However, it's easier for the CLR to optimize this loop. Time: 173.5ms

4) We can use the power of Intel's MKL to multiply the vector by zero.

 v.Scale( 0.0 );

Scale() does this in-place. No new memory is created. In this example, we assume that MKL has already been loaded and is ready to go which is true if another MKL-based NMath call was already made or if NMath was initialized. This method will work on all views of other data structures. Time: 170ms

5) This surprised us a bit but the best method we could find was to clear out the underlying array using Array.Clear() in .NET

 Array.Clear( v.DataBlock.Data, 0, v.DataBlock.Data.Length );

This creates no new memory. However, this will not work with non-contiguous views. However, this method is very fast. Time: 85.8ms

To make efficiently clearing a vector simpler for NMath users we have created a Clear() method and a Clear( Slice ) method on the vector and matrix classes. It will do the right thing in the right circumstance. It will be released in NMath 5.2 in 2012.

Test Code

using System;
using CenterSpace.NMath.Core;

namespace Test
{
  class ClearVector
  {
    static int size = 100000000;
    static int runs = 10;
    static int methods = 5;
    
    static void Main( string[] args )
    {
      System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
      DoubleMatrix times = new DoubleMatrix( runs, methods );
      NMathKernel.Init();

      for ( int run = 0; run < runs; run++ )
      {
        Console.WriteLine( "Run {0}...", run );
        DoubleVector v = null;

        // Create a new one
        v = new DoubleVector( size, 1.0, 2.0 );
        sw.Start();
        DoubleVector v2 = new DoubleVector( v.Length, 0.0 );
        sw.Stop();
        times[run, 0] = sw.ElapsedMilliseconds;
        Console.WriteLine( Assert( v2 ) );

        // iterate through vector
        v = new DoubleVector( size, 1.0, 2.0 );
        sw.Reset();
        sw.Start();
        for ( int i = 0; i < v.Length; i++ )
        {
          v[i] = 0.0;
        }
        sw.Stop();
        times[run, 1] = sw.ElapsedMilliseconds;
        Console.WriteLine( Assert( v ) );

        // iterate through array
        v = new DoubleVector( size, 1.0, 2.0 );
        sw.Reset();
        sw.Start();
        for ( int i = 0; i < v.DataBlock.Data.Length; i++ )
        {
          v.DataBlock.Data[i] = 0.0;
        }
        sw.Stop();
        times[run, 2] = sw.ElapsedMilliseconds;
        Console.WriteLine( Assert( v ) );
        
        // scale
        v = new DoubleVector( size, 1.0, 2.0 );
        sw.Reset();
        sw.Start();
        v.Scale( 0.0 );
        sw.Stop();
        times[run, 3] = sw.ElapsedMilliseconds;
        Console.WriteLine( Assert( v ) );

        // Array Clear
        v = new DoubleVector( size, 1.0, 2.0 );
        sw.Reset();
        sw.Start();
        Array.Clear( v.DataBlock.Data, 0, v.DataBlock.Data.Length );
        sw.Stop();
        times[run, 4] = sw.ElapsedMilliseconds;
        Console.WriteLine( Assert( v ) );
        Console.WriteLine( times.Row( run ) );
      }
      Console.WriteLine( "Means: " + NMathFunctions.Mean( times ) );
    }

    private static bool Assert( DoubleVector v )
    {
      if ( v.Length != size )
      {
        return false;
      }
      for ( int i = 0; i < v.Length; ++i )
      {
        if ( v[i] != 0.0 )
        {
          return false;
        }
      }
      return true;
    }
  }
}

- Trevor

The post Clearing a vector appeared first on CenterSpace.

Benchmarks

These benchmarks were run on a 2.80 Ghz, Intel Core i7 CPU, with 4Gb of memory installed.

The clock resolution is 0.003 ns
1024 point, forward, real FFT required 4361.364 ns, Mflops 4069
1000 point, forward, real FFT required 5338.785 ns, Mflops 3235
4096 point, forward, real FFT required 21708.565 ns, Mflops 3924
4095 point, forward, real FFT required 43012.010 ns, Mflops 1980
1024 * 1024 point, forward, real FFT required 15.635 ms, Mflops 2324

I’m estimating the megaflop performance during the FFT using:

This is the asymptotic number of floating point operations for the radix-2 Cooley-Tukey FFT algorithm. This FFT MFlop estimate is used in a number of FFT benchmark reports and serves as a good basis for comparing algorithm efficiency.

As expected we take a performance hit for non-power of 2 lengths, but due to various optimizations for processing prime length FFT kernels (3, 5, 7 & 11), the performance hit is minimal in many cases. The 1000-point FFT has prime factors (2)(2)(2)(5)(5)(5), and the 4095-point FFT has prime factors (3)(3)(5)(7)(13), so those larger prime factors in the 4095-point FFT cost us some performance. Typically, user’s zero pad their data vectors to a power-of-two length to get optimal performance.

Side by side comparison with FFTW

FFTW claims to be the “Fastest Fourier Transform in the West”, and is a clever, high performance implementation of the discrete Fourier transform. This algorithm is shipped with all copies of MATLAB. FFTW is implemented in C and has the reputation as being one of the fastest desktop FFT algorithm.

Both the NMath FFT and the FFTW have a pre-computation setup that establishes the best algorithmic approach for the DFT at hand, before computing any FFT’s. This pre-computational phase is not included in the times below. In the case of the NMath FFT classes, this pre-computational phase in done in the class constructor; Therefore users must avoid constructing NMath FFT classes in tight loops for best performance (as shown in the benchmark code below). Below is a small side-by-side comparison between FFTW and NMath’s FFT (using the numbers from above).

 Comparison of a forward, real, out-of-place FFT. 

 
 FFT length
 
 FFTW 
 
 NMATH FFT 

 
 1024 
 
 4.14 μs
 
 4.36 μs 
 

 
 1000
 
 5.98 μs 
 
 5.33 μs 
 

 
 4096
 
 20.31 μs 
 
 21.71 μs 
 

 
 4095
 
 49.90 μs 
 
 43.01 μs 
 

 
 1024^2 
 
 17.16 ms 
 
 15.63 ms 
 

Clearly NMATH is very competitive with, and at times out-performs FFTW for real FFT’s of both power-of-2 length signals and otherwise. I chose 1D real signals as a test case because this is one of the most frequent use cases of our NMATH FFT library.

On a subjective scale, running a 1024-point FFT on a desktop commodity machine at around (an algorithm normalized) 4 GFlops is amazing. That means that in a real time measurement situation, users can compute 1024-point FFT’s at around 220kHz – all with just a couple of lines of code.

Happy Computing,
Paul

Benchmark Code

 public void BenchMarks()
    {
      Double numberTrials = 10000;
      Double flops;

      Stopwatch timer = new System.Diagnostics.Stopwatch();
      Console.WriteLine( String.Format("The clock resolution is {0:0.000} ns", Stopwatch.Frequency / 1000000000.0 ) );

      // Snip one - power of two
      RandGenUniform rand = new RandGenUniform();
      DoubleForward1DFFT fft = new DoubleForward1DFFT( 1024 );
      DoubleVector realsignal = new DoubleVector( 1024, rand );

      DoubleVector result = new DoubleVector( 1024 * 1024 );

      timer.Reset();
      for( int i = 0; i < numberTrials; i++ )
      {
        timer.Start();
        fft.FFT( realsignal, ref result );
        timer.Stop();
      }
      flops = (2.5 * 1024 * NMathFunctions.Log(1024)) / (((timer.ElapsedTicks / numberTrials) / Stopwatch.Frequency) * 1000000.0 );
      Console.WriteLine( String.Format( "1024 point, forward, real FFT required {0:0.000} ns, Mflops {1:0}", ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000000.0, flops ) );

      // length 1000
      fft = new DoubleForward1DFFT( 1000 );
      realsignal = new DoubleVector( 1000, rand );

      timer.Reset();
      for( int i = 0; i < numberTrials; i++ )
      {
        timer.Start();
        fft.FFT( realsignal, ref result );
        timer.Stop();
      }
      flops = ( 2.5 * 1000 * NMathFunctions.Log( 1000 ) ) / ( ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000.0 );
      Console.WriteLine( String.Format( "1000 point, forward, real FFT required {0:0.000} ns, Mflops {1:0}", ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000000.0, flops ) );

      // length 4096
      fft = new DoubleForward1DFFT( 4096 );
      realsignal = new DoubleVector( 4096, rand );

      timer.Reset();
      for( int i = 0; i < numberTrials; i++ )
      {
        timer.Start();
        fft.FFT( realsignal, ref result );
        timer.Stop();
      }
      flops = ( 2.5 * 4096 * NMathFunctions.Log( 4096 ) ) / ( ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000.0 );
      Console.WriteLine( String.Format( "4096 point, forward, real FFT required {0:0.000} ns, Mflops {1:0}", ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000000.0, flops ) );

      // length 4095
      fft = new DoubleForward1DFFT( 4095 );
      realsignal = new DoubleVector( 4095, rand );

      timer.Reset();
      for( int i = 0; i < numberTrials; i++ )
      {
        timer.Start();
        fft.FFT( realsignal, ref result );
        timer.Stop();
      }
      flops = ( 2.5 * 4095 * NMathFunctions.Log( 4095 ) ) / ( ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000.0 );
      Console.WriteLine( String.Format( "4095 point, forward, real FFT required {0:0.000} ns, Mflops {1:0}", ( ( timer.ElapsedTicks / numberTrials ) / Stopwatch.Frequency ) * 1000000000.0, flops ) );


      // length 1M
      fft = new DoubleForward1DFFT( 1024 * 1024 );
      realsignal = new DoubleVector( 1024 * 1024, rand );

      timer.Reset();
      for( int i = 0; i < 100; i++ )
      {
        timer.Start();
        fft.FFT( realsignal, ref result );
        timer.Stop();
      }
      flops = ( 2.5 * 1024 * 1024 * NMathFunctions.Log( 1024 * 1024 ) ) / ( ( ( timer.ElapsedTicks / 100.0 ) / Stopwatch.Frequency ) * 1000000.0 );
      Console.WriteLine( String.Format( "Million point (1024 * 1024), forward, real point FFT required {0:0.000} ms, Mflops {1:0}", ( ( timer.ElapsedTicks / 100.0 ) / Stopwatch.Frequency ) * 1000.0, flops ) );

    }

The post FFT Performance Benchmarks in .NET appeared first on CenterSpace.

ClickOnce automagically tries to determine the appropriate dependencies to deploy. However, since the NMath kernel and native DLLs are not required at compile-time, but are required at run-time, the ClickOnce mechanism fails. The best solution we’ve found is to:

1. Add NMathKernelx86.dll, NMathKernelx64.dll, nmath_native_x86.dll, nmath_native_x64.dll as files to the project.
2. Set the Build Action to Content.
3. Set Copy to Output Directory to Copy Always.
4. Publish your project, then go to the publish directory\Application Files to verify that these four DLLs have been included.

– Trevor

The post ClickOnce Deployment appeared first on CenterSpace.