Making a Double Out of Parts in VB.NET

Recently I picked up on a piece of code I had started several months ago and didn't have time to finish.  I was a bit stumped actually, though I've got it pretty well beat into shape now (maybe more on that later).  I was making a VB.NET type Fraction using BigIntegers as the base type.  As such, the class would theoretically be able to represent any rational number.  But what if I wanted to convert that result to a double?  So, I started into the code necessary to do the job.  I began with the easy part, the cases where the numerator and denominator can both be converted to doubles.  In that case, .NET already knows how to do the needed conversions.  But if the numerator or denominator is too large to be converted to a double, the result of division (mathematically) may still be within the range of a double.  For example,

4.445 × 10⁴⁰⁰ / 4.222 × 10³⁹⁹ = 10.528185693983894

An important finishing piece to solving this programming problem is the following function:

Public Shared Function DoubleByParts(positive As Boolean, exponent As Integer, mantissa As Int64) As Double Dim res As Int64 = 0 If Not positive Then res = &H8000000000000000 Dim biasedExp As Int64 = (exponent + 1023) If biasedExp > &H7FF Then Throw New OverflowException("Exponent too large for conversion to type Double.") If biasedExp < 0 Then Throw New OverflowException("Exponent too small for conversion to type Double.") If (mantissa And &HFFF0000000000000) <> 0 Then Throw New OverflowException("Significand too large for conversion to type Double.") biasedExp <<= 52 res = res Or biasedExp res = res Or mantissa Return BitConverter.Int64BitsToDouble(res) End Function

First, for a good summary of the double format, see Double-precision floating-point format (Wikipedia).

Code Walkthrough

The double type has 64 bits as does the Int64 type.  We begin with initializing our result variable to 0.  Depending on whether the number is indicated as positive or not, we set the sign bit.  The sign bit (bit 63, the most significant bit) needs to be set (1) to indicate a negative number.  For simplicity of use, I wanted to let the caller work in terms of the exponent (base 2) rather than with a biased result.  The 1023 "excess" or bias is one of those values you don't want to have to remember.  This function obviates the need to be overly conscious of that value.

After making our biased exponent (biasedExp), we check that it is in range.  We have exactly 11 bits to work with.  If our result is greater than 11 bits (0x7FF in hex, 11111111111 in binary), then we complain to the caller with an OverflowException.  If the result is negative, then it still does not fit into the 11 bits and we complain with an OverflowException in this case as well.  The mantissa is required to be no more than 52 bits.  That's 13 "nibbles" (4 bits, a single hex digit) or 6 1/2 bytes.  If the mantissa has any bits set in the upper 12 bits, we complain.  By calling the variable mantissa I have already declared my draconian intent with this function.  I will not coddle the caller by shifting things that are in the wrong place to the right place.  If the caller sends a mantissa which is too large, they may have done the shifting wrong or they may have incorrectly included the implicit 1 at the beginning of the "binary scientific notation."  Either way, the caller has made an error and we cannot know which one it is.  If we could know which error they made, it might make sense to correct it silently and move on.  However, a wrong assumption here could be somebody's program's undoing.  Therefore, we just complain and let the caller figure out what to do about it.

The biased exponent is now shifted into place—this, like the 1023 excess, falls into the category of "painful detail we want to encapsulate so we can forget about it."  (This is not ambiguous like the too-large-mantissa.)  In our final steps we "Or" the biased exponent and mantissa into place and use a call to BitConverter.Int64BitsToDouble() to ensure we have the proper format.

Room For Improvement

To make this function more robust, an exception class could be defined, either several different ones (one for each error) or a class with properties and enumerations to allow the caller to efficiently test for the particular condition that caused the "overflow".  I note also that I have used OverflowException where an underflow has occurred.  In program debugging, an accurate error message ("over" versus "under") can provide a clue to the person debugging the program.

How to make a .NET (Excel) Add-In Using Visual Basic Express 2010

Automation add-ins are easier than what follows and are the way to go if you just want a few custom functions.  Actually, for efficiency's sake, you might want to just use VBA functions added to Module1  (must be Module1—no renaming to a more suitable name) and then save the workbook as an Excel Add-In (*.xlam).  But, if it is user interaction or in some way making Excel "do stuff" (rather than just return a single result or an array of results), an add-in which implements the IDTExtensibility2 and IRibbonExtensibility interfaces may be a good strategy.  (The main alternative is to use VBA.)

Making an Excel Add-in in VB.NET involves the following (the ordering of the steps is not absolute):

