BigIntegers for Delphi

An up-to-date version of this and other files can be found in my DelphiBigNumbers project on GitHub.

BigIntegers

The trouble with integers is that we have examined only the very small ones. Maybe all the exciting stuff happens at really big numbers, ones we can’t even begin to think about in any very definite way. Our brains have evolved to get us out of the rain, find where the berries are, and keep us from getting killed. Our brains did not evolve to help us grasp really large numbers or to look at things in a hundred thousand dimensions. — Ronald Graham

On many occasions, I missed a BigInteger type in Delphi. I wanted to have a type with which you could do simple things like:

var
  A, B, C, D: BigInteger;
begin
  A := 3141592653589793238462643383279;
  B := 1414213562373095 shl 10;
  C := 2718281828459045235360287471352;
  D := A + B * C;
  Writeln(D.ToString);

Many programming languages, for instance Java, C#, D, Python, Lisp, Perl, PHP, Ruby, Smalltalk, Visual Basic, Scala, Haskell, Kotlin, Dart, Julia, Nim, and even Windows PowerShell and JavaScript etc. have an arbitrary precision integer type. But in Delphi, there is no proper BigInteger type that

• is easy to use,
• can handle very long integers,
• is optimized for speed and precision,
• can handle different numeric bases (binary, hex, decimal, etc.) and
• can do more than basic arithmetic.

I have been thinking of using the GNU multi-precision library, but that has one big problem: it is GPL-licensed, which makes it unsuitable for my needs. So I decided to write my own, using assembler where appropriate, but also thus that pure Pascal routines would be optimal too. It works well and, as far as I know, faultless.

I initially modelled it after the .NET System.Numerics.BigInteger type, but took up influences from other languages with built-in BigIntegers, like Common Lisp, Python and Java. And yet I think I managed to make it as “Delphi-like” as possible. It is described below.

Note that I wrote this all on my own. I did not use any code from other implementations, but I did implement algorithms described in papers from, for instance, Burnikel and Ziegler, Karatsuba, etc.

Caution

{ $DEFINE PUREPASCAL}

{$IF not defined(PUREPASCAL) and defined(WIN64)}
{$DEFINE PUREPASCAL}
{$IFEND}

The BigInteger type

Unlike the integral types in Delphi, the BigInteger type uses a sign-magnitude format, i.e. the magnitude (or absolute value) is always unsigned, and the sign is an extra bit. A Delphi Integer -1000 is stored as 32-bit value of $FFFFFC18, which is called two’s complement. A BigInteger −1000 is stored as an always positive magnitude (or absolute value) of 1000 (or hex $000003E8) and a sign bit. This has some implications for bitwise operations, but more about that later.

The magnitude is stored as a dynamic array of UInt32. I, and as it turned out, also others, call such a single large digit a “limb” (a term you will see being used later on too). This is because in his book series “The Art of Computer Programming” (a.k.a. TAOCP), Donald Knuth, who describes a few base case algorithms for multiple precision math in TAOCP Volume 2, calls them so. I also like another term I have seen lately, “bigit” (biginteger digit).

BigInteger is a record type. This allows it to be used as a value type, like normal integers, i.e. there is no need to worry about the lifetime, and it also allows the use of operators like *, div, mod, +, -, and, or, xor (and some others), as well as a big number of methods.

The main thing about a BigInteger is that there is a very low chance (virtually nil) that it will overflow, since it will simply grow if more bits are needed. It can hold enormously huge integer values, theoretically — given enough memory is present — in the order of approximately 2^{4,000,000,000} or 10^{1,290,000,000}, in other words, an integer consisting of more than 1 billion digits. The total number of particles in the known universe is estimated as 10⁸⁰ or even 10⁸⁵, so a BigInteger can theoretically hold a vast multitude of that number.

Initialization

Unfortunately, there is no way to define a large integer literal like:

B := 3141592653589793238462643383279;

But yet, there are several ways to get values into a BigInteger. You can use constructors, like

A := BigInteger.Create(17);

or (implicit or explicit) conversion operators like

B := '3141592653589793238462643383279'; // string
C := -17;                               // integral type
E := BigInteger(6e30);                  // floating point type

or functions and expressions like

D := 6 * BigInteger.Pow(10, 30);        // 6 * 10^30 exactly, unlike the floating point
                                        // value 6e30 which is only an approximation.

