Catching Raindrops

Suppose we know the area of a country and the average annual rainfall. And then suppose that we also know the population and the daily water consumption, then we can work out what proportion of drops of rain that fall need to be captured for use by people.
We convert the daily consuption to annual and then compare the volume of water that is consumed with the volume of water that falls as rain.

Inputs
Population		people
Average Water Consumption		litres per person per day
Land Area		square kilometers
Rainfall		meters per year
Result
Proportion of raindrops to catch		%

(If you change one of the inputs above and hit enter, then the result will be updated.)

Singapore has approximately a population of 5.9 million people, they use 141 litres of water per person per day. The land area is small: 729 sq km, their annual rainfall is about 2.2 meters. So if they captured 19% of the raindrops then they'd meet their water needs.
On the other hand, Ireland has a slightly smaller population but much larger land area and so they only need capture a much lower proportion of their raindrops.

Pumped Storage Power Calculations

Suppose a country had some good sources of intermittent renewable energy, perhaps tidal which is nice and predicatable or wind which is much less foreseable. Either way, one approach to achieve a consistant supply would be to store the energy produced and then release it on demand. A pumped storage power station may be appropriate. It consists of pairs of lakes which are relatively close by eachother, though there is a significant altitude difference between the lakes. One or both of the lakes may be man-made. When there is excess supply of electricity, water is pumped from the low lake to the high lake. On the other hand, when there is excess demand, water flows from the high lake to the low lake, passing through a generator and so it produces electricity.

Now, let's look into how much energy could be stored.
The potential energy stored is Mgh:
where g is the acceleration due to gravity.
h is the height of the high lake above the low lake.
M is the mass of water, which is evaluated by multiplying the volume of one lake times the density of fresh water (1,000 kg per cubic meter).
We'll also introduce an efficiency factor because the system won't be perfectly efficient.

Inputs
Population		people
Average Power Per Person		Watts
Lake Radius (r)		meters
Lake Depth (d)		meters
Altitude Difference (h)		meters
Efficiency		%
Number of Lake Pairs
Results
Annual Energy Consumption		TW hours / year
Energy Stored		TW hours
Days of Energy Stored		days.

(If you change one of the inputs above and hit enter, then the results will be updated.)

If we were to use tidal power, which goes through almost 2 complete cycles per day, then we may need about half a day's worth of demand to be stored, which may be achievable with a series of pumped storage power stations. On the other hand, if we were to try to rely on wind as the sole energy source and we wanted to store enough energy to see us through say six weeks of calm weather, then the number of pumped storage power stations required is likely to be unacceptably large.

Now suppose we choose to harness tidal power. One approach would be to put a sea-wall across the entrance to some bays or inlets. Let the water flow in as the tide rises. The sea water is then blocked as the tide starts to ebb. To extract a maximum amount of energy from this, we would wait until the tide at its lowest point and then instantaneously release all the sea water, passing it through a generator. But it is likely to be much more practical to release the water before low-tide. Also if we want to use much of the electricity as it is being used, then we would want the generation of electricity to continue through much of the tidal cycle.

We can set a target of what proportion of our energy needs we want to come from tidal and then we can work out what area of the sea needs to be put behind sea walls with tidal generators.
In a 27 day lunar cycle we have 2 tides per day due to the spin of the earth, less 2 tides due to orbit of the moon. For now we won't go into the details of why that's true. But our statement here is that we have 2 * ( 27 - 1 ) tides in 27 days, i.e. 1.93 tides per day. So a tidal cycle is (24 / 1.93) hours = 12.44 hours. But we can generate power both as the tide flows in and as the tide flows out. So we'll use the half tidal period which is a little over 6 hours.

The target amount of energy to generate in a half tidal cycle is:
population * powerPerPerson * durationOfHalfTidalCycle * targetTidalPowerProportion.
On the other hand we see how much energy is available from the tidal movement using the equation:
Potential Energy: E= Mgh
In this case M is the mass of the sea water which is the area times the tidal height times the density of sea water (approximately 1030 kg per cubic meter).

So we can evaluate the area of sea that is required:

Inputs
Tidal Height		meters
Tidal Power Efficiency		%
Proportion of Total Energy from Tidal		%
Result
Sea Area Required		square KM

(Once again, if you change the inputs and hit enter, then the result will update.)

Tidal power is something that can provide predictable renewable energy. However, a significan area of sea needs to be harnessed.

Sha256 Hashing Algorithm as a Directed Graph

