[...]but more and more recently i am going away from binary back to bcd. here are some things that increasingly bug me (and you). try, 2 enter .2 + .2 + .2 + .2 + .2 + 3 - you get 8.8818e-16 also, 1 enter 1e-13 + 1 - to get 9.9920e-14 both of these are really annoying.
I suppose it depends on what you're used to. I started computer programming on a Commodore PET, 28 years ago, and one of the first things I noticed were numerical quirks like that. And even today, programming in C or FORTRAN or Java it's the same.
I don't understand what the fuss is about. I can understand it for financial applications, I guess, but even there it's hard to see what problem would be caused by having $2 plus 5 times 20 cents minus $3 come out less than one tenth of one trillionth of a cent wrong. Presumably you're going to round money amounts to two decimals before printing your bill? :-)
But all kidding aside, outside of financial applications, all you're dealing with in the example given above is a misconception of how computers store numbers, and about the limits of precision. Personally, I don't like it very much that 1/7 + 1/7 + 1/7 + 1/7 + 1/7 + 1/7 + 1/7 does not come out as 1, but that's life, or rather, that's limited precision. Just because BCD can calculate certain special cases exactly does not make it more accurate in general, and for the scientific applications I'm primarily interested in, it's accuracy in the general case that matters.
i have an alternative implementation of the gamma function you might like, http://www.voidware.com/gamma2.htm http://www.voidware.com/gamma.htm
i see you need a ln1(x) = ln(x+1), here’s one i wrote for scicalc,
Thanks! It is much appreciated. I will also take a look at your INTEG implementation and take a look at the Numerical Algorithms book. Hopefully all those improvements will make it into Free42 version 1.1.
a few more discoveries. sin(360) degrees isn’t zero. this is a bug.
Good point. I missed that -- and there's really no excuse because only a week ago, I was reading an article about the HP-91 on the HP Museum CD set, where they mention doing user-unit argument reduction for trig functions, for preventing precisely that type of inaccuracy! Oops.
also, binary is hampering mod. for example 1e50 enter 9 mod, comes out at 3 instead of 1.
Whether or not that's a bug is a matter of perspective. If you feel that an HP-42S emulator has to go to every possible length to disguise the fact that it's using binary under the hood, then that's a bug -- but if you're comfortable with the notion of binary under the hood (I am, but I suspect I may be in the minority on that issue, at least among HP handheld fans), it's different, because the number you enter as 1e50 is stored as 1.000100011011... * 2^166, and for all I know the remainder of THAT divided by 9 could well be 3 (I'd have to check but that kind of integer algebra is beyond me, as I keep finding out whenever I try to understand how modern encryption algorithms work).
The solution you suggest works, but this does not seem to me like a problem, or rather, I prefer to do things the "binary" way throughout, so I'll stick with the current fmod()-based implementation.
Still, if enough people keep complaining about the numerical behavior of Free42, maybe I'll add support for other number representations. If there is a BCD library available under the LGPL or similar, and if it includes the full complement of trig, log, etc., then I'd certainly be interested in evaluating it.
PS. can you supply the bmp resource files to build the windows version.
When I build the Windows version, I run the make-images script to create them. You can generate them from the images in the 'common' directory simply by converting the 8 GIFs and the one PBM (for the 7 annunciators, the skin, and the keyboard mask) to monochrome BMPs while enlarging them by a factor of exactly 2.
lastly, thanks for writing this calculator!
My pleasure! I'm glad you like it, even if we may not see eye to eye in the great binary-vs-decimal debate. :-)
- Thomas