The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
It seems to me that there could be a type (implemented in your favorite language has has classes, including operator overloading) that would store a number as a rational number. This type would be a list of links that would have prime factors and their exponents (e.g., in C++, the prime factor would be type "unsigned long", with the exponent being "long"). This would work because any decimal (or hexadecimal) input would be a rational number itself, and then any operations would be exact, so that, e.g., the result of (213.56 - 45.41) would be 168.15 and not 168.14999999, etc.
As a rational number? I believe 23/7 comes close, but if you want, you can find even closer rational numbers.
pi isn't a rational number.
With irrational numbers, there would be roundoff problems, although small ones. Most our everyday problems end up in rational numbers. It isn't difficult to implement a rational number type with modern OO languages.
That wouldn't make pi a rational number, though. It would be misleading to provide pi in a class named something like rational_number - unless you called it not pi, but pi_approximated_as_a_rational_number.
A (true) story about pi, I believe it is from around 1980 - I was told the story around 1983 by a guy who had participated in the hunt for The True pi:
At Bergen University, Norway, one professor teaching numerical methods and error propagation had his students estimate the error expected in some trancendental functions in difficult number ranges, and verify it on the University's new shining IBM 3080 mainframe. The students came back and reported significantly larger errors than their estimates suggested. The surprised professor set out to find the cause of this.
It turned out that the IBM 3080 Fortran libraries were carbon copies of the 370 libraries. Which were carbon copies of 360 libraries. The 360 got its libraries (in assembler format, of course, with floating point constants in hexadecimal format) as an adaptation of the old 7090 libraries - machines with a different instruction set and 36 bit word length (rather the 360's 32 bits). Calculating a binary representation of pi anew would have had to be set up as a separate job. They didn't do that; they just chopped 4 bits off the 7090 binary floating point mantissa for the pi value. Ignoring rounding. So the least significant bit, which should have been rounded up to a 1, remained a 0. The professor's theoretical error estimates were based on a properly rounded, not a truncated pi value.
This truncated 7090-binary pi value from the end of the 1950s was interited all the way up to the 3080 series, more than 20 years later. When discovered, and the least significant bit rounded up to a 1, the theoretical error estimates matched the observed errors more or less perfectly.
Still wouldn't help electrical engineers whose work is based on e and I. That said there are a lot of good reasons to support some sort of base 10 fractional numbers to avoid the rounding errors that result from converting base 2 fractionals to base 10 fractionals.