The quick and easy part of bitcoin mining is checking the digital signatures of those spending their coins and then confirming that there hasn't been a double spend. Then comes the slow part. Miners guess a value for a number known as a nuance and then take the (Sha256) Hash of the verified transactions and the nuance. If the result is less than the currently specified threshold, then the miner can announce his block to the community. The vast majority of the nuances guessed lead to a hash that is greater than then threshold and so are rejected.
Miners seek a number called a nuance such that
\[Hash( transactions, nuance) < threshold \]
When the nuance is found, it represents proof that the mining community has done a lot of work. This approach is known as a proof of work algorithm.
Well, suppose someone were to invert the Hash function, they would start with say (threshold - 1) and then work out the nuance that would achieve that. So they could mine bitcoin without doing the work. Bitcoin would be unable to continue using the proof of work algorithm and would very likely collapse. For bitcoin to survive it is important that no one known has to invert the hash function.
The Hash function that bitcoin uses is called Sha256. (For details look at the wikipedia article). For the rest of this blog post, I'm going to focus on the part of the algorithm where we start with 512 bits, they are processed through 16 preliminary iterations and then a further 48 standard iterations, at the end of which we have 256 output bits. The algorithm has the following attributes:

• It is not a secret, anyone who wants can look at the code or indeed write their own code to implement it.
• It is completely deterministic and repeatable. It gives the same answer every time.
• There are no 'if' statements.

One of the operations carried out is integer addition. The inputs are put into groups of 32 bits and then the 32 bits are treated as an integer. Pairs of integers are added. If we go down a level from the integer to the bits that make it up, we can implement the integer addition using the AND operator and an XOR operator on pairs of bits.
The rest of the algorithm can be implemented using:
NOT operator, which takes one bit as an input and has one output bit.
XOR operator, which takes two bits as input and has one output bit.
AND operator, which takes two bits as input and has one output bit.
So the entire algorithm can be represented as a directed graph going from the 512 input nodes to the 256 output nodes. Every node represents one bit. The inputs bits are set and then after that every other node is assigned a value of either 0 or 1. A node is assigned a value just once.
If a NOT operator was used to assign the value, then it has one precedent.
On the other hand if an AND or XOR operator is used then it will have 2 precedents.
However nodes can have any number of dependents. The graph is strictly directed. There are no circular loops.

So now we might ask the question: how might someone invert this algorithm. Suppose the output was fixed or indeed constrained, how could we find appropriate inputs?
Well, lets start with the NOT operator.

Input A	NOT A
1	0
0	1

This is very straight forward to invert. Indeed if you apply the NOT operator to the output, then you'll recover the input.

Now lets move on to the XOR operator. It is also known as the 'exclusive or'. A XOR B is A or B but not both.

Input A	Input B	A XOR B
1	1	0
1	0	1
0	1	1
0	0	0

Suppose: A XOR B = 0
that means that A and B are the same. They could both be 1 or both be 0. We just know that they are not different. So if we are traversing our graph from the outputs to the intputs, (i.e. from right to left in the image above) then A XOR B = 0 imposes the simple relationship between A and B that A=B.
On the other hand: A XOR B = 1
tells us that A and B are different. So if we go from right to left across our graph then that condition needs to be maintained.
So the XOR output will tell us if the inputs are the same or different.

The final operator we need to deal with is the AND operator.

Input A	Input B	A AND B
1	1	1
1	0	0
0	1	0
0	0	0

When A AND B = 1,
that implies that both A and B are 1 and so if we have that condition, then we can take a step back through the graph and set the two inputs to 1.
A more difficult case to deal with is: A AND B = 0
In that case either A or B could be 1, but not at the same time.
So that relationship between A and B is (a little bit) complicated.
The Sha256 algorithm consists of 64 iterations ( 16 preliminary, followed by 48 standard). However on each iteration the bits pass through numerous NOT, XOR and AND operators. In my implemenetation in Java (which is available in github) I had:
NOT operator called 117,248 times.
XOR operator called 58,880 times.
AND operator called 106,240 times.
There are a number of ways those numbers could be reduced. For example we could use an OR operator. But if someone was trying to come up with an algorithm to invert the Sha256, then introducing new operators may make it more complicated. Indeed we could replace the XOR with 5 calls to an AND so then we just have lots of AND's and NOT's to invert.
To successfully invert the Sha256, the run time should not grow exponentially with the number of operators N. Something linear in N would be great. Something quadratic in N may be doable.

One method that might be tried would be a probabilistic approach, assigning each node a value between 0 and 1 (inclusive).
For example if we had: A AND B = 0
then we might set A =1/3 and B=1/3.
Reflecting the fact that they are both more likely to be zero than 1.
We could attempt to traverse the graph from right to left and back again a number of times until we had a stable solution. Perhaps a simulated anealing method could be tried. But the problem is that the values in the graph are not stable. One flipped input bit has a huge cascade effect through the graph. It would be very difficult to get a probabalistic method to work because of that instability.

