Heterodyne

Frequency modulation (FM) is one of the techniques used to transmit audio signals at radio frequencies. If we "multiply" a sinusoidal signal wave with a sinusoidal carrier wave, the result is two waves at frequencies just above and just below the original carrier.

By way of an example let's try and transmit a 440 Hz tone using a 10 kHz carrier.

\(signal(t) * carrier(t) = mixed(t)\)

The mixed result will then be the superposition of a 10,000 Hz - 440 Hz and a 10,000 Hz + 440 Hz wave.



We can un-mix the mixed wave by applying the same function to our pair of tones at 9,560 Hz and 10,440 Hz; doing so will create another pair of tones: one for each input. Two of those tones will be very high frequency and almost inaudible; the other two will be centered around 0 Hz. Originally, the tone at 9,560 Hz would be a kind of "mirror image" of our original tone (though this distinction isn't readily apparent for a single frequency), but after the second multiplication, it's now the "mirror image of a mirror image" so it's the right way around. The tone that was at 10,440 Hz when modulated will now be at -440 Hz and inaudible.

As a second example, let's say the signal is an audio file containing many frequencies between 20 Hz and 20 kHz. We know from the superposition property of waves that we can decompose our song into 19,980 different signals (yes, there will be some rounding errors if we only allow integer values, but hear me out). And let's chose a slightly higher frequency carrier of 100 kHz. Our lowest frequency of 20 Hz will now be mixed to 99,980 Hz and 100,020 Hz while our highest frequency will be mixed to 80,000 Hz and 120,000 Hz. The signal frequencies in between the lowest and highest will then fall into the two bands when mixed. One band will appear to have the "mirror image" of our original signal: that is to say the higher signal frequencies will now occupy lower mixed frequencies and the lower signal frequencies will now occupy higher mixed frequencies. The other band will contain the same information as the signal but simply shifted to a higher base frequency.

Binary vs Decimal, Part 2

Microsoft's .NET framework gives developers options for representing floating point numbers as well as integers. The same is true of Microsoft's SQL Server, though the options differ subtly.

Remembering from my earlier post that we can convert between base 10 (decimal) and base 2 (binary) integers with no loss of information, it shouldn't surprise you that .NET and SQL Server offer similar integer types with varying number of bits. Even though we're storing numbers that we entered as a sequence of digits (i.e. literals) in C# source or SQL script, they are converted into base 2 integers. However, this post is not about integers.

If, instead of integers, we wish to store fractions (e.g. negative powers of our chosen bases) we must ask a few questions, the first being:

Are we trying to represent a fractional number that has a base 10 representation? If so, we already know that the conversion from base 10 to base 2 cannot necessarily be done without losing information. We can very easily represent the decimal number 0.625 in binary because it's simply the sum of 0.500 (or 2^-1) and 0.125 (or 2^-3), but we cannot exactly represent the decimal number 0.99 because the number of base 2 powers required to add up to 0.99 would quickly exceed our chosen precision (the number of bits available to represent the number.) Instead, if wanted to store our decimal number in a binary field with a fixed number of bits, we would need to approximate the decimal.

0.989999949932098388671875
0.9900000095367431640625
0.990000069141387939453125

The three numbers above are actually sums of powers of 2 and can be stored in a 24 bit binary field without losing information^[1]. Notice that the middle number is closest to 0.99.

But what if we wanted to represent the price of our chocolate: 34.99? In order to fit into a field of the same width we would need to adjust the largest exponent and make a corresponding adjustment to
smallest exponent. Our closest "sum of powers of 2" approximation might be:

34.990001678466796875

In binary this same number would look like

100010.111111010111000011

25	24	23	22	21	20	2-1	2-2	2-3	2-4	2-5	2-6	2-7	2-8	2-9	2-10	2-11	2-12	2-13	2-14	2-15	2-16	2-17	2-18
1	0	0	0	1	0	1	1	1	1	1	1	0	1	0	1	1	1	0	0	0	0	1	1

We're ready to ask ourselves the second question: can our application tolerate the approximation in converting from base 10 to base 2? In applications where the inputs, intermediate values and outputs are not exact numbers to start with, (e.g. in the fields of science and statistics, to name a few) the answer is probably yes, but certain applications with exact inputs (e.g. in the field of finance) might strictly require us not to approximate the values. The next section presents a way to circumvent the approximation.

In this series' first post, we learned that we can convert numbers between all bases without loss of information, but only when the lowest power for both bases is b^0 or 1. Some smart engineers realised that if we pre-scale our number by some chosen scale so that it becomes an integer, then we can post-scale it when we're done operating on it. Going back to our example number of 0.99, we could pre-scale it by 10^2 (or 100) giving us 99, which converts exactly into the binary number 0110 0011. Now we're able to store the exact value in 7 bits when previously we could only store the approximation in 24 bits.

At this point SQL Server and .NET diverge:

SQL Server offers the DECIMAL data type, which has a fixed precision and scale. In other words, when you define a value of this type you explicitly provide the precision and scale (e.g. DECIMAL(26, 2). If we wanted to store the number 31.42 in this field, SQL Server would pre-scale it by 10^2, convert the number 3142 to binary, and store the binary representation.

.NET, on the other hand, offers the System.Decimal struct type which is a floating point number. The scale that's chosen to pre-scale any given decimal number is packed and stored along with the binary integer representation, and can be accessed to post-scale the integer back into a fraction when needed. The struct is 128 bits wide, and stores the integer part in 96 of those bits. 2^96 is approximately 7.92282E+28. We can create a System.Decimal with anywhere between 0 and 27 (or 28) digits and we choose where the floating decimal point will go.

It might be worth emphasizing that SQL Server's DECIMAL is not floating point. The distinction between fixed and floating point is probably best made by looking at where the scale value is stored.

Converting between SQL Server's DECIMAL and .NET's System.Decimal can take a little forethought.

[1] https://www.h-schmidt.net/FloatConverter/IEEE754.html
[2] https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql

Binary vs Decimal, Part 1

We commonly represent numbers in base 10, or decimal. The number three thousand, one hundred and forty-two, for example, can then be represented by the composite symbol 3142.

Power	103	102	101	100
Digit	3	1	4	2
Product	3000	100	40	2

The arithmetical sum of products (of powers and digits) gives us back our number: 3142.

Computers represent numbers in base 2, or binary. The same number three thousand, one hundred and forty-two has a binary representation of 1100 0100 0110 (I added some spaces to make the long sequence of bits easier to process visually.)

Power	211	210	29	28	27	26	25	24	23	22	21	20
Bit	1	1	0	0	0	1	0	0	0	1	1	0
Product	2048	1024	0	0	0	64	0	0	0	4	2	0

Again, the arithmetical sum of products (of powers and bits) gives us back our number: 3142.

Notice the similarity of the mechanical operations between the two tables above: a pattern (or algorithm) should emerge. Once it does, you may continue reading.

With representations like these, it's instructive to notice that we can represent any number that is a multiple of the rightmost power, up to a maximum that is determined by the leftmost power. Once we choose (fix) the rightmost and leftmost power, we restrict our representation to only those real numbers that can be represented subject to those constraints.

Consider a real world example: the price of a bar of chocolate at your local grocery store is R 34.99. If the shop has one of those electronic price displays on the shelf, that display is likely to be physically limited to displaying only 6 digits.

To enable us to represent any number that is a multiple of 1 cent (R 0.01) we must set the rightmost exponent to -2. Consequently, because we also defined the number of digits as 6, we are also constrained to represent numbers less than or equal to 9999.99. So, we can encode any number from 0.01 to 9999.99 inclusive, but we cannot encode smaller numbers (such as 0.001) or larger numbers (such as 10000.00) as they exceed our chosen constraints.

Power	103	102	101	100	10-1	10-2
Digit	0	0	3	4	9	9
Product	0	0	30	4	0.9	0.09

Once we restrict our representations to a limited number of digits (in the case of decimal) or bits (in the case of binary) we essentially restrict the set of numbers that we can represent. Remember: every number must be some multiple of the rightmost power. It's not coincidental that I chose an exponent of 0 for the first two examples; b⁰ is always 1 whatever base b is. That has the consequence that we can represent all integers in both decimal and binary (as long as we increase the number of digits or bits sufficiently.) As long as our smallest representable value is common to both schemes, we can represent the same numbers in each of them. If the following equation holds true then we can convert between two schemes d and b, with integer exponents m and n respectively, without loss of information:

\({d}^{m} = {b}^{n}\)

When d is 10 and b is 2 the only solution is where m and n are both zero. We can only convert integers (i.e. multiples of b⁰, or 1) between base 10 and base 2 without losing information.

If we chose a different pair of bases 16 (hexadecimal) and 2 (binary, again) then we see an additional repeating solution each time the larger base power is an integer multiple of the smaller base power, but we still wouldn't be able to represent the other powers of 2.

Base 16			...	161	160	16-1	16-2	...
Base 2	24	23	22	21	20	2-1	2-2	2-3	2-4	2-5	2-6	2-7	2-8

Multiples of

16

1

0.0625

0.00390625