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.

[SiliconWizard]

To finally add a little point about this all, regarding the sin(pi) != 0 affair in itself. We all agree (except commie apparently) that precision has nothing to do with it, since pi itself can only be an approximation.

Some calculators happen to give exactly zero for sin(pi) (using the 'pi' constant provided by the calculator itself), while others don't. I have 2 physical HP calcs, and a few emulators. My 48G+ gives 0 for sin(pi), but not my other HP calc (HP39gII which is kind of a simplified predecessor of the Prime), nor the HP42S simulators. As we explained in this thread, this has nothing to do with precision, but everything to do with how the sin() function is implemented.

While sin(pi), with pi an approximation of pi, should never be exactly zero for an infinitely precise sin() function, for an implementation with finite precision, everything goes.

The most common reason why you'd get zero is if sin(x) is computed modulo pi (the exact same numeric constant as the pi it gives you when you press 'pi') and the sign handled separately. Then obviously sin(pi) would be sin(pi-pi)=sin(0)=0. Yes all calcs will give sin(0)=0. That much you can be sure of. But try a multiple of pi, and see how even on those calcs, the result will not be zero anymore. As expected. For example, my HP48G+: again gives sin(pi)=0, but gives sin(2*pi)~4.135.....E-13.

Just because a given calc doesn't implement sin() this way, doesn't mean it's bad. And as we just saw, why care if it gives sin(pi)=0 but sin(n*pi) != 0?
(So to get an idea about "precision" of a given calc, try sin(n*pi) with n a large integer.
Eg.:
* on the HP42S sim., sin(1000*pi) ~ 115.8...E-33
* on the HP48G+: ~2.067...E-10
* same on the HP39gII
* what do you get with your own calc?
Which one is closer to zero?)

If you want exact values, use symbolic calculators.

[commie]

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

You say above that ieee754 fp strings cannot be represented exactly? This being the case, what does ieee754 fp actually do with the string of numbers? what does the ieee754 fp algorithm actually do?, does it hang up, approximate or output an error?

I know what the answer is, it approximates, this conversion process is inducing(albeit small) errors into the fp number before the user calculation has even started.This happens by just converting string into a ieee754 fp number format.

BCD fp, does not suffer this conversion error process because bcd is transparent to input/output conversion.

I will repeat, when using ieee754 fp does the string conversion process induce errors, yes or no?

[Siwastaja]

I will repeat, when using ieee754 fp does the string conversion process induce errors, yes or no?

This is already explained to you in great detail. Your lack of attention to people who are trying to help you is just rude. Especially Nominal Animal has spent a lot of effort in explaining all this to you, but if you refuse to think about it and just play trolling games, what more can we do? What is your actual purpose on this thread because clearly it isn't understanding how things work?

[newbrain]

This is already explained to you in great detail. Your lack of attention to people who are trying to help you is just rude. Especially Nominal Animal has spent a lot of effort in explaining all this to you, but if you refuse to think about it and just play trolling games, what more can we do? What is your actual purpose on this thread because clearly it isn't understanding how things work?

It is still growing...

[commie]

This is already explained to you in great detail. Your lack of attention to people who are trying to help you is just rude. Especially Nominal Animal has spent a lot of effort in explaining all this to you, but if you refuse to think about it and just play trolling games, what more can we do? What is your actual purpose on this thread because clearly it isn't understanding how things work?

Since you are deaf, I will repeat, when using ieee754 fp does the string conversion process induce errors, yes or no?

[Nominal Animal]

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.08333 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(10⁶), 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.

[commie]

Every IEEE-754 Binary32/64/128 value can be exactly represented as a decimal number.

Please, no more numbers,eh?, please just answer my question, here it is again,  I will repeat, when using ieee754 fp does the string conversion (algorithm)process induce errors, yes or no?

Please just answer the question, its not that hard,eh?

[Siwastaja]

Have you stopped beating your wife? Answer that first. Yes or no. Simple question.

[Siwastaja]

But really, that question is easy, after all. The answer is no.

No, it does not induce errors. There is nothing in "error" when converting or rounding numbers between different systems.

[Nominal Animal]

when using ieee754 fp does the string conversion (algorithm)process induce errors, yes or no?

No, the conversion between decimal and non-decimal representation does not induce errors.

