All of us at CenterSpace software are proud to announce a partnership with Nevron, leaders in data visualization. Nevron builds .NET components which enable developers to quickly build clean, enterprise quality, user interfaces incorporating well rendered maps, gauges, diagrams, or charts. Nevron has built it’s visualization framework with the developer in mind and has created components that are powerful, yet quick to pick up and work with.

Free Project Examples

As part of of this partnership our software engineers are working together to develop a series of example applications to help our customers quickly become productive using our tool set. Our first example demonstrates how to use the Nevron .NET chart component with some of NMath Stat’s fundamental capabilities: regression and prediction, polynomial curve fitting, and data smoothing. To build and run this example, you’ll need to download this VS8 project, along with evaluation copies of the CenterSpace NMath Suite and the Nevron .NET Chart package. All of this is freely available from our partnership page.

As I mentioned this is the first in a series of examples that we will be jointly developing. Our next example application is in the planning stages, and will cover the building of common charts in statistical process control. Statistical process control is employed across many industries ranging from manufacturing to medicine and has been an area of interest by customers of both companies. We’ll post up a blog article about the example once it’s finished and you’ll see a tweet about it if you are following us.

If you have an idea for an example using Nevon’s and CenterSpace’s tools together, which would help speed along your own project, leave a comment or drop us an email. We just may cook it up!

Discount Bundle

As part of our partnership with Nevron, we are able to offer a substantial discount on package licenses. If you are interested, please email our sales staff and request the Nevron partnership discount.

Thanks for reading,

-The CenterSpace Team

Resources

• CenterSpace partnership information partnership page.
• Nevron technology partnership information page.
• Nevron’s .NET Chart home page.

We’ve had several customers ask about porting their Excel model to a .NET language in order to leverage the performance and functionality of NMath or NMath Stats. NMath does have good crossover functionality with Excel making this porting job easier. It is also possible to accelerate your Excel models by calling the NMath .NET assemblies directly from a VBA macro in Excel . This post provides some guidance for porting all or just a portion of your Excel model to C# and NMath.

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.
(more…)

Customers frequently ask us how large their matrices can be.

NMath matrices (and vectors) are stored internally as an array of floats or doubles.

32-bit .NET processes are limited to 1.2GB of memory. Theoretically a matrix could take up most of that space. Let’s say it’s feasible 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’s a workaround in 32-bit .NET to increase the 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 myapp.exe

where myapp.exe is your application.

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 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,006 square DoubleMatrix or a 28,377 x 28,377 square FloatMatrix.

- Trevor

Update

We have spoken with Microsoft. They are well aware of this issue and are working on a solution. That solution could involve a blob object that could be created of arbitrary size. We have no word on when this will be available.

Back in the early 90’s I went to work for a small, progressive company that was creating and selling C++ class libraries. At this time Object-Oriented programming was still quite new and the developers at the company were a talented group of people who approached programming with a balance of academic rigor and humble pragmatism. Selling code other programmers used in their applications meant that the code we sold had to as error free as humanly possible. This meant large, exhaustive tests suites, and copious use of what we called pre-conditions and post-conditions.

Pre-conditions and Post-conditions

Frequently, before a function begins executing we require certain conditions to be true for the function to successfully complete. These conditions may be upon the functions arguments, like a reference not being null, or an integer being non-negative or, if the function is a member function on a class, we may require the class instance to be in a particular state. For example, many collection iterators do not reference a collection element when first constructed, you must first call the next method before invoking a dereference method. Doing otherwise will cause an error. In this case the iterators’ dereference method has a pre-condition that the given instance must be actually looking at a valid collection element location. Similarly, after a function has completed we frequently expect certain post-conditions to be true. If the function computes a return value, we expect it to a valid one. In addition, if the function is a class member function, we may require its invocation to have changed the state of the instance it was invoked upon and a post-condition is a check on the validity of that final state.

In the Old Days…

The pre and post condition code we used took the form of C/C++ macros taking a Boolean parameter and were placed at the beginning and end of a functions body. Unless a “debug” preprocessor symbol was defined in the compile, the macros expanded to nothing. Thus, not using the condition macros for fear of impacting performance sensitive code with overly obsessive error checking was not a valid excuse. I really liked the idea of pre and post conditions and used them frequently. Sure, invalid input or state will cause an error, hopefully an exception, to occur anyway, so why bother with the extra code? Here are a few reasons:

1. The error that occurs when a pre-condition for a function is not met may be triggered several function calls later, and it may not be obvious that the error occurred from something like invalid input to a function several levels up in the call stack. This is also true for function post-conditions. If, say, invalid input is returned, it may cause an error far removed from the point of infraction. It’s best to identify these problems as close as possible to the source.
2. It saves time. Checking for things like valid input arguments is something most programmers do anyway with an if-then-throw statement. Some kind of condition checking code can make this check a one-liner.
3. It makes code more readable. A function with pre and post conditions makes it explicit to the reader exactly what assumptions are necessary for the function body to execute and what constitutes a successful execution.

Pre and post conditions are especially useful for numeric programming. Many mathematical functions have restricted domains, like square root, and log, and linear algebra operations involving matrices and vectors usually require those objects to have consummate dimensions. Many times these errors do not occur immediately upon a function invocation or return, but are removed from those execution points.

Back to the Future

As I moved on to work with other companies, I did not encounter any other explicit pre and post condition checking practiced by the programmers. And, I must admit, I didn’t ever overcome the inertia of having to roll my own, though I did think about doing it more than once. Now the .NET platform has now provided me with pre and post condition checking code! The project goes by the shorter – but just as descriptive – moniker of “Code Contracts” and promises to be much more robust than the old C/C++ macros I had used in the distant past. I won’t go into detail about Code Contracts here, because there is lot of information available on line and because we have not yet started using them in our code so I don’t know a lot about them. However, I look forward to taking .NET Code Contracts for a test drive.

http://research.microsoft.com/en-us/projects/contracts/

Steve