Constructors

Although BigInteger is a record type and record constructors are no real constructors, and the syntax used can deceive you into thinking a new instance is allocated somewhere, I think records should have them, for initialization. But note that it doesn’t matter if you do:

A := BigInteger.Create(17);

Or just:

A.Create(17);

Both will do exactly the same and initialize A with the value 17.

The constructors defined are:

Byte array parameter

The bytes in the byte array are considered to be in little-endian two’s complement format. That means that if the top bit of the most significant byte is set, then the value in the bytes is interpreted as negative. Say you want to pass a value of 129. Then your array must contain two bytes: $81, $00, because a single $81 is interpreted as -127. Likewise, if you want to pass -129, you must pass $7F, $FF, because $7F is interpreted as +127.

Note that this is like in C#, which also accepts a byte array in little-endian order, but unlike in Java, which requires a big-endian byte array.

RoundingMode

The global RoundingMode property governs how a Double is converted to a BigInteger. It can have the following values.

Note that, due to the fact that floating point values can only have a limited precision, the results may not always be what you expect. A double value like 6e30 will not result in a BigInteger with an exact value of 6000000000000000000000000000000 (a 6 with 30 zeroes), because the Double is not precise enough to hold such an exact value. The result is actually 5999999999999999556357795610624, which is the conversion of the closest a Double can get to 6e30. If you want exact values, do not use floating point values as input. Use strings or functions like BigInteger.Pow instead (see below). To obtain exactly 6e30, you can use 6 * BigInteger.Pow(10, 30).

IRandom and TRandom32Proc

IRandom

I was not sure how to generate a random BigInteger. Other languages seem to use separate Random classes for this. I wanted to avoid any manual memory management for random numbers, so I declared an interface (called, you guessed it, IRandom) with a few suitable methods and two implementations, the first being TRandom, using the simple algorithm Knuth proposes and which Java seems to use (using an 48 bit seed) and the second, TDelphiRandom, which uses the built-in System.Random functions to generate random values. Both classes can be found in unit RandomNumbers.pas, included in the download. If you want to create your own, inherit from TRandom and override the virtual parameterless function Next().

TRandom32Proc

RAD Studio 10.3 Rio introduced a different concept. It lets you define your own custom pseudo-random number generators, using procedural types:

type
  TRandom32Proc = function: UInt32;
  TRandomizeProc = procedure(NewSeed: UInt64);

Random, respectively Randomize call these functions. You can supply your own implementations without having to change any code that calls these runtime functions.

If these types are not defined in System.pas, the unit defines them. The type is used by the Create(NumBits, Random) constructor to generate a random BigInteger of the desired bit size.

Implicit conversions and class functions

To get a value into a BigInteger, you don’t have to use constructors. There are implicit operators that allow you to assign several integer types directly, for instance:

var
  A, B, C: BigInteger;
begin
  A := -1;
  B := 200*1000*1000;           // My usual way to write a literal like 200,000,000
  C := -$8000000;
  D := BigInteger(Pi * 1e20);

Another way is to use functions like Pow(), e.g.

var
  A: BigInteger;
begin
  A := BigInteger.Pow(10, 85); // 10^85

The most convenient way, however, to get a well defined big number into a BigInteger is to use its string parsing capabilities, which also allow you to assign a string, like so:

var
  A, B: BigInteger;
begin
  A := '671998030559713968361666935769';
  B := '-$2940C583C5C79C8A70261FEE080A73B5B23556A5CF802BAB81DB08546F3623D5';

Numeric base

Beside parsing simple decimal numbers like the ones in the code snippet above, the parser can do a bit more. But I will first have to explain the numeric base. This is the base used for text input as well as text output of a BigInteger. I guess everyone knows decimal (base 10) numbers like 1000 or -17. But in Delphi, we know hexadecimal numbers (base 16) too, like $7F00. Some languages, like C or Java, also know octal (base 8), in the form 017 which is the same as 1*8 + 7, or decimal 15. The BigIntegers unit knows a bit more. It can have any default base from 2 to 36 (where base 36 has the “digits” 0..9 and A..Z, where A=10 and Z=35). You can set or query the default base by accessing the BigInteger.Base class property. That it is a class property means that it is the same for all BigIntegers.

The default numeric base affects input and output. So if you do:

var
  A, B: BigInteger;