A very different way of trying to reverse it would be to bring the constraints on the nodes through the graph from the outputs back to the inputs. For example if an output needs to be 0 and it is assigned using an AND operator then we know that the two inputs cannot both be 1. We could then pass that constraint back to their precedents.
However in this case if we are not clever then the constraints would grow exponentially as we go back through the graph. If a node has some contraints, then they are passed on to its two precedents, in many cases each of which will have 2 precedents, which in turn may have 2 precedents. Typically to pass from the outputs to the inputs, bits need to pass through 200 AND operators. \(2^{200}\) is a very big number. Someone would need to be very smart in how they compress the constraints to prevent the exponential explosion.

If we observe the Sha256 calculator as it goes from the input to the outputs we find we just need 512 currently live nodes (bits). After a while the inputs are no longer needed. Later, after the intermediate nodes are used, they too are no longer needed. 512 is a comparatively small number. Similarly, someone going back through the graph (from the outputs to the inputs) just needs to keep track of 512 bits at any given point in time. That's not a lot of memory. How difficult could it be to invert the Sha256?
Well, so far no-one has been able to work out how to do it...

False positives and false negatives

When testing for the presence of a disease, the results obtained are often not 100% reliable. In this article we explain false positives and false negatives in test results. The graphics are dynamic, if you change the input numbers, then they'll update.
Let's start with the prevalence of disease, this is the proportion of positive cases in the population.
Disease prevalence input: %


Light red shows the proportion of the population that have the disease, i.e. are positive.
Light blue shows the proportion of the population that don't have the disease, i.e. are negative.


The false negative rate is the proportion of the positive cases that are incorrectly deemed to be negative.
False negative input: %


Dull red shows the true positives: the proportion of the population that are positive and get positive test results.
Orange shows the false negatives: the population that are positive but get negative test results.


The false positive rate is the proportion of the negative cases that are incorrectly deemed to be positive.
False positive input: %


Yellow shows the false positives: the population that are negative but get positive test results.
Dull blue shows the true negatives: the proportion of the population that are negative and get negative test results.


One challenge when considering an individual positive test result is that it is not clear whether it is a true positive or a false positive. We can look at the likelihood of each:

Dull red shows the true positives: the proportion of the population that are positive and get positive test results.
Yellow shows the false positives: the population that are negative but get positive test results.

Using the values that were input above for prevalence, false positives and false negative,
we find that of the positives:

True positives:
False positives:

When the prevalence is low, it is common to have a situation where there are more false positives than true positives. You can try this out for yourself by reducing the prevalence number above.

The Mathematics of a Ponzi scheme

A Ponzi Scheme is a form of investment where profits are paid to early investors with funds from later investors. It often involves fraud and as a result it is of course illegal.
This article will explore the mathematics of a Ponzi Scheme which has been transparent about its intentions. Suppose someone were to set up a fund that aims to pay investors a return of \(\rho\) (rho).
I.e. for each unit of currency invested, it will aim to return \(1+\rho\).
The fund pays out on a first in, first out basis. Early investor money is returned when (or if) later money arrives.
Suppose, at a point in time, the cumulative money invested is N.
The money that's been paid out is P and the fund has remaining money R.
We known that
(Investment in) = (Payouts made) + (Remaining money)
\[N = P + R\] We can classify the investment so far into two categories. There is the money that has already been settled S, i.e. the early investors that have already received their funds returned with a positive return \(\rho\) .
And there is the balance outstanding B, that remains unsettled as yet.
So we can write:
(Investment in) = (Settled amount) + (Balance outstanding) \[N = S + B\]
The early investors who have received their settlement all got a return of \(\rho\).
So we know that the payout: \[P=S(1+\rho)\] The fund administrator has guaranteed that the maximum loss that could be imposed on an investor is \(\lambda\) (lambda).
So for each unit of currency invested, the worst case scenario for the investor is that \((1-\lambda )\) is returned.
Hence we require the remaining funds (R) to be able to cover a payment of the balance (B) with an imposed loss. \[R= B( 1 - \lambda )\] We now have 4 equations and 4 unknowns (P,R,S,B) along with three knowns (N, \(\rho\), \(\lambda\) ).
If we do the algebra, we can find our unknows:

Settled amount:	\(S = N \frac{\lambda}{\lambda + \rho} \)
Balance outstanding:	\(B=N-S\)
Payouts made:	\(P=S (1+ \rho) \)
Remaining money:	\(R=N-P \)

We can try that out with some numbers:

