⑴
Let me show you one trick here, even though the syntax is a bit weird. Instead of printing out %f alone, let me print out %.5f. So this is weird syntax. And it's only specific to printf " %.5f " means show me five decimal places specifically.
So if I do make calculator, ./calculator, 1, 3, voila. I get five decimal places.
If I want six, let's do this. I'll change the code to 6.
Make calculator, ./calculator, 1, 3 and now I get six 3s instead. All right, well, wouldn't it be nice to be even more precise ?
Let's give me 20 significant digits after the decimal point.
So make calculator, ./calculator. 1 divided by 3, and - - woo. So you middle school teacher seems to have lied to you at this point. 1 divided by 3 is apparently not 0.33333333 with a line over it or just infinite number of 3s. Ok, that's not quite the right conclusion, though, why might I be seeing these weird numbers instead of just lots of 3s, intuitively ? Why this rounding error ? The computer only has limited memory, finite memory. So it just can't represent every possible number in the universe because we know from grade school there are infinitely many of those numbers. So what you're essentially seeing is the closest it can actually get. It's rounding to the nearest floating point value, if you will. And it also relates to how the numbers themselves are represented in memory underneath the hood. I can do a little better, though.
And let me upgrade, so to speak, from 32 bits to 64 bits and use doubles instead. I can still use %f. You don't use %d for double.
Let me do make calculator, ./calculator, 1, 3. I get more 3s but still some rounding. It's more precise, but it's not 100% accurate because that's just not going to be possible in terms of the computer's memory. So this is a whole other issue known as floating point imprecision, which is another type of limitation.
We saw integer overflow, if integers can only count so high before you run out of bits and things wrap around. Floating point imprecision means that you can't possibly represent the infinite number of real numbers that exist in the universe, if you only have a finite amount of memory. You would need an infinite number of bits, it would seem. So these are two issues that actually fundamentally can influence the correctness not only of your code but code in the real world.
⑵
And case in point, back in my day - - I graduated in 1999 - - and a lot of the world thought the world was going to end around then because around the time the years rolled over from 1999 to 2000, there was a lot of old software still running in the world.
And in fact, that old software, reasonably, only used two digits to represnt years. Why ? Memory was very expensive early on. And if you could use half as much memory to store a year, that was a win. That saved you money. The problem though, of course, is that a lot of old software from the 70s and prior was still running in 1999. And unless companies or individuals updated that software, 1999 might be mistaken for the year 1900 instead of 2000 because all of the code just assumed that, of course, we're talking about the 1900s. This code is not going to be running 50 years later, but it was still in that case. So people had to scramble and they essentially had to solve this by using more digits, so upgrading from two to four. Nowadays and really since the 70s too, we've used 32-bit integer from January 1, 1970, the so-called epoch whereby that's just an arbitrary data early on where we just started counting time. So all of the clocks in your Macs, PCs and phones pretty much just have a single integer that gets updated every second but it's just keeping track not of absolute time per se, but how many seconds have passed since January 1, 1970, just because that's the date hunmans chose. The problem is you can only count as high as 4 billion give or take, with 32 bits and actually 2 billion, give or take, if you support negative numbers, as well.
And the problem with that is that we're about to trip over the same issue again in not too long from now. This is the 2038 problem because in the year 2038, on that data, mark my words things could break again. Why ? Because that 32-bit value is going to accidentally wrap around back to a 0 or a negative value. So we're going to go through the whole darn process again. Now, thankfully the solution, as you might expect, is kind of just to kick the can even further down the road and use 64 bits, which I think will get us another 290 million years of runaway. It's more than twice. So it's not our problem anymore at that point. But that's fundamentally going to be the solution. But it will still be finite. So we're just deferring to our descendants to actually deal with the issue some millions of year from now, if these things are still running.
So if that does happen, here's the specific date that in 2038, all of a sudden out clocks will still think because a negative number will get substracted to the current epoch time. So it will think we're back in 1901.