begin
  BigInteger.Base := 16;
  A := '100';
  BigInteger.Base := 10;
  Writeln('A in decimal is: ', A.ToString);

The output is:

A in decimal is: 256

BigInteger knows a few shortcut methods for the most usual base values, so instead of writing

BigInteger.Base := 16;

you can write

BigInteger.Hex;

The convenience methods are:

Parsing

The methods Parse, TryParse and the implicit conversion operator (which allows you to assign a string to a BigInteger) allow for a few tricks to make it easy to enter numbers.

There are a few things to know about the strings that can be valid BigIntegers:

• To make it easier to increase the legibility of large numbers, any ‘_’ or ’ ‘, anywhere in the numeric string, will completely be ignored, so ’1_000_000_000’, ‘1 000 000 000’ and ‘1000000000’ are exactly equivalent.
• The string to be parsed is considered case insensitive, so ‘$ABC’ and ‘$abc’ represent exactly the same value.
• The number can be prefixed with a sign, either ‘+’ or ‘-’ with the usual meaning, i.e. a prefix of ‘-’ will result in a negative number, the prefix ‘+’ in a positive one. If a sign prefix is omitted, ‘+’ is assumed.

Usually, the string that is parsed is assumed to be in the base that is set with BigInteger.Base. But there are a few overrides that disregard the default base and give the number a specified base. Like in Delphi, this is done with a prefix:

I made sure that simple numbers starting with a ‘0’ are not automatically regarded as octal, like they are in C. Any of the valid prefixes starting with ‘0’ has an alphabetic second character.

An example:

procedure Test;
var
  A: BigInteger;
begin
  BigInteger.Decimal;
  A := '-%36r Rudy Velthuis'; // Yes, that's my name
  Writeln(A.ToString);
  BigInteger.Base := 36;
  Writeln(A.ToString);
  BigInteger.Base := 35;
  Writeln(A.ToString);
end;

The output is:

-3664889415200015812
-RUDYVELTHUIS
-12XJI7QCQ4S0C

Note that the three lines above represent the exact same number, but each output in a different base.

Examples of valid BigInteger strings:

Seeing 'RUDYVELTHUIS' as a valid big integer still needs some getting used to. <g>

Output

There are two simple output routines.

The second version, ToString(Base) accepts only Base values in the range 2..36.

I also implemented a few convenience methods for this:

UPDATE (7 Feb 2016)

The classic ToString(Base) method (which is still available as ToStringClassic) simply did a DivMod by 10, turned the remainder into a digit and then repeated this with the quotient until the value of the BigInteger was 0. That worked fine, but when I wanted to turn the currently largest known prime, 2^74,207,281 − 1, into a string, I thought my computer had hung up. Well, the result is a 22 million digit string, and (what is now) ToStringClassic simply repeatedly divided that huge number by 10, leaving a still huge quotient, with one digit less each time. This was, of course, even with Burnikel & Ziegler’s division algorithm, dead slow.

To improve things, I came up with a divide-and-conquer algorithm which divides the huge number by a power of ten that more or less splits it in half, and then recursively calls itself for the remainder and the quotient, so on each recursion, only half of the number has to be converted. Very small values are then converted using an optimized version of ToStringClassic. This cut the time for ToString(10) to form a 22,338,618 digit string down to approx. 150 seconds.

