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.

Excel is designed to interoperate with external assemblies from VBA using COM. Type libraries built in .NET are not directly COM compatible, however all .NET class libraries including NMath and NMath Stats can be made to present a COM interface making Excel interop possible. This interop is acheived by building the COM type library directly from the assembly – no recompiling needed – using a tool shipped with the .NET framework, and then adding this type library as a reference to an Excel sheets’ VBA macro. Because of the many differences between the C# language and VBA, only a small portion of NMath will be accessable from Excel using this procedure, however a simple remedy will be outlined below that can expand the available functionality to all of NMath.

1. To build the type library interface to the NMath.dll use the regasm.exe utility shipped with the .NET framework

    >regasm.exe NMath.dll /tlb:NMathCom.tlb 

   The COM compatible type library now resides in the NMathCom.tlb file. You will see some warning messages regarding incompatibilities between COM and NMath.

2. Open a spreadsheet, right click on a sheet tab and choose View Code to open the VBA development environment.
3. In the Tools menu select References… and browse to the location of the new NMath type library.

Now the COM compatible portions of NMath are now available for use from VBA. At this point we can code up simple example for generating random numbers in VBA to test out the NMath interoperability

Private Sub TestNMath()
  Dim rand As New NMath.RandGenLogNormal
  rand.Mean = 50
  rand.Variance = 10

  Dim i As Integer
  For i = 1 To 10
    Cells(i, 1) = rand.Next()
  Next
End Sub

This simple VBA script populates cells A1:A10 with LogNormal distributed random numbers with a mean of 50 and a variance of 10. This is not so easily achieved within Excel natively.

Because NMath was not designed from the ground up to interoperate with the aging COM standard, many types will not be useable from VBA. All types lacking an empty (default) constructor, generic classes, static methods, and all static classes are not directly usable from VBA. However, any of these incompatible classes or methods can be wrapped in VB and then made available to Excel via COM. We understand many Excel users are not C#/.NET experts and so we are happy to help wrapping any NMath classes or NMath Stats classes you may need for enhancing and accelerating your Excel models.

Porting Excel Models to C# using NMath

As models grow in Excel, they commonly devolve into a bizantine workbook that becomes slow, opaque, and difficult to version, debug and manage. Usually, it is at this point that users start looking at porting the complex portions to another compatible platform, typically VB. These workbooks tend to be business critical applications so the port must be done carefully and in a piecewise fashion. This conservative strategy can be acheived using the following steps.

1. Identify the computationally demanding and complex portion of the spreadsheet carefully selecting a separation point where the interface is thin between the workbook and the new VB class.
2. Identify all of the input and output cells of this computation.
3. Create build a VB wrapper class in a (class library) VB project that wraps the functionality necessary for the port. This class should include methods for loading and returning results in types compatible with VBA.
4. Build the library and generate the COM type library and add this new type library to the workbook’s VBA.
5. Test the new model in parallel with the existing model.
6. Remove the duplicated Excel computation and enjoy the new faster model.

Porting functionality from an Excel model to a VB type library can be facilitated by NMath due to the large crossover in functionality between Excel and NMath Stats. Also, due to NMath’s high performance, once ports are complete, considerable performance gains can be expected. Below is a table of Excel functions and their supporting classes in either NMath Stats or native .NET.

Happy Computing,

-Paul

Resources

• Microsoft ported the Excel financial functions to F#, making them accessible to any VB or C# project. Follow this link to download this library and read the libraries’ documentation and limitations.
• Microsoft’s landing page on the assembly registration tool regasm.exe for building the COM type libraries.
• A little dated but clear and complete article on accessing .NET assemblies from Excel.

Excel Functions Supported in NMath and .NET

Between the NMath and NMath Stats numeric libraries and the .NET framework many of the Excel functions are covered for a port to C#. If you have a math function that you need which is not covered or is not in this list, let us know and we can probably add it to NMath or NMath Stats. Note resources above if financial functions are needed.

The post Using Excel with NMath appeared first on CenterSpace.

The post Configuring missing values appeared first on CenterSpace.

Due to the increasing prevalence of 64bit operating systems, NMath 4.0 has been re-architected to generate executables that can run on 32-bit or 64-bit platforms with one build. When building simple choose the ‘Any CPU’ configuration, and the resulting application can be redistributed on both 64-bit or 32-bit platforms with no changes.

NMath Versions Prior to 4.0

An NMath application targeting a 32-bit operating system should be built using the “x86” platform configuration in Visual Studio. The resulting application should ship with the 32-bit NMath assemblies found in “Assemblies”. Please note that this application will also run on a 64-bit operating system.

To harness the full capabilities of a 64-bit operating system, build your application using the “x64” platform configuration and deploy with the 64-bit NMath assemblies in “Assemblies/x64”. The resulting application will not run on a 32-bit operating system.

Using the “Any CPU” platform configuration causes .NET to choose a 64-bit application on a 64-bit operating system and a 32-bit application on a 32-bit operating system. This could result in a BadImageFormatException when NMath is loaded.

– Trevor & Paul

.NET 4.5

Please note that there has been a change with Visual Studio 2012 and .NET 4.5. If you are building for .NET 4.5 or higher, also ensure that the Prefer 32-bit flag is unchecked, under Build | Platform target in your project properties.

– Trevor

The post Platform configurations x86, x64 appeared first on CenterSpace.