Is ieee754 fp meant to be a replacement for bcd fp?

[commie]

  Hi, its me again,

I notice alot of people think bcd floating point is somehow old school and lives in the 1970's, the fact is, all relevant calculators use bcd still to this day.This being the case, why don't compiler manufactures offer bcd fp? Heck, the AVR hardware designers were/are so confident that they removed the 'DAA' instruction from its instruction set.

Apparently, Swissmicros, who claim to produce the worlds most precision calculators use 128bit ieee754 fp, clearly smashing a nut with a sledge hammer only to have customers complain that pi,2pi, 3pi.. sine function gives a very small number , which is incorrect as my £15 Casio gives zero i.e., what the  answer should be. I sense shafting going on again.

[PCB.Wiz]

...This being the case, why don't compiler manufactures offer bcd fp? ..

That will be because the underlying hardware uses IEE or similar Float.
BCD floats tend to come from serial mathops, (like your calculator examples) which do not really care how long a calculation takes, and ultimately display BCD anyway.

Microcontrollers and small MPUs are more interested in compact memory usage, so the binary float packs better.
They also often have 4 or 8 byte integers already, so 4 or 8 byte floats are natural packing-compatible offerings.

[Kleinstein]

Chances are you will get BCD floats with a modern Cobol compiler  - though I doubt you find this for a µC (maybe with GCC ?).

Nobody really needs BCD floats: you may want BCD for financial math, but that is about it. These usually can use a fixed 2 or 3 digits behind the decimal and fixed point math. With good rounding normal binary FP is good enough.

The typical example where binary FP failed was something like summing up 0.1 until you reach a large number like 100. This may very well fail.

[SiliconWizard]

You may consider decimal floating point, which is every bit as standardized and has not died.

What Swissmicros have done, I have no clue. I suppose the calculator you're talking about is the DM42, "based" on the HP42S. Interestingly, Free42, which is a well known simulator of a HP42S, has the option to use either binary or decimal floating point. The original HP42S itself used a Saturn processor, which, IIRC, implemented BCD arithmetics.

According to Swissmicros, they based their calc on Free42 and they mention using decimal floating point: https://www.swissmicros.com/product/dm42
but they also mention using quad precision FP (128 bits). It's sort of unclear to me how they use what. Free42 can be configured in different ways. You may want to ask them directly.

But I don't think what you mentioned (sin(pi) not being exactly zero) is a sign of any rounding problem here. You probably know that pi is irrational, and so any numerical representation of pi, no matter with how many decimals and number format, will always be an approximation. So I think sin(pi) = very small number but not zero exactly is the sign that the calculator is very accurate, not the other way around, and has nothing much to do with the fact it would use decimal or binary representations. The only way sin(pi) = 0 on a calculator would either be because the calculator actually had poor precision (if pi is implemented as a numeric constant), or because pi would be treated not as a numeric constant internally, but as a "symbolic" object, and the calculator would just implement particular cases when it's encountered as an argument in trigonometric functions.

[Kleinstein]

The difference between getting zero and a small number could be in the way rounding is implemented. With floating point (exponential display) even very small numbers can be shown, well better than the accuracy one gets from even 128 bit sin(x).  There are also different options on how to implement the sine function: usually one first subtracts muliples of 2 Pi - so the question here is if the same math  rounding is used as when the user calculated 2 * pi or similar. Chances are they get zero if the modulo 2 pi gets exacty zero, which is possible. A factor could be just the last bits in the approximation of Pi: they may allow easy rounding or cause errors. So the same algorithm may give different results with 32, 48 , 64, 80 ,... bits with no easy pattern.

[commie]

What Swissmicros have done, I have no clue. I suppose the calculator you're talking about is the DM42, "based" on the HP42S. Interestingly, Free42, which is a well known simulator of a HP42S, has the option to use either binary or decimal floating point.

Using your own link, the calculator utilizes...
IEEE 754-2008, 128-bit floating point precision implementation with 128-bit transcendental function support

. So I think sin(pi) = very small number but not zero exactly is the sign that the calculator is very accurate, not the other way around, and has nothing much to do with the fact it would use decimal or binary representations. The only way sin(pi) = 0 on a calculator would either be because the calculator actually had poor precision (if pi is implemented as a numeric constant), or because pi would be treated not as a numeric constant internally, but as a "symbolic" object.