I really came up with this algorithm myself, although it turned out I was not the first. :-(

For what it’s worth, I also modified ToString(Base) for bases 2, 4 and 16 to take advantage of the fact that these only have to shift limb-wise, in a simple nested loop, to get the digits. The same huge number was converted using ToString(16) in – hold on, hold on… 133ms, in other words, more than 1,000 times as fast as ToString(10). This shows that base conversions can be quite slow, and that it makes sense to treat different bases differently.

I intend to do something similar for the parser, but note that this is not a priority, at the moment.

Arithmetic operators and functions

The following functions and operators are defined for arithmetic with BigIntegers:

Bitwise operators

The following bitwise operators are defined for BigIntegers. Note that these have two’s complement semantics, so before any bitwise operations are performed, the internal format is converted to two’s complement. Aftwerward, the result is converted to sign-magnitude again.

Relational operators and function

The following relational operators and functiond are defined for BigIntegers.

Conversion operators and functions

The following conversion functions perform a conversion to built-in Delphi types. If the value of the BigInteger is too large, an EConvertError is raised.

The following implicit conversion operators (the conversions generally do not require a cast) perform a conversion from built-in Delphi types to a BigInteger.

The following explicit conversion operators, (conversions requiring a cast) from BigInteger to built-in Delphi types do not raise exceptions, but truncate or sign extend the values to make them fit, just like Delphi does.

Conversion to bytes

The individual bytes in the array returned by the following method appear in little-endian order.

Negative values are written to the array using two’s complement representation in the most compact form possible. For example, -1 is represented as a single byte whose value is $FF instead of as an array with multiple elements, such as $FF, $FF or $FF, $FF, $FF, $FF.

Because two’s complement representation always interprets the highest-order bit of the last byte in the array (the byte at position High(Array)) as the sign bit, the method returns a byte array with an extra element whose value is zero to disambiguate positive values that could otherwise be interpreted as having their sign bits set. For example, the value 120 or $78 is represented as a single-byte array: $78. However, 129, or $81, is represented as a two-byte array: $81, $00. Something similar applies to negative values: -179 (or -$B3) must be represented as $4D, $FF.

You can, inversely, convert such a byte array to a BigInteger again, using the already mentioned:

Mathematical methods

The following mathematical methods are implemented:

Bit fiddling

The following methods to do bit fiddling are implemented. They follow two’s complement semantics, so a value of, say, -$1234000 is regarded as $EDCC0000 and bits are accessed accordingly. You can access bits past the current size of the BigInteger. The BigInteger is expanded if that is necessary to contain the new value.

For what it’s worth: for negative values, these methods can be slow (because of the need to turn the internal sign-magnitude format into two’s complement) and thus are not fit for the implementation of bit sets and the like.

var
  Q1, Q2: BigInteger;
begin
  Q1 := '-$12';

  Q2 := Q1.SetBit(100000);

The following functions also provide information about the bits of a BigInteger:

Properties

The following properties are defined by a BigInteger. Apart from the last one, Base, they are all instance properties describing the BigInteger.

Conditional defines

The following conditional defines can be used. Note that some are off by default. This is reflected in the source file, e.g. the conditional PUREPASCAL is easily turned off by turning

{$DEFINE PUREPASCAL}

into a mere comment:

{ $DEFINE PUREPASCAL}

  {$IFDEF Experimental}
    // ... the new, experimental code
  {$ELSE !Experimental}
    // ... the working original code
  {$ENDIF !Experimental}

Internal format

The internal format of a BigInteger is quite simple. It consists of two private data members (fields). They should only be manipulated indirectly, using the various methods and operators defined for the BigInteger. Of course you can access them using a trick, but it is not recommended.

Note that FSize is not two’s complement either. The lower bits are unsigned, and the sign bit has no relation to them. So negating a BigInteger is as simple as flipping the top bit of FSize.

In the above, the term “limb” is used a few times. A TLimb is one of the elements of the array that forms the magnitude of the BigInteger. It is declared as:

type
  PLimb = ^TLimb;
  TLimb = type UInt32;

Even in 64-bit Windows, I decided to use the same 32-bit limbs. This makes some 64-bit code a lot easier, and probably not slower.

Speed

For Windows, most of the time critical routines are implemented in 32-bit or 64-bit built-in assembler. For other platforms, or if the PUREPASCAL conditional is defined, they are completely implemented in plain Object Pascal. I optimized the routines as much as I could, sometimes with the help of the good people on StackOverflow.com (see sources).

Optimizations

Many of the routines use unrolled loops and other small-scale optimizations, not only in assembler, but also in PUREPASCAL. Most of the 64 bit assembler processes 64 bit (i.e. 2 limbs) at once. If this made sense, 64 bit variables were used. Just read the source code and see for yourself.

After a lot of reading and testing I was able to implement higher level, divide-and-conquer algorithms for faster operations (see, for example, this pdf and this website as well). As the Wikipedia article says: A divide and conquer algorithm works by recursively breaking down a problem into two or more sub-problems of the same (or related) type (divide), until these become simple enough to be solved directly (conquer).

Karatsuba and Toom-Cook 3-way

For faster multiplication, recursive algorithms described by Anatolii Alexeevitch Karatsuba and by Andrei Toom and Stephen Cook (the 3-way algorithm) were implemented.

These are much more complicated than simple base case multiplication, but also asymptotically faster. However, due to the overhead in these functions, they are only faster if the sizes of the BigIntegers are above certain thresholds. That is why multiplication only uses Karatsuba when both sizes are above BigInteger.KaratsubaThreshold and it uses Toom-Cook 3-way when the size of one of both operands is above BigInteger.ToomCook3Threshold. These thresholds differ for 32-bit and 64-bit, as well as for PUREPASCAL or assembler-based code.

Usually, the Multiply() function will decide which algorithm is used, but I also made functions MultiplyBaseCase (normal “schoolbook” multiplication), MultiplyKaratsuba and MultiplyToomCook3 public, if you have a special reason to use one of these. Note that MultiplyToomCook falls back to Karatsuba, and MultiplyKaratsuba falls back to base case if the operands do not meet the threshold criteria.

Because of the recursion, both algorithms are much faster than normal “schoolbook” multiplication. I measure a speed increase of almost 10 for BigIntegers with more than 6,400 limbs (a limb is the basic building block of BigInteger, a 32 bit unsigned integer), i.e. more than 61,000 decimal digits.

There are faster, even more complicated algorithms, e.g. the FFT-based Schönhage-Strassen algorithm for very large BigIntegers. I did not implement any of those yet.

Burnikel-Ziegler

For faster division (and modulus), I implemented the divide-and-conquer algorithm described by Christoph Burnikel and Joachim Ziegler. The speed of this is more or less limited by the speed of multiplication. It mainly consists of two routines, DivTwoDigitsByOne and DivThreeHalvesByTwo, which call each other recursively until sizes get below a certain threshold. Then normal base case (“Knuth”) division is used. The paper linked to explains the algorithm quite nicely, without much ado. It is quite a bit faster than normal “Knuth” division, especially for very large values.

There are faster algorithms, e.g. the Barrett algorithm or Montgomery reduction for extremely large BigIntegers, but I did not implement any of those yet.

Allocation

As described above, if the RESETSIZE conditional is defined, the internal Compact procedure will shrink the size of the allocated array if Size becomes less than half the allocated size (Length) of the FData array. Such a reallocation can negatively affect performance, so by default, the conditional is not defined, and FData is never shrunk. But this does not mean that eventually, you will get an enormous amount of memory leaks. FData is a normal dynamic array, so if the last reference to it is lost, it will be freed entirely.

Copy-on-write (COW)

The methods and operators of BigInteger follow the COW principle. This means that if you just assign one BigInteger to another, only a shallow copy is made. The FData pointer is copied and its reference count is updated, but the entire contents of the FData are not copied. Because of this, several BigIntegers with the same value can share one FData array. Only if one of these BigIntegers is about to be modified, a new copy of the data for that BigInteger is made, while the others can still reference the original FData.

An example:

var
  A, B, C, D: BigInteger;
begin
  A := 17;      // A gets new FData array with contents 17
  B := A;       // B.FData points to same array as A.FData
  C := B;       // C.FData points to same array as B.FData and A.FData
  B := A + 1;	// B gets new array, but A and C still reference array with value 17.
  ...

Note that, despite of the above, most of the time, BigIntegers should and can be treated as immutable, i.e. most methods or operators operating on BigIntegers return a new one, instead of changing the value of one of the operands. Even a function like SetBit does not modify the BigInteger on which it is called. It returns a new one with the given bit set. Only some self-referential instance methods modify the value of Self and Inc and Dec modify the value of the operand.

Partial-flags stall problems

This is a problem that caused me some headaches before I could solve it. I noticed that on some CPUs, against all expectations, the PUREPASCAL routines were faster than the assembler routines. This turned out to be due to a partial-flags stall.

In assembler, on some “older” CPUs, certain loop code combining the opcodes INC and/or DEC with ADC and/or SBB or other instructions reading the carry flag, can cause a considerate slowdown (up to 3 times as slow), because of a so called partial-flags stall, which happens when instructions like INC or DEC write only some of the flags, while other instructions (e.g. ADC and SBB) read other flags.

I coded routines (using LEA and JECXZ/JRCXZ instead of INC/DEC/JNE) that avoid that problem, but on CPUs that do not have the problem, these modified routines are a bit slower than the “plain” routines. So now, at startup, the unit determines, with a few timing loops, which of the routines it should use: the plain ones or the modified ones. So, on CPUs that are not affected, plain code using INC/DEC/JNE is used. That is faster than the modified procedures. But on older, affected CPUs, modified code using LEA/JECXZ is used. On these CPUs, the modified code is much faster than the plain code. At the moment, only code for addition and subtration is different. The problem does not occur in other routines, probably because in these routines another instruction (e.g. ADD or CMP) will set the full flags register before it is read.

But every now and then, due to unexpected events happening that mess up the timing, the decision taken by the unit can be wrong, or you may have other reasons to choose one implementation over the other. For that, you can use:

BigInteger.AvoidPartialFlagsStall(True); // True to make BigInteger use modified routines,
                                         // False to make it use plain ones.
                                         // Omit routine to keep the setting the unit
                                         // measured.

Whether plain or modified routines are used can be queried from the property:

If you know a better way to determine the affected CPUs than the simple timing loops I am using, please send me a note.

Bitwise operators and negative values

As I explained already, bitwise operators like and, or and xor use two’s complement semantics. This means that before the operations on the values are performed, they are converted from the usual sign-magnitude to two’s complement. For positive values, that means that nothing has to be done, but negative values must be negated completely. I found ways to get around that, partially. People on StackOverflow helped me, as well as the many bitwise tricks mentioned in Hacker’s Delight.

Visualizer

All the time when working, to find the numeric value of a BigInteger, let’s call it X, in the debugger, I had to either add a watch entry with X.ToString, or I had to run a little piece of code. So I decided to write a debugger visualizer for it. Here you can see it in action:

Here value A, which was initialized with the string above it, is displayed in the tooltip.

The visualizer package currently comes in source format, which you only have to install in the IDE (click Install in the context menu in the Project Manager). Make sure that the BigNumbers.dpk package was built first and that the visualizer package references its .dcp file. I intend to write an installer for this, but please don’t hurry me, as this is not something I have done before.

Currently, the code on GitHub contains three projects.

• BigNumbers.dproj is a package with Velthuis.BigInteger, Velthuis.BigDecimal and some other units, which is required by (and must be installed before) the second package:
• BigNumVisualizers.dproj is a package expert, which can be loaded into the IDE and then installed (e.g. from the context menu of the IDE’s Project Manager).
• BigNumberVisualizers.dproj is a DLL expert, which must be installed using the registry.

FreePascal

In {$mode delphi}, it is possible to compile the units. FreePascal doesn’t seem to use segmented unit names (yet), so you’ll have to rename some of the used units and qualifiers like System.Math or System.SysUtils to simply Math or SysUtils. At first, you’ll have to {$DEFINE PUREPASCAL}, because making the assembler work satisfactorily could be quite a job. It seems to work alright, if you set {$asmmode intel}, but it is a little finicky. Stuff like LEA EAX,[EDX + EDI*CLimbSize] seems to cause problems, but [EDX + CLimbSize*EDI] works. That is a bit of a problem for me, because I most of the time use the former variety. But I guess that, with enough time on your hands, you can make it work.

Some of the tricky routines, e.g. ToString, which uses RecursiveToString, which in its turn needs an exact alignment of bytes to get a usable string, don’t work, but in the meantime — until you solved the problem — you can e.g. use (or wrap or rename) .ToStringClassic(10) instead. I guess the tricky routines just need some work and some debugging to make them work under FreePascal. I only tried a quick and dirty test, did not do any extensive tests, but it is obviously possible to make it work. Just don’t give up immediately.

Types like TArray don’t seem to work. And there is no way you can define an array of BigInteger before BigInteger is defined, so you will have to define a type BigIntegerArray = array of BigInteger inside the BigInteger record, as a nested type. You will meet other, similar problems. Another was the fact that there is no DivMod() function for UInt64 types, so you will have to either use the one for Longint or use div and mod separately. It could be that the change I made there is one of the causes for the failure of RecursiveToString. This needs some investigation.

There will be other, simple problems and it is well possible that there are a few not-so-simple problems. But it looks as if BigIntegers can be used in FreePascal.

Good luck!

Conclusion

I hope this code is useful to you. If you use some of it, please credit me. If you modify or improve the unit, please send me the modifications at this e-mail address.

I may improve or enhance the unit myself, and I will try to post changes here. But this is not a promise. Please don’t request features.

Rudy Velthuis