The core idea behind floating point numbers is that you have some number of bits for the mantissa, and then some number of bits to tell where the decimal point is, and of course a bit for the sign.

Let us not get down into how that works in practice. Have a video. Have more videos.

Here is the deal, around 0 we get a lot of precision, because we can place the decimal point right at the start of the mantissa, leaving all the bits to express the fractional part.

However as we move away from 0, we need to use more bits to represent the integer part, meaning that we have less bits for the fractional part, and thus less precision.

The result, ignoring all technicalities, is that the more we move to the future the less precision we have in the value of time, and thus the more rounding errors and soon things do not properly.

Were we using floating point numbers, the minimum increment possible would go up every time we need one more bit of the mantissa in the integer part. It does not sound like it is easy to design a clock that works like that.

In fact, some things could stop working at all. For example, if we represent time in seconds, and we run out of bits for the fractional part, anything that needs fractions of seconds does not work.

Do you want that?

Computers clocks ultimately boils down to counting oscillations of a vibrating crystal. We count how many times it shakes. And that is fundamentally an integer.

More videos.

The core idea behind floating point numbers is that you have some number of bits for the mantissa, and then some number of bits to tell where the decimal point is, and of course a bit for the sign.

Let us not get down into how that works in practice. Have a video. Have more videos.

Here is the deal, around 0 we get a lot of precision, because we can place the decimal point right at the start of the mantissa, leaving all the bits to express the fractional part.

However as we move away from 0, we need to use more bits to represent the integer part, meaning that we have less bits for the fractional part, and thus less precision.

The result, ignoring all technicalities, is that the more we move to the future the less precision we have in the value of time, and thus there are more rounding errors and soon things do not work properly.

Were we using floating point numbers for time, the minimum increment possible would go up every time we need one more bit of the mantissa in the integer part. It does not sound like it is easy to design a clock that works like that.

In fact, some things could stop working at all. For example, if we represent time in seconds, and we run out of bits for the fractional part, anything that needs fractions of seconds does not work.

Do you want that?

Computers clocks ultimately boils down to counting oscillations of a vibrating crystal. We count how many times it shakes. And that is fundamentally an integer.

More videos.

The core idea behind floating point numbers is that you have some number of bits for the mantissa, and then some number of bits to tell where the decimal point is, and of course a bit for the sign.

Let us not get down into how that works in practice. Have a video. Have more videos.

Here is the deal, around 0 we get a lot of precision, because we can place the decimal point right at the start of the mantissa, leaving all the bits to express the fractional part.

However as we move away from 0, we need to use more bits to represent the integer part, meaning that we have less bits for the fractional part, and thus less precision.

The result, ignoring all technicalities, is that the more we move to the future the less precision we have in the value of time, and thus the more rounding errors and soon things do not properly.

Were we using floating point numbers, the minimum increment possible would go up every time we need one more bit of the mantissa in the integer part. It does not sound like it is easy to design a clock that works like that.

In fact, some things could stop working at all. For example, if we represent time in seconds, and we run out of bits for the fractional part, anything that needs fractions of seconds does not work.

Do you want that?

Computers clocks ultimately boils down to counting oscillations of a vibrating crystal. We count how many times it shakes. And that is fundamentally an integer.

The core idea behind floating point numbers is that you have some number of bits for the mantissa, and then some number of bits to tell where the decimal point is, and of course a bit for the sign.

Let us not get down into how that works in practice. Have a video. Have more videos.

Here is the deal, around 0 we get a lot of precision, because we can place the decimal point right at the start of the mantissa, leaving all the bits to express the fractional part.

However as we move away from 0, we need to use more bits to represent the integer part, meaning that we have less bits for the fractional part, and thus less precision.

The result, ignoring all technicalities, is that the more we move to the future the less precision we have in the value of time, and thus the more rounding errors and soon things do not properly.

Were we using floating point numbers, the minimum increment possible would go up every time we need one more bit of the mantissa in the integer part. It does not sound like it is easy to design a clock that works like that.

In fact, some things could stop working at all. For example, if we represent time in seconds, and we run out of bits for the fractional part, anything that needs fractions of seconds does not work.

Do you want that?

Computers clocks ultimately boils down to counting oscillations of a vibrating crystal. We count how many times it shakes. And that is fundamentally an integer.

More videos.