Try your own calculator, sine(pi) and see what you get? You are saying, if calculators the world over, all utilizing bcd fp , give zero for sine(pi) then they are not accurate? and deploy some sort of software trap or alternatively calculators that are producing zero for sine(pi) are less accurate than those producing a small number, like 10^-11

[Nominal Animal]

Whether sin(pi) is zero or not is not indicative of the precision achieved.

In IEEE-754 Binary64, pi is approximated as 3.141592653589793115997963468544185161590576171875.
sin(3.141592653589793115997963468544185161590576171875) ≃ 1.2246467991473531772260659322749979970830539012997919494882577162608696099732581⁺×10^-16.

The fact that IEEE-754 Binary64 sin() of pi yields
sin(3.141592653589793115997963468544185161590576171875) = 1.22464679914735320717376402945839660462569212467758006379625612680683843791484832763671875×10^-16
means it is actually accurate to 16+17=33 decimal digits.  If it yielded zero, it would only be accurate to 16 decimal digits.

Expecting exact results when operating on approximate values is a common error.  Fortunately, we have arbitrary-precision algebra programs available for us, for example Wolfram Alpha online, with which we can explore the values and functions more precisely.

When a calculator or program yields zero for sin(pi), it almost certainly does algebraic simplification on the argument first.
A good test of precision, therefore, on your calculator or program is to see what it yields for sin(longest approximation of pi that can be input, or makes a difference in the answer).

IEEE-754 Binary32 ("float"): sin(3.1415927) = sin(3.1415927410125732421875) ≃ -8.74227800⁺×10^-8
IEEE-754 Binary64 ("double"): sin(3.1415926535897931) = sin(3.141592653589793115997963468544185161590576171875) ≃ 1.224646799147353177⁺×10^-16
IEEE-754 Binary128: sin(3.1415926535897932384626433832795028) = sin(3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857177734375) ≃ 8.67181013012378102479704402604335196876⁺×10^-35.

(The first argument is the value that suffices for specifying the exact argument, which is shown as the second sin argument; the third, result, is obtained using arbitrary-precision arithmetic, and is correct to within the shown digits. ⁺ indicates that the value is not exact and additional digits actually follow.)

Dividing the argument by two pi, and only using the fractional part, actually leads to increased numerical error than otherwise, so if the calculator or program actually does yield zero for the sine of the closest approximate value of pi it accepts, it is less precise than if it returned a nonzero value.  Re-read third paragraph in this post for the reason, if you disagree.

[SiliconWizard]

What Swissmicros have done, I have no clue. I suppose the calculator you're talking about is the DM42, "based" on the HP42S. Interestingly, Free42, which is a well known simulator of a HP42S, has the option to use either binary or decimal floating point.

Using your own link, the calculator utilizes...
IEEE 754-2008, 128-bit floating point precision implementation with 128-bit transcendental function support

If you had read everything, you would have seen they (and I, for Free42) mentioned DECIMAL FLOATING POINT. The 2008 revision of IEEE 754 added decimal FP.
https://en.wikipedia.org/wiki/IEEE_754-2008_revision

So, even if, as I said, Free42 can be configured to use either binary or decimal FP, I guess it is safe to assume here that they have used 128-bit decimal floating point. And feel free to ask them for a confirmation. Or if anyone from Swissmicros reads this and wants to chime in.

. So I think sin(pi) = very small number but not zero exactly is the sign that the calculator is very accurate, not the other way around, and has nothing much to do with the fact it would use decimal or binary representations. The only way sin(pi) = 0 on a calculator would either be because the calculator actually had poor precision (if pi is implemented as a numeric constant), or because pi would be treated not as a numeric constant internally, but as a "symbolic" object.

Try your own calculator, sine(pi) and see what you get? You are saying, if calculators the world over, all utilizing bcd fp , give zero for sine(pi) then they are not accurate? and deploy some sort of software trap or alternatively calculators that are producing zero for sine(pi) are less accurate than those producing a small number, like 10^-11

