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

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