I looked into the source code for the wp34s and discovered something that I had not been familiar with before. The IEEE came up with a cool way to store 16 decimal digits with an exponent of 10^+384 to 10^-383 into only 64bits. This format is defined by the IEEE 754 specification and with it the wp34s does all of its decimal calculations on base 10 decimal digits directly!

The reason many floating point libraries and older calculators get all of these inaccuracies is because they compute things in the floating point binary number system, then convert the answer back into decimal digits at the end where rounding errors creep in.

When you try to represent a decimal number in a binary number system
the least significant 2 or 3 digits can get errors in them.
This is because the binary representation does not accurately translate into decimal numbers for every digit.

The wp34s keeps it's full 16-digit decimal numbers in a decimal format for each and every digit THROUGHOUT EVERY STEP of
every calculation, so there are almost never any rounding errors.

At least there are no errors that result from converting numbers
to and from decimal and binary.

If you are curious as to how the wp34s fits 16 decimal digits and an exponent of 10^+384 to 10^-383 all into a 64 bit space look at this
nice page on
Wikipedia Decimal64

When you put your wp34s into Double Precision mode with [h][mode]DBLON it uses the Decimal 128 format where it fits
34 decimal digits plus an exponent of 10^+6144 to 10^-6143 all
into 128 bits. Wikipedia Decimal128 I find this technology fascinating.

Thanks for making the wp34s so accurate!

Edited: 4 Aug 2013, 1:52 a.m.

Actually, most calculators use BCD, just not with 64 bits.

Quote:

---

Thanks for making the wp34s so accurate!

---

Quote:

---

I looked into the source code for the wp34s and discovered something ... ... ...

---

Quote:

---

If you are curious as to how the wp34s fits 16 decimal digits and an exponent of 10^+384 to 10^-383 all into a 64 bit space look at ...

---

Quote:

---

When you put your wp34s into Double Precision mode with [h][mode]DBLON it uses the Decimal 128 format where it fits
34 decimal digits plus an exponent of 10^+6144 to 10^-6143 all
into 128 bits.

---

Quote:

---

I find this technology fascinating.

---

d:-)

We're using the decNumber library of which the decimal64 and decimal128 formats are part of. Computations aren't executed directly on the decimalXXX objects, they are transformed into decNumber objects. The latter are much more memory consuming but have important advantages: easier access to the digits, signs and flags, and arbitrary precision. The decimalXXX format is used for storage of numbers in registers because it's more compact. We are loosing some digits in the process because internal computations are done with even higher accuracy (typically 39 digits, sometimes more) and the results are converted back to 16 or 34 digits, depending on the register size.

To be precise, we skipped a memory consuming step in the conversion and are using a slightly simplified method to encode three digits into 10 bits. We are actually using a base 1000 format with a base 10 exponent. It's still named decimal64 or decimal128 internally but you cannot directly exchange the data with other applications using the original encoding.

Edited: 4 Aug 2013, 3:51 a.m.

And those that do use 64 bit BCD arithmetic (the twelve digit HPs e.g.) don't use a tightly packed format like the 34S.

This is a trade off. Alpha strings cannot be distinguished from numbers using packed decimals like they can on the 41 series. Likewise, matrix descriptors cannot be distinguished from numbers like they are on the 15c.

- Pauli

Yes but most calculators don't incorporate the advanced rounding rules that are incorporated into the wp34s! Rounding can make a
big difference, causing the Least Significant Digit to be wrong in many cases. Take a look at the HP-15C. It frequently gets the Least Significant Digit wrong giving values such as 4.999999999 , or 5.000000001 instead of 5.0.

I never see these rounding inaccuracies on the wp34s.

I read the manual, and didn't find the description there as comprehensible as the Wikipedia article referenced above.

It made sense to me after stumbling upon the Wikipedia article, but still seemed confusing when I tried to interpret this theory directly from the manual. I am not saying that the manual isn't well written, only that occasionally looking at something from another perspective
can often unlock the missing pieces of a complete understanding.

Thanks again for creating this open-source collaboration!

This calculator is a good example of what mankind can do when
he cooperates with his fellow man seeking excellence over profit!

I think we have all sensed that Hewlett Packard isn't the company
it used to be. They used to build-in this kind of care and they
used to STRIVE for excellence in their products.

I miss that kind of workmanship, and it's obvious that the creators
of the wp34s built the kind of calculator that they think HP would
have built with today's technology, if they still cared about excellence the way they used to.

Edited: 4 Aug 2013, 9:57 a.m.

Base 1000 cool! That seems MUCH simpler than the IEEE 754 method of encoding 3-digits into 10-bits. Very cleaver. When too many people try to decide things that are to be a standard in a big committee it always seems to be more bureaucratic and less innovative.

Thanks Marcus for the description of how it's actually done in the wp34s.

This calculator reminds me of an onion. The more layers I unwrap (comprehend) the more layers of cool technology I find beneath them.

Edited: 4 Aug 2013, 9:53 a.m.

Quote:

---

Take a look at the HP-15C. It frequently gets the Least Significant Digit wrong giving values such as 4.999999999 , or 5.000000001 instead of 5.0.

---

Dieter

Quote:

---

I think we have all sensed that Hewlett Packard isn't the company
it used to be. They used to build-in this kind of care and they
used to STRIVE for excellence in their products.

I miss that kind of workmanship...

---