You are stuck on the idea of a specific notation being somehow perfect, and comparing everything else to that, without any sensible reason.

The fact that conversion between decimal and non-decimal forms is approximate, does not mean one is better or more "precise" or "accurate" than the other.  The approximation is only one more mathematical tool, and is not an "error" per se.  As I showed above, the 32, 64, and 128-bit IEEE binary forms are more accurate than their equivalent decimal forms using the same amount of memory.

To repeat: Human-interfacing calculators do not use BCD/DPD/decimal representation forms because they're more precise or better in any way than binary representation forms.  With decimal representation, conversion to and from human preferred form and the storage representation is cheap, but arithmetic operations more expensive, compared to those with binary representation.  With respect to digital logic and memory needed, it turns out that the decimal representation is cheaper and simpler to implement; either way the basic arithmetic operations are going to be so fast that to a human, each single operation will be nearly instantaneous.
"Precision" or "accuracy" is a completely separate question, and is dependent on how much memory you're willing to spend per number, and how much digital logic (and read-only memory tables) to implement the built-in functions (trigonometrics, square root, exponent, logarithm, etc.) to match that precision; and really has nothing intrinsically to do with the representation used!

[commie]

No, the conversion between decimal and non-decimal representation does not induce errors.

You have stated no to  ieee754 fp conversion errors.Then you go on to state, the ieee754 fp is an 'approximate'

The fact that conversion between decimal and non-decimal forms is approximate

I am assuming that small errors equate to approximate, right? So, you are ambiguous in your answer, which is it?, an approximate, or a small errors, or no error?, because they are one of the same thing.

In maths and physics, whenever a quantity undergoes a conversion, errors are introduced in the outcome as proven by Gauss.

[Nominal Animal]

I am assuming that small errors equate to approximate, right?

No.

I know this will be immensely annoying, but "error" and "error of approximation" are two completely different things.  One is an undesired deviance from expected value, and the other is known difference to the expected value.

The key is approximation theory.  Simply put, the difference between an approximate and the exact value is known, and can be accounted for: the error is quantitatively characterized.  It's numerical value is often not known precisely, but its maximum possible magnitude is known.  Otherwise, what you have is a guess, and not an approximation.  The "error" in error of approximation refers to the difference to the exact correct value, and is bounded (its maximum possible magnitude is known).

For example, I can use an IEEE 754-2008 Binary64 to approximate any Decimal64 with magnitude between 10^-300 and 10⁺³⁰⁰ without loss of precision or accuracy.  Decimal64 happens to have a slightly larger exponent range, -383 to +384 in powers of ten, than Binary64 (about -308 to +308 or so), but that is an implementation detail, and not a consequence of using decimal basis vs. binary one.

Another example is how IEEE 754 defines rounding rules, using the default rounding mode. The maximum error allowed is less than one half of the unit in the least significant place, with exact midpoint rounded towards even.  This means that the binary representation used is not just the truncation of the exact, possibly infinitely long, binary representation of the correct value; but it rounded.

If you check my posts above, can you see how I've consistently used "[approximation] is used to represent [exact value]"?
This is at the very core of this issue.

Perhaps your mind might open, if you consider the number 0.1, one tenth, in Binary32 (32-bit binary floating-point) has 13,421,773 unique values which all yield "0.1" when converted to decimal form with one decimal digit.  Those thirteen million values define the boundaries of our approximation (for this particular value).  As long as we track the difference between the approximation and the actual value we use the approximation to represent, and that range fits within our approximation, the result will be correct to within the given precision.

If you cannot accept that you are wrong in this matter, at least please limit your opinion to the domain where it can be accepted as a rough approximation of the truth.

Something along the lines of "When working on numbers with exact decimal representations, using decimal (BCD, DPD, or base-10) representation for them is more accurate than using binary representation".  This excludes irrational and transcendental constants like e and π, as well as trigonometric functions, exponentials, logarithms, antilogarithms, and kinda-sorta division (not the kind of division that yields a quotient and a remainder).  But it does convey that for multiplication, addition, and subtraction on decimal numbers, using decimal representation yields exact results, whereas binary representations are approximations.

In all cases, the value computed for sin(π) by itself does not reliably describe the accuracy and precision of the calculator.  For that, you need to use an explicit numerical constant; for example sin(3.14159265) or even sin(3141592.65358979323846), because the calculator may be designed so that the sine function has a systematic error that compensates for the difference between the rational value of π it uses and the actual value of π.