1. Ensure you have Office installed on the development machine and have the Primary Interop Assemblies (PIAs) installed in the Global Assembly Cache (GAC).  You can download them from Microsoft.  (The Microsoft installer will put the PIAs in the GAC.)
2. Start a Class Library project in VB.NET.
3. It's a good idea to generate your own strong name using the sn.exe tool (part of the .NET framework).  You only need one for multiple projects.  In a nutshell, you use the sn.exe tool to create a *.snk file which you will tell VB.NET about.
• let VB.NET know where your *.snk file is by going to Project/Properties..., under Signing check "Sign the assembly" and choose a strong name key file.  You will be able to browse to where your *.snk file is
• if your add-in is intended to be widely distributed, and especially if you want to sell your add-in, you would be well-advised to learn more about this topic to ensure your end-users don't get warning messages that cause them to be (perhaps unduly) alarmed.
4. Apparently, step 4 is unnecessary, but I did step 4, so here it is:  In the project properties, go to Application and click the button Assembly Information....  In this screen, check the Make assembly COM-Visible box.
5. Create a GUID.  There are several ways but a program called guidgen.exe may already be on your computer which will do the job.  Just search your computer for it.  It is located under C:\Program Files\Microsoft SDKs\Windows\... on my computer.
• Copy and Paste the GUID into the Assembly Information... dialog box referred to in step 4.
6. Encapsulate your project in a namespace either by typing it explicitly in the files or by specifying a root namespace in the project properties.
7. Add references to needed PIAs, and extensibility (.NET tab)
• It is recommended that you add these by referencing the Interop Assembly on the .NET tab, not the COM tab. You may need to browse for this: Look under C:\Windows\assembly\gac_msil\Microsoft.Office.Interop.Excel\...
8. Create a class named Connect (seems that the name has to be Connect) which implements the IDTExtensibility2 and IRibbonExtensibility interfaces.
• Implements Extensibility.IDTExtensibility2, Microsoft.Office.Core.IRibbonExtensibility
9. Implement the methods of the interfaces.
10. Decorate the class with COM visibility specifications and include functions for creating and deleting custom registry settings.
11. Register your assembly with regasm.exe.

Steps 8, 9, and 10 are implemented in the following code snippet, which has been parameterized somewhat.

Imports System.Runtime.InteropServices Imports Extensibility Imports XL = Microsoft.Office.Interop.Excel <ClassInterface(ClassInterfaceType.AutoDual), ComVisible(True)> Public Class Connect Implements Extensibility.IDTExtensibility2, Microsoft.Office.Core.IRibbonExtensibility Dim oExcel As XL.Application Public Function GetCustomUI(RibbonID As String) As String Implements Microsoft.Office.Core.IRibbonExtensibility.GetCustomUI Dim res As String res = "<customui xmlns=""http://schemas.microsoft.com/office/2009/07/customui"">" res += "<ribbon>" res += "<qat/>" res += "<tabs>" res += "<tab id=""ArithmosTab"" label=""Arithmos"" insertBeforeQ=""TabFormat"">" res += "<group id=""exportGroup"" label=""Export"" autoScale=""true"">" res += "<button id=""secret111"" label=""Write Secret Number"" screentip=""See what the secret number is..."" imageMso=""DiagramTargetInsertClassic"" onAction=""WriteSecretNumber""/>" res += "</group>" res += "</tab>" res += "</tabs>" res += "</ribbon>" res += "</customUI>" Return res End Function Public Sub WriteSecretNumber(control As Microsoft.Office.Core.IRibbonControl) MsgBox("I don't know what you're talking about.") End Sub Public Sub OnStartupComplete(ByRef custom As System.Array) Implements IDTExtensibility2.OnStartupComplete End Sub Public Sub OnBeginShutdown(ByRef custom As System.Array) Implements IDTExtensibility2.OnBeginShutdown End Sub Public Sub OnDisconnection(RemoveMode As ext_DisconnectMode, ByRef custom As System.Array) Implements IDTExtensibility2.OnDisconnection End Sub Public Sub OnConnection(Application As Object, ConnectMode As ext_ConnectMode, AddInInst As Object, ByRef custom As System.Array) Implements IDTExtensibility2.OnConnection oExcel = Application End Sub Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements IDTExtensibility2.OnAddInsUpdate End Sub <ComRegisterFunctionAttribute()> Public Shared Sub RegisterFunction(ByVal pType As Type) Microsoft.Win32.Registry.ClassesRoot.CreateSubKey("CLSID\{" + pType.GUID.ToString.ToUpper() + "}\Programmable") Dim key As Microsoft.Win32.RegistryKey = Microsoft.Win32.Registry.ClassesRoot.OpenSubKey("CLSID\{" + pType.GUID.ToString.ToUpper() + "}\InprocServer32", True) key.SetValue("", System.Environment.SystemDirectory + "\mscoree.dll", Microsoft.Win32.RegistryValueKind.String) ' Add-in registry settings so Excel knows that this is an add-in and what it should do with it / register for all users key = Microsoft.Win32.Registry.LocalMachine.CreateSubKey("Software\Microsoft\Office\Excel\AddIns\<yournamespace>.Connect") key.SetValue("CommandLineSafe", 0, Microsoft.Win32.RegistryValueKind.DWord) key.SetValue("Description", "<description of your Add-in.>", Microsoft.Win32.RegistryValueKind.String) key.SetValue("LoadBehavior", 3, Microsoft.Win32.RegistryValueKind.DWord) ' if something goes wrong, tell the user what it is key.SetValue("FriendlyName", "<your friendly addin name>", Microsoft.Win32.RegistryValueKind.String) End Sub <ComUnregisterFunctionAttribute()> Public Shared Sub UnregisterFunction(ByVal pType As Type) Microsoft.Win32.Registry.ClassesRoot.DeleteSubKey("CLSID\{" + pType.GUID.ToString.ToUpper() + "}\Programmable", False) Microsoft.Win32.Registry.LocalMachine.DeleteSubKey("Software\Microsoft\Office\Excel\Addins\<yournamespace>.Connect", False) End Sub End Class

The functions RegisterFunction and UnregisterFunction are invoked by utilities like regasm.exe which comes with the .NET Framework.  I have created a batch file which I run in order to register the assembly.  You will need to modify it to suit your assembly.

cd C:\Users\<userid>\Documents\Visual Studio 2010\Projects\<projectname or names>\bin\Release C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm /codebase yourassembly.dll pause

Note that once the Add-in is registered and added, you will not need to reregister it after every Build (while developing).