Yes. Workmanship like the 'excellent' Woodstock battery charging calculator self-destruct system, the early Spice PCB problems and Spice battery compartment flimsiness, HP-67 potential damage if used with AC charger but no battery, Clamshell battery compartment defects, etc. All of them retailed at very high prices.

I used an HP for the first time in 1972, when the HP-35 showed up at the Georgia Tech Bookstore. Having experience with HP from the beginning, I don't buy the mythology of HP perfection in "the good ol' days". I very much like my 1988 HP42S and 2006 HP 50G, and I'm looking forward to the 2013 HP Prime.

Example of rounding errors in HP-15C!

Using the HP-15C, put the 2x2 matrix 1234 into matrix A and take the inverse of
it and put it into Matrix B then take the inverse Matrix B and put it
into Matrix C. Then look at the rounding errors in Matrix C.

You get 1.000000001,2.000000001, 3.000000002, 4.000000002

On the wp34s you get exact values with no rounding errors doing
the same thing.

Edited: 4 Aug 2013, 1:38 p.m.

I have an original HP-35 and when HP discovered that they had made a mistake in the firmware (2.02 ln e^x showed 2.0), they offered to repair it for free! This kind of customer care does not exist anymore!

This is what I was referring to when I said that HP isn't the company that it used to be.

Edited: 4 Aug 2013, 1:44 p.m.

The HP-35 launched at $395 in 1972 which works out to be over $2000 in today's dollars.

The cost of a product does factor into the decisions any company makes about the level of support they offer. It isn't really valid to compare HP's support for the original HP-35 to its support for today's sub-$200 devices.

Well, that's easy to explain. On the 34s, most internal calculations are done with 39-digit precision, sometimes even more, and even the XROM-coded functions use 34-digit precision. Since the matrix routines always return single-precision results, there are 39 minus 16 = 23 (!) additional guard digits. Plenty of room to cover roundoff errors. ;-)

Compare this to just 3 (three) additional digits on most HP machines (e.g. HP-15C = 10 digit display => 13 digits internal precision). So 9 correct digits out of 13 used internally does not look too bad to me.

If the results of the 34s matrix functions could be examined in all of their 39 internal digits, you should not be surprised to see some roundoff errors in the 35th digit either. ;-)

Dieter

Quote:

---

If the results of the 34s matrix functions could be examined in all of their 39 internal digits, you should not be surprised to see some roundoff errors in the 35th digit either. ;-)

---

d:-)

The matrix routines are more complicated. True, the full internal 39 digit precision is used for basic computations, however many intermediates are stored and accumulated in 34 digit precision to conserve the very limited RAM.

- Pauli

Encoding 3 digits in ten bits is base one thousand still. This is one case where the standard is extremely well thought out.

Read about the history of the IEEE 754 standard. Although, politics was involved, the technically best solution made it in the end. Interview with Kahan and lots of documents from his web page. The IEEE 854 standard continued making the right decisions and was subsequently reintegrated back into the 754 standard as the base ten implementation.

- Pauli

Edited: 5 Aug 2013, 6:13 p.m. after one or more responses were posted

While it is true that the calculator was expensive for that time period, I don't believe HP has been as magnanimous, even with it's expensive products lately. I like the HP-30B, it makes a good platform on which to build the wp34s, but I remember back to he 60's and 70's where the name HP was synonymous with "HIGH QUALITY TEST EQUIPMENT". Today, I can find better quality products at cheaper prices than what is provided by HP in most cases.

I stand by my assertion that Hewlett Packard isn't the Pillar of Integrity and Quality that it once was.

I still contend that the wp34s IS MORE ACCURATE than the HP-15C!

Weather the wp34s is more accurate because it shows 12 of 16 digits
by default, or because some operations are performed to 39 digits
of precision only supports my claim that the calculator SEEMS MORE ACCURATE to the end user.

I also believe that the sophisticated user configurable rounding rules shown on page 110 of the printed manual further support the
claim that the authors are STRIVING for maximum accuracy with minimum rounding issues.

It don't see why this issue should be disputed.

Edited: 4 Aug 2013, 9:38 p.m.

I think what Marcus said about using base 1000 encoding
to represent the 3 digits into 10 bits is simpler than the complex encoding table shown in the IEEE754 spec. Marcus encodes the
3-digits 0-999 as hex values 0-3e7h which still gives 3 full digits in 10-bits, but doesn't require all of the table lookups that are needed to decode the declet encoding as shown in the IEEE754 spec.

I concur that the remainder of the IEEE754 spec is very cleaver and yields maximum number ranges in a minimum of bits.

But I can also see why Marcus deviated from the spec in this one area as it vastly simplifies the declet encoding and decoding process.

The densely packed decimal encoding is also very clever and provides a number of benefits when used. In the 34S, we didn't need any of these and we saved a kilobyte or two of flash. It really isn't complex, it involved a single table look up per ten bits when converting either way.

For us, by far the largest benefit was the space saving. It would have been nice to be able to say we support the IEEE standard at the bit level, but we don't. Our arithmetic is equivalent otherwise but we really needed the space.

- Pauli

Hi,

Please see that the links in your post are not working. If possible, please suggest alternative ways to access such interesting materials.

Thank in advance, and - of course - for your work in the wonderful HP34S.

Best regards,

Quote:

---

Please see that the links in your post are not working.

---

Interview with Kahan and lots of documents from his web page.

Franz