Heck, you can define zin(x) = sin(πx/3) and then define n = 3, so that zin(n) = 0 and zin(24137n) = 0.  Nice, now we have a sine function for pi exactly three!  However, then zin(6) = 0 too, which tells you there is something iffy about this calculator.  That's why I said you find out much more about a calculator if you test its sine function with specific decimal constants, one very close to π, and the other very large – say a million or so –, and compare those to known expected values.  A calculator could easily use a zin function, where n is the value it uses for Pi, and its users might believe it is more precise than other calculators, while it really has a misleading/incorrect sine function!

[commie]

No.

please just answer my question, here it is again,  I will repeat, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, yes or no?

[westfw]

First of all, the "approximations" that occur during the conversion of decimal numbers to binary only happen because you have DECIMAL numbers; you can equally complain than 1/256 takes 6 BCD digits to represent accurately (and 14 digits for 1/(1024*1024), while each takes ONE bit in binary FP.

But Decimal (or binary) representation isn't actually REAL.  Except for quantities that are artificially quantized to decimal numbers (like money), you can provide a decimal representation that results in a binary value that is accurate to all of the bits that are there.  If it's a physical quantity, measurement inaccuracies will dominate.  If it's a mathematical constant (like Pi), you can get the "exact" binary representation to within the limits of the format, regardless of conversion issues (perhaps it means providing more digits in the decimal representation than are actually representable. So?)  (consider a value like 1/3, which doesn't have an exact representation in either decimal or binary FP.  It still has both binary and bcd FP representations that are "as close as possible"

Secondly "'where precision calculations were concerned" usually means COMPLICATED precision calculations, where the conversion steps happen at the beginning (on inexact data) and at the end (and then there are MANY MORE internal calculations (where errors can propagate), and the better precision and speed of binary FP is more useful than the easier conversion of BCD FP.

[newbrain]

[the usual correct, clear and informative content]

[commie]

First of all, the "approximations" that occur during the conversion of decimal numbers to binary only happen because you have DECIMAL numbers; you can equally complain than 1/256 takes 6 BCD digits to represent accurately (and 14 digits for 1/(1024*1024), while each takes ONE bit in binary FP.

Westfw, I have stated else where on here that bcd is extremely wasteful of ram granted, but it does remove the string of decimal to binary conversion block  and so no conversion is necessary for bcd fp io, a vast improvement in accuracy occurs.

[Nominal Animal]

a vast improvement in accuracy occurs.

No, it does not occur.

If you limit to addition, subtraction, and multiplication of exact decimal numbers, with the result not having more significant digits than your internal format supports, then using a decimal representation is exact without any extra work.  Since there are decimal numbers that cannot be expressed exactly in finite binary form (without fractions), doing the same with binary representation without any extra work, would not yield exact decimal results.

Whenever you include

• Irrational constants like e or π
• Numbers without an exact decimal representation
• Nonpolynomial functions, like exponent, logarithm, square root, any trigonometric functions like sin or cos
• Division (when the remainder of the result is nonzero)
• Rounding of any kind

that exactness is immediately lost.  Not just with regard to that term or operation, but for the full calculation.

You can also use binary representation for the decimal numbers to produce the exact same results, if the binary representation has slightly more precision and at least the same range as the corresponding decimal type, and you track the number of significant decimal digits separately.  The internal representation of the values will be approximate, but the difference between the exact value represented and the approximation will never affect the visible result, since its magnitude will always, no matter the sequence of the operations done, be less than what is needed to change the displayed result.

I can prove this all.  This also applies if you use base-K instead of decimal, and base-M instead of binary, where K and M differ.  Yes, including if we swap "decimal" and "binary".

I do not know how to express this any simpler than this.

[westfw]

so no conversion is necessary for bcd fp io,

Ok.  Conversion is easier.

a vast improvement in accuracy occurs.

But this doesn't follow.  The binary FP number will be accurate to within +/- 0.5lsb for however many bits it puts in the mantissa.  Some numbers will be exact.
The BCD number will be accurate to within 0.5*leastSignificantDigit.  Some numbers will be exact, and those will be different numbers than are exact with binary.  But in general, the binary value will be more accurate than the BCD value, because 0.5*oneBit is smaller than 0.5*OneDigit
(And in neither case is the error "vast.")

Consider Pi.
In IEEE BCD Floating point, you can get 7 digits of a number in a 32bit FP value, so Pi will be 0.3141593e1, with an error of about  3.5e-7
(this is using "dense BCD", which gets 3 digits in 10bits, which is much better than normal BCD and very close to pure binary.  A normal BCD number would either take more space or have less digits.)

For an IEEE Binary floating point number, Pi would get stored as 3.14159274, which has an error of about 8.7e-8; about 4x less than the error of the BCD value...

Code: [Select]

(gdb) set $pi=3.14159265358979323846   // a "double" Pi with more digits than will fit(gdb) print $pi
$4 = 3.1415926535897931  // (internal representation)
(gdb) print $pi-3.141593      // compare with 7digit BCD value
$1 = -3.4641020674186507e-07
(gdb) print $pi-(float)$pi      // compare with 32bit binary FP value (native 'float')
$2 = -8.7422780126189537e-08
(gdb) print (float)$pi
$3 = 3.14159274

You can do similar calculations for 1/10, the number that is infamously non-representable in binary.  The error in a 32bit number is about 1.5e-9:

Code: [Select]

(gdb) set $tenth = 0.1
(gdb) print $tenth - (float)$tenth
$6 = -1.4901161138336505e-09

[Siwastaja]

please just answer my question, here it is again,  I will repeat, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, yes or no?

Clearly it isn't here "again" because this time the question is different.

Now the answer is,

Yes, if special care is not taken by tracking number of decimals using extra code.
No, if special care is taken by tracking number of decimals using extra code.

Hope this helps.

[commie]

please just answer my question, here it is again,  I will repeat, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, yes or no?

Note, we are focusing on the string conversion only, this is before any actual user calculations have taken place.

[Siwastaja]

The simple answer is yes;

The binary form is an approximation of the decimal string. Given same memory, it has higher resolution, smaller step size, but the steps don't coincide, so the nearest one must be picked, and it will be of different value. Very very close, but different.

Because the internal steps are smaller (resolution is higher) than the input steps, with a little bit of extra code (which needs to be done right, of course!), you can guarantee that the approximation stays internal, i.e., when the string is generated again, the approximated part goes away and the output string is exactly what would be achieved with BCD or fixed point number systems. If you don't do that extra logic, then there will be a very small rounding error that is visible to the end user, and may confuse some users.

Plenty of options to do it. All are pretty accurate, none of them induce "vast" errors. The highest chances of getting relatively large errors is to try to fake results to "look" better. This bears the highest risk for serious bugs.

[commie]

The simple answer is yes;

Yeah, and what does 'Nominal Animal' say?, has he done a runner on me?

[Nominal Animal]

Yeah, and what does 'Nominal Animal' say?, has he done a runner on me?

No, I'm just trying hard to find a way to answer your question in a way that does not lead you astray.

I have already written above,

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).

and what that means with respect to a calculator:

If you limit to addition, subtraction, and multiplication of exact decimal numbers, with the result not having more significant digits than your internal format supports, then using a decimal representation is exact without any extra work.  Since there are decimal numbers that cannot be expressed exactly in finite binary form (without fractions), doing the same with binary representation without any extra work, would not yield exact decimal results.

Some of your intuition is correct: when we restrict to numbers with an exact decimal representation, and use only multiplication, addition, subtraction, and division with zero remainder.  Your conclusion from that, extending it erroneously into "decimal is more precise than binary", is what is wrong.

My only aim here – not just in this thread, but on this forum (and every other forum I've used) – is to help others.  I get a dopamine kick whenever it is obvious that I've helped someone grasp a new difficult concept, or realize (either in their mind, or physically making) something they couldn't before; including myself.  I do not get any dopamine kicks from "being right" or "getting the last word" at all, even though it seems to look that way sometimes.

I feel kinship here, because I know exactly the feeling one has when a conclusion seems irrefutably correct, and then someone says "No, that does not follow".  I know the feeling of frustration!  To me, the worst thing is when that someone does not explain why, and simply walks away.  I learn nothing that way!  I hate that, and I don't want to do that, and I don't want you to be left with an erroneous conclusion either.  Not just because of yourself, but because such conclusions so easily spread; and when that happens, we all become a little poorer.

I personally have used both binary and packed-decimal forms on microcontrollers, so I have no opinion as to which one is "better", decimal or binary.  It is just a representation, and one of my tools as a developer, that I can pick depending on the use case.

[commie]

No

You are being ambiguous again, do I take that to be 'no' to my original question below.

please just answer my question, here it is again,  I will repeat, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, with a simple yes or no?

Note, we are focusing on the string conversion only, this is before any actual user calculations have taken place.Also, please do not worry yourself about leading me astray. Your buddy 'Siwastaja' has said 'yes' to my question, what is your answer?

[SiliconWizard]

As Nominal patiently explained, it only makes a difference for numbers the significant number of digits being less than, or equal to the maximum number of digits that can be represented in the particular decimal FP format considered. So doesn't matter one bit for numbers having an infinite number of decimals, be they rational or irrational.

Decimal FP can have its uses (which is why it found its way in IEEE754:2008), as long as you know why you're using it and can justify never exceeding the max number of significant digits the decimal format you're going to use allows. Which may or may not apply, but it's usually for pretty niche applications all in all. Financial stuff comes to mind. But my own approach for this kind of applications is to use integers only, and not bother with FP.

What did not serve the OP well here, beyond a relative aggressiveness, is that they took examples that are definitely NOT good examples for justifying the use of decimal FP., and that on top of it, they took as an example a calculator that actually uses decimal FP. So yeah Nominal, I don't deny the discussion could have been interesting. But it looks like it just went all over the place in the OP's mind.

[emece67]

.

[Nominal Animal]

when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string

Like I've attempted to explain above, "With base-2 exponents (as used in Binary32/64/128), the problem is that not all decimal number strings can be represented exactly."
(That should really read "... not all decimal numbers with a fractional part can be ...", though.)

If I answered your question with "Yes", then I'd be contradicting myself, and saying that "no decimal number strings can be represented exactly in binary", which is not true.
If I answered your question with "No", then I'd be contradicting myself, and saying that "all decimal number strings can be represented exactly in binary", which is not true.

You have posed a loaded question.  I have thus far assumed that you did this accidentally, because you did not understand the argument, and have attempted to clarify.  This is what I'd like others to do to me, when I myself accidentally pose a loaded question, and do not realize it myself.  I will always rather eat humble pie and admit being wrong when shown exactly how I'm wrong, and learn from my mistakes, because doing any other thing would be intellectually dishonest, and make me poorer for it.  I will not let my ego hinder my learning, no matter how often I feel I've made a stupid error or made an ass of myself.

However, I do now have a slight suspicion that you are demanding an answer to the loaded question that you designed to allow you to claim validates your incorrect presupposition.  I will not do this, because it is rhetorical sleight-of-hand and misdirection, and I have zero interest in such social games at all.  Sometimes the correct answer is to show how the question as posed is invalid.

Before you construct another loaded question, please take the time to re-read the entire thread from a third person perspective, and take your ego out of it.  Read it as if it were completely unknown people to you discussing the issue.  See me as someone with experience in the real-world implementations trying to describe the differences, someone trying to help the asker, and not an antagonist.  Then, when you find the point where your understanding diverges from mine, describe that, and we can continue a mutually beneficial discussion here, without falling into the dirty muck-slinging of social games.

For example, if you have any interest in C programming, I could show you how arbitrary-precision arithmetic on ASCII decimal strings, BCD, Densely-Packed-Decimals, or in binary, are actually implemented.  I've done all of them at one point or another, and don't have a "favourite", because it is just one more tool in my toolbox of useful stuff.
None of them are "the most precise" or yield the most accurate results, because precision and accuracy are simply not related at all to the underlying base/radix.

[commie]

when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string

Like I've attempted to explain above, "With base-2 exponents (as used in Binary32/64/128), the problem is that not all decimal number strings can be represented exactly."

...and there are many thousands of decimal numbers which do not give an exact binary fit, what does the ieee754 conversion algorthm do then?, it gives the closest fit or approximation in binary? correct?

(That should really read "... not all decimal numbers with a fractional part can be ...", though.)

..and, for those decimal numbers that do fit exactly are very few indeed, right?

If I answered your question with "Yes", then I'd be contradicting myself, and saying that "no decimal number strings can be represented exactly in binary", which is not true.
If I answered your question with "No", then I'd be contradicting myself, and saying that "all decimal number strings can be represented exactly in binary", which is not true.

Okay, let me make yet more clear for you, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, in nearly all cases or conversions?, yes or no?

[commie]

Decimal FP can have its uses (which is why it found its way in IEEE754:2008), as long as you know why you're using it and can justify never exceeding the max number of significant digits the decimal format you're going to use allows.

Hey, Siliconwizard, why did ieee754 32/64/128 require modifying into ieee854 if the former was so good?

[Nominal Animal]

Now I'm getting angry.  This is not a conversation to discover facts, this is some kind of sick social game to twist words, and I don't like it a bit.

Pun intended.

..and, for those decimal numbers that do fit exactly are very few indeed, right?

Did you miss the part where I said that only 8 out of 1000 for three-digit decimal to binary?

The part you keep consciously ignoring because it invalidates your conclusion, is that for the inverse, 10-bit fractional binary to at most three decimal digits, only 8 out of 1024 have exact decimal representations.
There is nothing special about decimal or binary here.  We could be talking about any other base/radix, and my arguments would still be exactly the same: even if someone argued that "binary is more precise than decimal".
You believe that using decimal is more precise than binary.  I am not saying that binary is more precise than decimal, I am saying that the base/radix – binary or decimal or any other – does not intrinsically affect precision or accuracy at all.

It feels like telling two teens arguing whether black or white racing stripes make a car go faster, that their argument is invalid because the color of racing stripes does not affect the speed of the car at all; and one of them keeps demanding a yes-or-no answer to "does white racing stripes make a car go faster", because they think that a "no" answer means "black racing stripes make a car go faster" and they "win" the argument.  This is stupid, and helps nobody.

You want me to say "yes", because in your mind, it validates your conclusion.  I'm trying to show you it doesn't, because your argument does not lead to the conclusion you have drawn at all.  You would like me to play your game, but the only way to arrive at the mathematically correct conclusions is to avoid answering your loaded question with either of the two options you have provided.

This is damned annoying and makes you look like a pushy teen idiot, commie.  Snap out of it, please.  I've told you I feel kinship, because some of these concepts really threw me in a loop once upon a time, too, and I wish I'd had someone trying to explain these things to me as I am now trying to explain to you.  Otherwise I'd have blocked and ignored you ages ago, because I really, really hate these social games.  So, stop treating me as an opponent or antagonist, will you?

If I answered your question with "Yes", then I'd be contradicting myself, and saying that "no decimal number strings can be represented exactly in binary", which is not true.
If I answered your question with "No", then I'd be contradicting myself, and saying that "all decimal number strings can be represented exactly in binary", which is not true.

Okay, let me make yet more clear for you, when using ieee754 fp does the string conversion (algorithm)process produce an approximation in binary for a given decimal string, in nearly all cases or conversions?, yes or no?

How is restating your question more clear?  I've made it crystal clear (pun intended) that I refuse to play the social verbal game you have constructed.

You didn't even know about this detail at all, before I pointed it out to you in my post you already quoted.  Now you insist I must assert "yes or no" to a statement I myself told you.

Why do you insist on getting that assertion?  My understanding is that you are using this discussion as a sort of a game, and believe that if you get me to re-confirm a statement I've already made, it somehow proves your incorrect conclusion, and you "win", somehow.

I refuse to play.  Moreover, I am not writing here to you only.  I know that these threads are easily discovered by searching for related terms on the web, so many people who are pondering the related terms, will discover this thread.  Most of what I write here is directed to them, because helping a single person is much less rewarding than helping many people.  I am not playing your social word games, I am trying to write posts to help everybody reading this thread, now or afterwards, you included, to the best of my ability.

[commie]

You didn't even know about this detail at all, before I pointed it out to you in my post you already quoted.  Now you insist I must assert "yes or no" to a statement I myself told you.

Yes,I did/do know the detail of ieee754 fp and alot more besides, before engaging in tireless wasteful discussions with you. As I have stated elsewhere, Ieee754 utilizes a conversion, in which case the great Mathematician Karl Gauss, stated every conversion generates errors. Now, bcd fp on the other hand does not use a conversion algorithm and it therefore retains accuracy when  moving fp numbers in/out,i.e. keyboard/memory/display, whereby ieee745 fp is a joke.


   

[Nominal Animal]

As I have stated elsewhere, Ieee754 utilizes a conversion

No, neither IEEE 754-1985, IEEE 754-2008, nor (current) IEEE 754-2019 specify any "conversions" at all.

The standard only defines

• Binary32, Binary64, Binary128 binary interchange formats
• Decimal32, Decimal64, and Decimal128 interchange formats
• Arithmetic formats (representable real and complex numbers, infinities, and NaNs) using the above interchange formats
• Rounding rules
• Operations (arithmetic operations like addition, subtraction, multiplication, division, but also functions like square root, powers, trigonometric functions, and so on)
• Exception handling (especially divide by zero handling)

IEEE 754 does not specify how numbers are converted.  Really, all it says about the subject, is that however it is done, it should be done with less than half an unit in the least significant place of error, with exact half rounded according to the rounding rules.

Now, bcd fp on the other hand does not use a conversion algorithm and it therefore retains accuracy when  moving fp numbers in/out,i.e. keyboard/memory/display

You most certainly need to do a conversion to BCD, if the display and/or keyboard uses binary, octal, duodecimal, or hexadecimal, and not decimal.

Some of such systems currently still in use involve astronomy (where angles are in degrees, minutes, and seconds, instead of decimal degrees) and time (when time is not in decimal seconds, but as seconds, minutes, hours, days, months, and years).  Decimal is prevalent, but by no means the only one currently in use.

(In computer programs, the binary format of floating-point numbers, "a" and "A" conversions in C since C99, are used to provide exact floating point numbers in a binary basis (hexadecimal, i.e. four-bit digits, in base-16) when the exact decimal form would be excessively long – up to 768 decimal digits –, and the value should be conveyed in text form with maximum precision available.  In most cases, the hexadecimal format is transparently supported by the C library, so that wherever a decimal real number can be input, a hexadecimal floating-point format is also acceptable.  In particular, strtod()/strtof()/strtold() will do this for you, and is the recommended way to parse floating-point inputs from strings in standard, hosted environments, in C.
If you use Bash or a related shell, you can use printf '%a\n' number to convert number to the hexadecimal form, and printf '%.768g\n' number to convert to decimal form with maximum precision, with number being either decimal or hexadecimal real number.)

whereby ieee745 fp is a joke

IEEE 754 is no joke, proven by how it is supported by almost all computing environments, and there are basically no competitors for it.

(Integer arithmetic and fixed point arithmetic as used in e.g. digital signal processing is not a competitor, since they boil down to just basic integer arithmetic, and IEEE 754 has basically nothing to do with integer arithmetic.)

IEEE 754 is commonly used even by calculators that use decimal base either use IEEE 754 Decimal types; the rest use very closely related representations (DPD, in particular), and basically just cherry-pick features from IEEE 754 instead of implementing it completely.


I don't think I have anything useful to further this thread, so I will bow out in defeat here.  I failed to help. 

If anyone else happens to read through this thread, and has questions about IEEE 754 BinaryN/DecimalN or BDC/DPD/binary arbitrary-precision arithmetic, and especially implementing them and their relative upsides and downsides, I'd recommend starting a new thread in the Programming sub-forum here.  There are many members here with plenty of embedded programming experience, and the discussions can range from beginner to expert level.  As for myself, I'm most interested in the implementation side of things, as shown in my Constructing short C strings in limited or constrained situations, which we could expand into say calculators with decimal inputs and outputs, if anyone is working on that kind of stuff.

If you do start a thread there, but find my style of posts annoying/aggravating/waste of time (see e.g. Mind over bugs: C pointer edition thread for examples), just drop me a friendly private message or email with a link to the thread, with a note "Would you mind not participating in this thread?", and I will stay away.

In general, you can block me completely here so you don't need to read my posts at all, by opening your own Profile (near the top of each page), then Modify Profile, and in the pop-up lists, Buddies/Ignore lists... and Edit Ignore List.  I add members to it if I feel I cannot respond in a mutually beneficial manner because of emotions or whatever, and about once a month or two, review the list whether that is still the case, and if not, clear the list.  It, too, is just a tool, and not some sort of social game.

Disgruntled people have already added my email address to various spam lists, so there's not much point in doing that to spite me.  I've got pretty good filters for that, having had an email address since 1994.