Because the "trapdoor" functions used in public key cryptography are designed with exactly that property.
In your question, the first implicit assumption is already wrong. If a function can be calculated, it does not necessarily follow that its inverse can be calculated with similar effort or can be calculated at all.
For example, the function "abs" returns the absolute value of its argument. Naturally, its inverse cannot be computed, because you don't know whether the original argument was positive or negative.
Other functions have a defined inverse but it's much harder to compute the inverse than computing the original function. Elliptic curve functions as used in bitcoin belong to this class, as well as the operations on large primes that are used in RSA public key crypto (Pretty Good Privacy).
"Much harder" in this case does not mean "requires a faster computer" but "impossible given the natural laws and available ressources of humankind."

Onkel Paul

Thanks for the response. I like mathematics but never studied too much of it. I would like to understand in more detail both about functions that can't be reversed and the ones which reversion is much harder than the original, where can I read about that?

And if it's possible to create a non-reversible function, then why didn't they do that with bitcoin?

His example does explain a lot to be honest , I personally got it
Thanks for the information Kazimir , really helpful

~ Madness

The examples given here are wrong and misleading.

The problem is not that it is not possible to compute the private key, because there is more than one solution (like in the case of abs() or the sum of numbers). The problem is that it is possible, in theory, to compute it, but the computation is so hard that it is practically infeasible.

Do not confuse asymmetrical cryptography with hashes. A hash is impossible to reverse, because many different inputs can result in the same output. (It's just that there is no easy way of finding all of them - or even any one of them.) A private key can be computed from the public one - but it is very, very hard - hard enough to be practically impossible.

For instance, if I ask you what is the product of 31 and 37, the answer is easy - 1147. But if I ask you what are the prime factors of 1147, that's a hard question. The easiest way to answer it is by trial and error - you try to divide 1147 by every prime number smaller than the integer part of its square root until you find a number that divides it exactly (the first such number is 31). When the numbers involved are very large it becomes practically impossible to answer such questions. (With large numbers there are faster methods than trial division, but they are still too slow to be practical.)

Nope, that does explain Bitcoin. Each address represents around 2^96 possible private keys. It is believed to be computationally infeasible to generate a collision.

If you watch a video on a pen and paper SHA256 hash, it might become more clear. It's pretty neat.

I tried to watch the video, and I gotta say, it was extremely IRRITATING to have the math-intensive lecture slides dissapear at the WORST possible timing to only cut to the lecturer in person. What. The. Fuck.

Whoever edited the video needs to be stuffed into a cannon and shot. What is supposed to be an informative learning video is ruined by moronic decision making that killed my concentration.

It was a simple example just to understand how difficult it would be determine the key from an address, hence the emphasis on 'suppose', he never implied that it was the concept the bitcoin address generation is based on.

But all of the 2^96 possible private keys of an address work, don't they? Or only one works?