Inputs
Total invested funds (N)		units of currency
Investment return (\(\rho\))		%
Acceptable loss (\(\lambda\))		%
Outputs
Settled amount (S)	-
Balance outstanding (B)	-
Payouts made (P)	-
Remaining money (R)	-

With such a scheme, any investor would be allowed to demand an immediate repayment of funds at any time, though in that case a loss of \(\lambda\) would be imposed. In other words, for each unit of currency invested, \(1-\lambda\) would be returned.

One problem for early investors is that they don't know how long they will have to wait until they'll be repaid their investment with the positive return (\(\rho\)). But it is not just a question of when they'll be paid, it is uncertain if they'll be paid. When later investors don't arrive, the early investors just wait and wait, until they eventually give up and request a return of funds, in that case they'll just have to accept a loss.

It is also worth noting that this model above ignores any administrative fees that may be imposed on funds on the way in and or the way out.

Plotting dates

Suppose you're plotting some attribute against time and so, on the horizontal axis you have years or dates. You might produce a graph such as the following which is of a currency exchange rate:

However one problem is that a year such as 2021 is an interval of time, indeed it is a full year, but on the graph it is presented as a point in time. When an interval of time is presented as a point in time, it reduces the clarity of the graph.
We could improve matters by displaying years as intervals. For example look at the following graph showing 5 years of data:

Sometimes we show graphs of data and the total interval of time is shorter. The graph below shows 12 months worth of data:

Again we have a familiar problem. A month is an interval in time, but on the graph above it is presented as a point in time.
Similarly we can be a bit more diciplined about showing an interval of time as an interval, rather than a point. For example we could have the following graph:

The aim is to be both precise and to be clear.
We often have a similar issue when we have just a few days of data. In that case we need to remember that a date represents a day which is 24 hours long, it is not a point in time!
There are a few caveats:
If we're showing many years of data, then relatively speaking, one year is short, so it is approximately a point. Similarly if we have hundreds of days of data, then one day is almost just a point.
There are also cases when the data is aggregated over a period. We might show monthly rain-fall in that case it may make more sense to display the month as a point, since it represents one data point and not a segment of the graph.
On the other hand if we are showing data within one day, then a time such as 10am is indeed just a point, it is not an interval. 10am does not last for one hour, it is just a point in time. In that respect it is unlike a date, which represents a full day. A date is not a point in time, it is an interval of 24 hours.
But overall, the moral of the story is: if you're using a time interval (year, month, day) as a label on a graph, then it should be diplayed as a time interval and not a point in time.

Intuitions about exponential growth

Suppose you fold over a sheet of paper, you'll then have something twice as thick as the original. Fold it again and you'll have something 4 sheets thick. With each fold the thickness doubles. This is an exponential growth and unlike linear growth, it accelerates.
Well, what if we start with paper 0.001 meters thick, how high would it be if it were folded 100 times? It turns out the answer is a thickness which is a bit more than the diameter of the universe. When written in meters, the number has 28 digits (before the decimal point).

Initially that may seem rather counter intuitive. However with a little bit of training, it can become intuitive. We actually do have lots of experience in dealing with this kind of dramatic exponential growth. Think about how we represent regular integers. Adding a zero will increase the number by a factor of 10. That's an example of exponential growth. The value of the number increases exponentially with the number of digits. We all know that a number with 4 digits, say 1,000 is much much smaller than a number with 8 digits, say 10,000,000. In this case when we have doubled the number of digits and the value increased by a factor of 10,000.
So, the moral of the story is that our experience with representing numbers using the standard decimal digits, gives us a good understanding of exponential growth.

Coming back to our folding example, we note that 3 foldings, causes 3 doublings, which increases the thickness by a factor of 8, which is pretty close to 10. So as a very rough rule of thumb, we'll almost be adding a new digit to the thickness after every three foldings.
If you want to be a bit more precise, then note that 2 to the power of 10 is 1,024 which is close to 1,000. So ten doublings (2 to the power of ten), causes an increase of just over 1,000, which means we add 3 digits. When we have 100 doublings, that is 10 times 10 doublings: \[2^{100} = (2^{10})^{10} = (1,024)^{10} \approx (10^3)^{10} = 10^{30} \] We started with something \(0.001 m\) thick and ended with something approximately \(10^{27} m\) thick.

Is exponential growth always very fast? Actually no. It depends on how long it takes to double. Suppose you are paid an annually compounding interest rate of 0.1% on your deposits in a bank. That is an form of exponential growth. But it will take 693 years for your money to double. That's the bad news. But the good news is that if you start with one euro it will grow to over a billion after it has doubled 30 times. \[ 2^{30} = (2^{10})^3 = (1,024)^3 \approx (10^3)^3 = 10^9\] But that will take more than 20,000 years.