As Nominal Animal and I said, this has nothing to do with the precision of the calculator, and even less so with whether it uses decimal or binary FP.
It's just all in the way they have implemented their trig functions.
As I said, from a strict precision POV, as long as you are doing NUMERIC calculations, not giving 0 as an answer for sin(pi) is perfectly correct, since pi itself will not be exact. And if the (2) emulators of the HP42S I have are emulating it correctly (I don't have the original), the HP42S itself didn't give 0 for sin(pi).

sin(n*pi) giving exactly 0 would be expected for a symbolic calculator, not for a numeric one. I get it that many vendors have probably tried their best to implement trig functions so that they give the "exact" values for the typical multiples of pi, so users, especially young students, are not troubled by this, but from a purely numeric POV, where calculations are approximations, it's fine. And those calculators may not give as precise results for trig functions for values that are not integer multiples, or simple fractions of pi. You could compare.

[rstofer]

HP Prime calculator for sin(3*pi) -> -6.2028461207 * 10^-13

Pi is irrational, why would sin(pi) come out exactly 0?

[commie]

HP Prime calculator for sin(3*pi) -> -6.2028461207 * 10^-13

Wow, amazing, I bet the hp prime has an ARM processor under the hood and it's application firmware was coded using a compiler supporting IEEE754 fp. My Casio cg50 gives zero for sine(pi).

Pi is irrational, why would sin(pi) come out exactly 0?

Because, zero is the correct answer.

[westfw]

Pi is irrational, why would sin(pi) come out exactly 0?

Sine of pi is zero.  Sine of any representation of Pi that you can punch into a calculator will be "not quite zero."

[newbrain]

What Swissmicros have done, I have no clue. I suppose the calculator you're talking about is the DM42, "based" on the HP42S.
[...]According to Swissmicros, they based their calc on Free42 and they mention using decimal floating point: https://www.swissmicros.com/product/dm42
but they also mention using quad precision FP (128 bits). It's sort of unclear to me how they use what. Free42 can be configured in different ways. You may want to ask them directly.

Unsurprisingly, being the same SW, my DM42 gives the same result as Free42 on Android - so using decimal quad precision FP - for π SIN: -1.158E-34 which is the expected result*.
π itself is approximated to 34 digits 3.1415926535 8979323846 2643383279 503 - the first time I meet a calculator that knows more digit of π than me

The library used is Intel® Decimal Floating-Point Math Library in 128 bit mode, giving exactly 34 decimal digits.

Because, zero is the correct answer.

If the argument is π.
But in a physical machine, π - as a number - cannot be represented.
Given the minuscule amount of error, I would say that a first degree Taylor series is enough, so Sin(x) == -S(x-π) ~= -(x-π).
For the 34 digit π approximation shown above,  this number matches the actual sin(x) up to 10^-103 and DM42/free42 results for all the 34 digits available.
Some calculator will go out of their way to make their result "right", leading to some bizarre effects:


*I have tried to coerce WolframAlpha to give me a numeric result, but it keeps saying it's zero  ! I ended up using this.

[Nominal Animal]

Another tool one can use is wxMaxima/Maxima: the bfloat() converts a symbolic expression to arbitrary precision, using fpprec significant digits.  In Maxima, the irrational number π is represented by %pi.

If your calculator accepts input
    sin(π)
and outputs
    0
then it is okay, because it does symbolic simplification on the argument (detecting that the argument is a multiple of π).  It most likely also outputs zero for stuff like sin(3π), too, which is okay.  Here, π is truly irrational, and sin (and possibly other functions) are evaluated using a mix of symbolic and numeric algebra.

If it outputs a small number instead, then that is okay too, and just indicates the calculator is purely numeric, and has to approximate π with limited precision.

If your calculator accepts input
    sin(3.14159265358979323846)
and outputs
    0
then it is in error.  The correct answer is approximately
    1.224646799147353×10^-16

If one believes the this input should also output zero, then one rejects the idea of an irrational π, and therefore the observable reality around us.

Problem is, we don't know which OP refers to by π: the approximate value used by a purely numerical calculator, or the actual irrational value used by symbolic and mixed symbolic-numeric calculators (like Maxima/wxMaxima).


As to whether IEEE-754 floating-point formats are intended as replacement for BCD floating-point: Yes, since 2008. IEEE-754 defined in 2008 Decimal64 and Decimal128 formats, where the significand is represented either in binary, or in densely packed decimal.
(Essentially, BCD packs two decimal digits in each 8 bit group, DPD packs three decimal digits in each 10 bit group.)

All current processors and arithmetic-logic units use binary arithmetic at their core.  (Although there do exist ternary machines and other oddities, these are either experimental or historical curiosities.)  This is because such arithmetic-logic is smaller, easier, and faster to implement in hardware (logic gates) than e.g. BCD or any other known formats.  That is, we didn't pick binary because it is easier for programmers, we picked binary because that way the hardware is simpler, cheaper, and faster.

The most interesting thing about BCD floating-point and Decimal64/Decimal128, is that they use base 10 for the exponent.  (The table in the Wikipedia IEEE 754 article is useful here.)  This is what makes the core difference in the floating-point representations, not how the significand (mantissa) is described.

With fixed-point formats (as used in e.g. finance), all three – binary, DPD, and BCD – can be used, but binary is the fastest to compute and requires the least storage for the same range of representable values, whereas BCD is the easiest to convert to/from text representations.  DPD is somewhere between the two.

[commie]

whereas BCD is the easiest to convert to/from text representations.  DPD is somewhere between the two.

Ah,ha there is truth there, so if we start to think how bcd and ieee fp go into and out of the cpu...we find ieee754 has a massive rom code overhead in order to get the ieee754 fp numbers into and out of the cpu, perhaps that is why we use strings for ieee754 fp, ??

There is some sort of conversion going on in there with ieee754 fp, causing small errors to creep in?

[Nominal Animal]

if we start to think how bcd and ieee fp go into and out of the cpu...

With base-2 exponents (as used in Binary32/64/128), the problem is that not all decimal number strings can be represented exactly.

For example, we cannot represent one tenth (0.1 = 1/10) in binary exactly, because 1/10 = 1/16+1/32+1/256+1/512+... or in binary, 0.00110011₂ (i.e., the last four binary digits repeated).

Working on base-10 exponents is a bit slower (because it takes more memory and more logic gates or basic operations than binary), but usually it does not matter.  You wouldn't want to run numerical simulations or other massive amounts of data on base-10 –– except if fixed-point financial data! ––, since binary is more efficient, but for human-interfacing stuff like calculators, base-10 exponent format makes sense, because the results are what humans expect them to be, with intuitive rounding.

It does not make it any more precise, however; only that the rounding done is intuitive to us humans, because the operations including rounding is done on the decimal representation (and not binary representation).

π, the irrational and transcendental number describing the ratio of the circumference of a circle to its diameter on an Euclidean plane, cannot be represented exactly in any integer (or rational) basis.  (Weirdly enough, Simon Plouffe discovered in 1995 a very simple spigot algorithm, BBP formula, that can calculate any desired hexadecimal digit of π without calculating any other digits at all.  Thus far, nobody has discovered a way to calculate any specific decimal digit in a similar way that was less work than calculating all the more significant decimals too.)

It is almost as if the universe is hinting to humans that hexadecimal, base-16, is somehow more "natural" than say base-10... 

[commie]

With base-2 exponents (as used in Binary32/64/128), the problem is that not all decimal number strings can be represented exactly.

Thanks for an excellent post. All my ti83+,ti84+ work in bcd fp and as you would expect they all give zero for quantized pi using the sine function.

I tried to squeeze a hp45(originally also bcd) in an avr 328, and although it works well the errors produced by going from keyboard to cpu and back out to strings for the display and back again, well the errors are a bit of a joke using ieee754 fp, to say the least. BCD on the otherhand has no conversion errors induced because the io is transparent which is why it is widely used in numerical calculations, bcd is very wasteful of ram but nowadays ram is in abundance.In otherwords, keep away from ieee754 fp because its crap for precision calculations, in particular where io is concerned.

[ejeffrey]

With base-2 exponents (as used in Binary32/64/128), the problem is that not all decimal number strings can be represented exactly.

Thanks for an excellent post. All my ti83+,ti84+ work in bcd fp and as you would expect they all give zero for quantized pi using the sine function.

Any numerical (not symbolic) calculator supporting floating point that gives sin(pi)=0  is giving you an incorrect answer because it thinks that is what you want to see.  It definitely has nothing directly to do with whether it stores numbers as decimal vs binary although there are better, faster, and more accurate algorithms for binary floating point so it may be that binary floating point calculators are systematically better at preserving accuracy when calculating trig functions that have very small results.

Using BCD floating point is extremely niche application.  Most of the time if you need BCD you also need fixed point.  Even then, you pretty much have to stick to +, -, * and limited division to get any value.  Calculating trig functions using BCD is just going to be less efficient and less accurate than  binary.  It can still make sense in certain situations because maybe your calculator is used in both financial and engineering applications and it isn't worth the effort to implement both.  But it is always a compromise.

[Nominal Animal]

In otherwords, keep away from ieee754 fp because its crap for precision calculations, in particular where io is concerned.

No, you still don't get it.

If your calculator says that sin(3.14159265358979323846) is zero, it is less accurate than one that says it is 1.224646799147353×10^-16.

That's not me saying it, that's just how the math works out.


What is true is that if you wanted to calculate say 0.54321 × 0.9876, the exact result is 0.536474196.  On a calculator that uses base-10 floating point with at least nine significant digits of precision, you get exact results.

On a calculator that uses base-2 floating point, those terms cannot be represented exactly.
    0.54321 = 54321/100000 ≃ 0.1000101100001111110011111000000011011100…₂
and
    0.9876 = 2469/2500 ≃ 0.1111110011010011010110101000010110000111…₂
therefore the result,
    0.536474196 = 134118549/250000000 ≃ 0.1000100101010110010111110111011011110111…₂
is also only approximate.

Whether the base-2 floating-point using calculator yields the expected results, depends on the number of significant bits it internally uses, and whether it tracks the number of significant decimal digits in the arguments, and uses the appropriate number of decimal digits to display the result.  Even in C one can use printf("%#.*g", double, digits); to print double using digits decimal digits of precision.

If you want exact results for your inputs, like in say finance, you use fixed-point arithmetic instead, so that rounding is avoided for multiplication, addition, and subtraction (× + -).

But, you cannot represent irrational and transcendental values like e and π exactly in any integer or rational base.  Thus, the result of sin(π) tells you much less about the precision and accuracy at which the computation is done, than you seem to believe.  As I originally explained, testing the sine function with a numerical value close to pi yields much more information about the precision (by comparing the result to the expected results – which is not zero) and accuracy (by comparing the number of significant digits in the input, and those correct in the output).

Given the same amount of computing resources, including memory and logic gates, binary floating-point will give you wider range and precision.

So, while base-10 systems like BCD and DPD are very useful in calculators, your assertion that "ieee754 fp is crap" has no factual basis.  It seems to me your feelings on this are based on a fundamental misunderstanding about numerical accuracy.

It is a common problem.  I've seen how it often takes computational physics students completely by surprise how little they actually know about numerical accuracy and precision – including myself – when they study the nitty-gritty details of it all.  I haven't found a better volume about that stuff than Numerical Recipes is.

[commie]

Any numerical (not symbolic) calculator supporting floating point that gives sin(pi)=0  is giving you an incorrect answer because it thinks that is what you want to see.

You are incorrect my friend, for small numbers the function y=sin(x) equates to y~=x, that is, put sin(10^(-50)) into your bcd calculator and the answer will be 10^(-50). Do you honestly think there is some sort of software trap in these bcd calculators, if so when does it kick in?
Furthermore, a calculator cannot 'think' it is an electronic machine only.

[SiliconWizard]

@ Nominal Animal: You're very patient =)
(And that said, we need to say for the (third? more?) time that IEEE754-2008 also defines decimal FP. Not that it matters again here for pi, but just to say that "ieee754 fp" is misleading, because it could be either binary or decimal FP, and again, the DM42 is likely to use decimal FP.)

[commie]

So, while base-10 systems like BCD and DPD are very useful in calculators, your assertion that "ieee754 fp is crap" has no factual basis.

I did say, 'where precision calculations were concerned'

[commie]

@ Nominal Animal: You're very patient =)
(And that said, we need to say for the (third? more?) time that IEEE754-2008 also defines decimal FP. Not that it matters again here for pi, but just to say that "ieee754 fp" is misleading, because it could be either binary or decimal FP, and again, the DM42 is likely to use decimal FP.)

I take it you are the proud owner of a DM42 then?, why did the original ieee754 fp require modifying? did the original 1985 ieee754 fp have a recognized problem?

[Rick Law]

... ... ...
But, you cannot represent irrational and transcendental values like e and π exactly in any integer or rational base.  Thus, the result of sin(π) tells you much less about the precision and accuracy at which the computation is done, than you seem to believe.  As I originally explained, testing the sine function with a numerical value close to pi yields much more information about the precision (by comparing the result to the expected results – which is not zero) and accuracy (by comparing the number of significant digits in the input, and those correct in the output).
... ... ...

Nominal Animal reiterated a significant point here that π is an irrational number.  It doesn't matter how many digits you got, you can never fully represent that number.

It is good for students and everyone else to understand the limits of resolution -- even nature has one.  Everyone should adapt the mindset that exact result only exist in theory.  While nature is quantize, results in the real world are approximated, or rounded, or statistical, and there is no infinite accuracy.  Somewhere down the resolution hole, nature will be truncating or rounding π to "calculate" its responses and presumably nature's responses will be within Heisenberg Uncertainty Principle  (which presumably also use a rounded π).

EDITed:  Corrected a couple of wording problems.

[newbrain]

the DM42 is likely to use decimal FP.

Nope, it's not likely. It's a fact!
See my post above, or peruse the code of Swissmicros and Thomas Okken's repositories on github.

[Nominal Animal]

So, while base-10 systems like BCD and DPD are very useful in calculators, your assertion that "ieee754 fp is crap" has no factual basis.

I did say, 'where precision calculations were concerned'

Precision or accuracy has nothing to do with whether the numbers are represented using base-10 or base-2 floating-point formats, I've shown that above.

The conversion to and from decimal number form is exact, cheap, and easy with base-10. That is all.  Other than that, precision or accuracy is not involved.

If you have sufficient binary precision, and use the binary approximates, you get the same results with base-2 as you do with base-10, if you track the number of significant digits yourself.  We have even had discussions here on EEVBlog on the various methods of doing this efficiently.  The key point is that as long as your precision – the number of significant digits your base type can describe exactly – is sufficient, and you track the number of digits, you can produce the exact same results using base-2 internal representation as with base-10 internal representation.

It is the resource use in decimal conversion – and to a lesser degree, tracking the number of decimal digits needed for correct base-2 representation – that makes the difference between base-10 and base-2 representations.  "Precision" or "accuracy" has nothing to do with it.

When I want to do precise math, I use algebraic representation (symbolic math), and for example rational numbers to represent decimal numbers: for example, 0.7531 = 7531/10000. This is common in symbolic algebra toolkits.  For all rational reals, the numerator is an integer, and the denominator a nonnegative integer.  Irrational numbers are approximated using sufficiently precise rational number.  Transcendental irrational constants e and π can be approximated to any desired precision, or treated specially.  No base-10 representation at all, except that when parsing, the decimal form will initially have a power-of-ten denominator.

(I have toyed with the idea of representing arbitrary-precision real numbers as products of powers of primes, but I'm afraid the math involved in implementing efficient addition and subtraction for them, is beyond my math-fu.  Multiplication and division is trivial with them, it's the addition and subtraction that are extremely hard with such.)

I do use BCD, DPD, or related base-10 representations myself on microcontrollers when dealing with values that get displayed in decimal form, when I only need basic arithmetic operations (× ÷ + -) on them.  Again, it is not about precision, but about the effort needed for the conversion.  (On a low-power 32-bit MCU, say a Cortex M0, I might even use an intermediate form, where two 14-bit units, each describing four decimal digits (0000-9999), are stored in the 28 least significant bits of a 32-bit word.  This means that I can implement the basic arithmetic using only 32-bit operations (no 32×32=64 multiplication or 64/32=32 division needed), and with a divide-by-10000-and-remainder 32-bit operation, I can implement arbitrary precision arithmetic.  Precision limited only by available memory.)

@ Nominal Animal: You're very patient =)

I remember when I myself first learned about numerical precision (in representations) and accuracy (of real-world approximations of non-polynomial functions like trigonometric functions, logarithms, antilogarithms, and exponents), and how inefficient and complicated I erroneously thought the binary representations are.
I don't blame anyone for initially misunderstanding this stuff, but I do want to clear such misconceptions.

It is good for students and everyone else to understand the limits of resolution -- even nature has one.  Everyone should adapt the mindset that exact result only exist in theory.

I like to think that while numbers are exact, the things we measure using numbers are not.  The approximations do not apply to the numerical values, but to the measurements or estimates we use the numbers to represent.  (Statistics, and concepts like standard deviation or confidence intervals, have a very similar brain-twist.)

You could argue that counting things is exact.  Quantum physics says otherwise, because reality itself isn't exact in that way.  (Even though quantum fields and such may be exact, the observables, the quantities we can measure, are not.  It appears that's just how reality works.)

To illustrate, consider the task of obtaining a decimal representation of e/π ≃ 0.865.  How do you calculate the result? To an arbitrary precision?
This is a good example, because both are irrational, transcendental numbers that (as far as we know) are not related to each other, and it is not obvious (even if it is linear) how (lack of) precision in the numerator or denominator will affect the precision in the result; range arithmetic would be useful here.
The precision of the result won't be affected by the base or format of numeric representation you use; it is all about the method(s) you use for the calculation.