My Galileo Module – Part 2

Welcome to the second part of my Galileo Module started there.

Please note that this post is a little technical. If you are not technically inclined, you could easily skip it.

Technical considerations on the precision of numbers

You can download the spreadsheet for this part here.

The world continuum

The world appears to be a continuous environment. Indeed, movements are smooth and don’t look like old animations like this one from an Iranian vase which is 4000 years old:

Similarly, light, sound, all seem to have a totally continuous space. Nobody knows for sure if everything is indeed continuous or if the “building blocks” are so small in both time and space that we cannot get to the level of precision needed to see them.

The discrete nature of computers

In the computer world, however, nothing is continuous. In time, everything depends on the “clock” of the microprocessor which can be thought as “beeps” at regular intervals. Similarly, in space, everything is coded as bits, pixels, etc. Nothing is continuous in the computer world, everything is “discrete”.

Computers use “bits” to store numbers. The less bits are used to store a number, the lower the precision of that number and/or the shorter range you can represent. With 8 bits, you can represent integers from 0 to 255, while with 16 bits, the range goes from 0 to 65535. But you could also choose to represent decimal numbers using 3 decimal digits from 0 to 65.535 with the same 16 bits. So the more decimal digits are used and the bigger the range we want to cover, the more bits are needed, which means more storage is used as well as we store the full history of all financial transactions.

We can make the parallel with the 3D industry. Depending on the precision of your “mesh”, 3D objects look smooth or horribly rough:

But if it is so, why don’t we use always smooth visuals? Because the first image is computed is mere milliseconds while the last one takes 10 minutes to build as well as much more memory. So there is a trade-off between time/space spent for calculations and how smooth we want things to appear.

In the music editing industry, the same kind of dilemma applies. All music is encoded in numbers that are stored in bits. If the data to be stored exceeds the capacity of the bits because the music’s volume was too high during the recording for instance, we experience what is called “clipping” which sounds pretty horrible and looks like this:

Consequences on UDs stored digitally

In a blockchain, all transactions are stored in a computer system. However, storage space costs energy, resources and money, it is important to minimize storage space. As transactions use a lot of numbers, it is worth investigating how much space we should use to store a number.

Using Integers

Let’s imagine that we wish to simply use integers to avoid storage costs. If we start with small numbers, we will have some “clipping” effects where we have to round numbers. The first problem we may face is that by rounding too much, we may not even be able to compute a UD that is greater than 0, for instance 3 × 0.1 = 0.3 which is rounded to 0:

Okay, let’s use some higher numbers:

We observe that for many years, the UD doesn’t change and remains at 1. The corresponding chart shows that the money mass doesn’t grow smoothly, its acceleration jumps when we switch from one integer to the next:

But it actually gets much worse than this. When we look at the relative scale, everything is expressed using the UD itself, which is rounded, so the curve is taking a very ugly form every time we switch from one UD to the next:

Decimals

Undoubtedly, using integers may be quite a bad idea. But it is mostly a bad idea because nobody wants to pay their bread 5.000 units of something. So let’s go on and use decimal numbers.

Let’s at least store a decimal digit:

It is better, but still not so great. Let’s try one more digit:

This is definitely better and quite acceptable.

Number of decimal digits

It is thus advisable to use floating point numbers with sufficient digits to compute the UD otherwise we may experience some “clipping effects” such as these. This effect diminishes as we advance towards greater numbers, but then the question of the possible range for our integers arises. If we have selected 16 bits to store integer values, the bad news is that, even if starting with very small values as above and with a population of only 3 individuals, the total money mass reaches 67.410 after 86 years, which will make it impossible to continue storing transactions at that time. Of course, a currency for only 3 people is pretty useless. We should consider for instance 3000 people instead which is a more likely and yet still timid scenario. Even then, we reach the same threshold after only 1 year and a month, and the more participants the quicker the limit is reached.

Moving the floating point

At some point, it is necessary to use a mechanism to move the floating point over time. Indeed, as time goes by, it becomes impossible to store exponentially growing values. Of course, we could grow the number of storage bits over time as well, which would be a rather bad idea! Instead, it is much more simple to move the decimal point which changes the base for counting in steps of 10^x. We only need to store the current “base” to know in which base a specific number is expressed into.

Distributing the UD over time

So far, we have considered that the UD is created every year. But it is actually best to create is as often as possible, to smoothen the inequalities over time. If we distribute the UD every year on Jan 1^st, it is clear that if someone enters the economic zone on Dec 31^st, he has an advantage compared to someone who enters on Jan 2^nd.

Theoretically, the UD would be created (or distributed) over time continuously at every millisecond, actually every nanosecond or femtosecond. Unfortunately, that is practically impossible as computers are machines that don’t operate continuously and require more energy to perform more calculations. We need to find a compromise between computer calculations vs generated inequalities. It could be created every hour, every day or even every week, whatever seems “acceptable” to the community using the currency.

This has some effects on the currency itself as every UD generation causes the number of monetary units to grow which causes a gap in the value of each unit (more units mean less value for one unit).

Updating the UD over time

Another reason for the clipping may also be that the UD will not be revised every microsecond, and not even every time the UD is distributed, as it is a costly operation. Currently in the Ğ1 currency it is only revised every 6 months while it is distributed every day.

Firstly, if there aren’t enough significant digits, then we might have a clipping effect every 6 months or more due to the revision of the UD, which is quite bad. Then, every time the UD is revised, it causes a “jump” in the relative scale of prices.

Let’s have a look at what happens if we revise the UD every 2 years instead of 6 months over a period of 40 years:

Have you noticed how the sawtooth effect is felt much more by the ones who own more money than the ones who own less? By the way, they don’t exactly experience minor changes on their accounts: the values suddenly drop by almost one third (exactly 28% in this case). This means that if people were to adjust prices, salaries and everything on the new DU, all prices would drop by 28% which is not acceptable for something that has only a purely technical cause that can be fixed.

To fix this further, we can revise the UD every 6 months:

Obviously, the sawtooth effect is still there, but on a much limited scale (4%) which seems proportionally more acceptable. However, we could probably consider revising the UD more frequently to avoid such a sawtooth effect.

Next is Part 3.