The October 2011 HP Solve newsletter is now available here. It was included in the HHC 2011 proceedings and I read it covertocover on the plane back from San Diego. Thanks to Richard Nelson to putting this together.
Dave
HP Solve #25 available


« Next Oldest  Next Newest »

▼
09282011, 10:36 PM
The October 2011 HP Solve newsletter is now available here. It was included in the HHC 2011 proceedings and I read it covertocover on the plane back from San Diego. Thanks to Richard Nelson to putting this together. Dave ▼
09292011, 01:44 AM
Not there, as far as I can tell. ▼
09302011, 11:57 AM
▼
10012011, 01:18 PM
So, finally I have read through (almost) the complete last issue of HP Solve  this time with no less than 75 pages. Much information, many topics... and some thoughts and remarks I would like to discuss. ;) Page 7 has a picture showing a 15C LE in space being "back by popular demand"  in five different languages. According to the comment on the next page I assume this ad will be used internationally as a part of the "15c PR campaign". I cannot comment on the French, Spanish and Dutch version of "bring it back", but I can say that the German version has three errors in its three words: it's not "Bringe es zuruck!" but "Bringt ihn zurück!". Which leads to the question if there really is not a single person at HP that is familiar with these languages. I would also like to ask this because my German HP35s manual does not compare favorably with the ones I got with my 34C and 41C back then. Page 26: "The HP41 SIGN function was “defined” differently, and they had to add two steps for each time it was used in the routines. (...) It makes you wonder what the HP41 developers were thinking. Was there some hardware restriction?" There is no secret why the '41 has its signfunction implemented this way. The reason is found in the manual and it also has been discussed here a few weeks ago: a zero result is reserved for x containing alpha data. This way the '41 can distinguish between numeric and alpha values: "ABC" ASTO X SIGN returns 0. Page 61: "Calculator Forensics". "The idea is that the functioninverse is supposed to return the input, in this case 9 degrees. Supposedly the more accurate calculator (overall?) is the one that is closest to 9". But is this really true? Even a perfect calculator with 10, 12 or 16 digits will not return the original input in simple cases like [9] [ln] [e^{x}]  the result will be "off" by several ULPs. And that's fine because this is the only correct answer. So there is a characteristic perfect result for the operation sequence used in the "calculator forensics" test, and this result usually is not 9... unless the calculator uses at least five additional guard digits it doesn't display. ;) For a 10digit device the perfect result is 9,00 041 740 3  and that's exactly what most 10digit HPs will return. For a 12digit machine it's 8,99 999 864 267 as returned by the 32s, 42s and others. The 35s here returns 8,99 999 986 001 which is closer to 9 (BTW, the deviation is just 1,4 E7). But in fact the accuracy is not better than that in the 32s/42s result, actually it is even slightly worse  the problem here is the inverse tangent where the correct result is 0,999 996 272 743 53... which should be rounded up to ...744 while instead the 35s rounds it down to ...743. In other words: closer to 9 is not always better. It may be worse just as well. The actual accuracy can only be judged by comparing the result to a certain characteristic value for a ndigit machine (which usually is not exactly 9). This point is also mentioned by the "inventor" of the calculator forensics test himself: Mike clearly sees that after the cosine calculation there is always a loss of about five significant digits, which is independent of the calculator. So it's clear the perfect result usually is not 9. Okay, it can be 9 if the calculator uses at least five guard digits throughout the whole calculation. ;) Page 67: "For 10 digit calculators the guard digits are usually two". As far as I know (except some early midseventies models) it's usually three digits for the 10digit machines as well. The reason why only 12 digits of Pi are displayed simply is its 13th (rounded) digit which is zero: Pi ~= 3,14 159 265 359 0. ;) What I would like to ask here is this: on the one hand there is a limited number of digits the calculator works with. In most 10digit machines that's 13 internal digits. On the other hand there is a certain number of digits of Pi stored internally, which may be 13, 24 or even 31 digits. How does this affect the accuracy of the trig functions? Why does sin(3,141592653) on a classic 10digit HP return just 5,90 E10? Does the internal algorithm simply evaluate Pi  x ? And, if the 35s actually uses 24 internal digits of Pi, why does it only return 6 digits for sin(3,14159265) = 3,58 979 E7. Add just one more digit to the argument to get a full precision result: sin(3,141592653) = 5,89 793 238 463 E10. Why? Final question: the WP34s internally uses 39 digits, 16 digits are returned and usually 12 digits are visible in the display. How many guard digits does it have? ;) Dieter ▼
10012011, 04:55 PM
Quote:The answer is 4. Guard digits are available to the user but not shown in the display. The internal precision is independent from this. The 41C has no guard digits but can compute to more digits (13?) internally. ▼
10022011, 10:09 AM
If guard digits are available to the user but not shown in the display, most HPs do not use guard digits at all. This does not match the usual definition by HP who claim that (most of) their calculators use three "guard digits". Which definition now is correct? And why? ;) Dieter
10032011, 05:58 AM
Quote: The French version is also wrong, and actually hilarious! "Retourné" means "turned over" (tarte Tatin anyone?); What it should have been is "De retour". Funnies aside, this is a bit poor. If anyone should use "foreign" languages, they could at least check that it's correct. Oh well, at least they got the "é" right on "retourné", and it made me smile ;) 