You say above that ieee754 fp strings cannot be represented exactly?
No.
Every IEEE-754 Binary32/64/128 value can be exactly represented as a decimal number.
Not every decimal number can be exactly represented as a IEEE-754 Binary32/64/128. For example, 0.1 is represented by
0.100000001490116119384765625 in Binary32,
0.1000000 in Decimal32,
0.1000000000000000055511151231257827021181583404541015625 in Binary64,
0.1000000000000000 in Decimal64,
0.1000000000000000000000000000000000048148248609680896326399448564623182963452541205384704880998469889163970947265625 in Binary128, and
0.1000000000000000000000000000000000 in Decimal128.
The ratio of the circumference of a circle to its diameter on an Euclidean plane, Pi, is represented by
3.1415927410125732421875 in Binary32,
3.141593 in Decimal32,
3.141592653589793115997963468544185161590576171875 in Binary64,
3.141592653589793 in Decimal64,
3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857177734375 in Binary128, and
3.141592653589793238462643383279503 in Decimal128.
with correct digits underlined.
In all cases,
BinaryN has more precision than the corresponding
DecimalN, and has better approximation of
π, too.
The reason we have IEEE 754-2008 Decimal32/Decimal64/Decimal128 types, and have used BCD in the past, is that
decimal numbers can be represented exactly.
But decimal is not the optimum representation; indeed, with anything involving Pi, we'd be better off using say hexadecimal instead. And when using digital logic, algebraic operations on the binary representations require fewer gates than those on the decimal representations.
The error on your part, commie, is that you seem to think decimal representation is somehow the correct, or natural, one. It is not. It is not even "natural" to us humans, because we've used base-5, base-8, base-12, and base-60 before base-10 became the most widely used.
For example, the British imperial system uses fractions, such that one foot is 36 inches; this means that one inch in feet is 0.0833
3 inches (with infinite number of decimal digits in the decimal representation). You cannot represent many British imperial length measurements exactly in decimal at all. Does that mean the decimal system is inaccurate? Or that the British imperial system was inaccurate? No, neither. It is just that using a simple base format (instead of as rationals, or as symbolic values), the base dictates which numerical values we can describe exactly. Irrational values, like
e and
π, cannot be described exactly in any integer or rational base.
In a human-interfacing calculator with input and display in decimal format, it makes sense to use decimal representation (say, IEEE 754-2008 Decimal32, Decimal64, or Decimal128), because the inputs can be treated as exact, and conversion to/from input/output and internal representation is cheap, quick, and easy.
The problems arise when quantities not representable exactly in the decimal internal representation are used, including
e (and exponentials/antilogarithms and logarithms) and
π.
Trigonometric functions are typically evaluated using
CORDIC. The angular units can be chosen freely; it does not need to be
πor
360º or
400 grad. A calculator manufacturer may choose to implement their CORDIC algorithm such that it treats
π as a rational number. Then, even a straightforward numercial calculator will return
0 for
sin(π). However, this is a problem, because on such a calculator, trigonometric functions with large arguments, say
sin(106), will yield incorrect answers: because the calculator believes
π to be slightly different than it actually is in reality, the argument will have linear error that can be extremely difficult to correct.
(The way it can be corrected for, is to make trigonometric functions non-periodic, such that every real zero and one of sine and cosine, and every zero and singularity (infinity) of tangent and cotangent, occur at an exactly representable point. This way the error is minimized to the difference between the actual value and the closest representable value, and does not compound. This approach is not used, because it is much cheaper and easier to instead make the calculator a mixed symbolic-numeric one, applying symbolic optimizations to terms, and achieving superior accuracy and precision with much less resource use.)
See? Decimal representation is nothing special, and has its own drawbacks. Its main benefit, really, is that it is the one humans currently prefer to read and write in.