Hide Forgot
xcalc, when running with the -rpn option, computes the wrong answer when an operand is less than one. For example, the result of 5 ENT 3 ENT 0.1 * - is 2.7 whereas mathematically, this should be 5 - (3 * 0.1) = 4.7 Note that 5 ENT 3 ENT 2 * - gives the correct answer. It appears that entering a number less than one corrupts the stack, duplicating the previous operand (in the example, 3 is used as an operand in the multiply and the subtract). Entry Stack 5 0 0 0 ... ENT 5 0 0 ... 3 5 0 0 ... ENT 3 5 0 ... 0.1 3 3 5 ... OOPS! - 3 5 0 ... In fact, if one types in the 0.1 and then uses the "<-" key to erase the 0.1, the "3" is already duplicated on the stack.
I think I found the fix for the bug #7795 I reported yesterday. I found that there was a difference between decf() and eef() in math.c, and when I made the change, the calculator seems to function properly. The comment for lift_enabled on line 96 is not very helpful, but I think it determines whether the stack should be "lifted" when certain keys are pressed. The diff is very simple: krylov:contrib/programs/xcalc->diff math.c math.c.orig 400c400 < if (rpn && lift_enabled) --- > if (rpn)
I found two more bugs in xcalc that I fixed. 1) From the man page: BUGS HP mode: A bug report claims that the sequence of keys 5, ENTER, <- should clear the display, but it doesn't. This is how _my_ HP calculator works. Admittedly, it's an 11C rather than the 10C that's supposedly being emulated, but I think the behavior is the same. 2) If you use the backspace in rpn mode to erase a decimal point, the flag that prevents two decimals in a number is not cleared, so you can't enter the decimal point after correcting it. The complete diff for these and the original bug is below. -Geoffrey krylov:contrib/programs/xcalc->diff math.c math.c.orig 377,378c377 < if (entered!=1) { < clearf(); --- > if (entered!=1 || clrdisp) 380,385c379 < } < if (clrdisp) < return; < if ((int) strlen(dispstr) > 0) { < if (dispstr[strlen(dispstr)-1] == '.') < Dpoint=0; --- > if ((int) strlen(dispstr) > 0) 387d380 < } 407c400 < if (rpn && lift_enabled) --- > if (rpn)
fixed for next release.
I've applied your patches to the X11R6 in rawhide. However, this bug still appears to persist. If you have a chance, please look at the X11R6-contrib-3.3.2-7 package in rawhide in the next couple of days and give me your thoughts.
closed due to lack of additional feedback. Please reopen if you have more information.
Apparently, I didn't submit all the diff's in my previous reports. There are a few more lines below than in my last report. % diff math.c math.c.orig 3d2 < * $MIT: contrib/programs/xcalc/math.c,v 3.2 1999/12/14 18:53:00 gjcoram Exp$ 18,19d16 < * < * Geoffrey Coram fixed most of the HP mode bugs. 316,317c313,314 < entered = 2; < clrdisp++; --- > entered = 2; > clrdisp++; 325c322 < clrdisp++; --- > clrdisp = 0; 330,331c327,328 < entered = 2; < clrdisp++; --- > entered = 2; > clrdisp++; 369d365 < memop = keynum; 381,382c377 < if (entered!=1) { < clearf(); --- > if (entered!=1 || clrdisp) 384,389c379 < } < if (clrdisp) < return; < if ((int) strlen(dispstr) > 0) { < if (dispstr[strlen(dispstr)-1] == '.') < Dpoint=0; --- > if ((int) strlen(dispstr) > 0) 391d380 < } 411c400 < if (rpn && lift_enabled) --- > if (rpn) 814d802 < memop = keynum;
Also, the man page should be updated, since the bug report in the old man page has been fixed. % diff xcalc.man xcalc.man.orig 425,426c425,426 < HP mode is not completely debugged. In particular, the stack is < not handled properly after errors. --- > HP mode: A bug report claims that the sequence of keys 5, ENTER, <- > should clear the display, but it doesn't.
fixed in rawhide, pkg. version X11R6-contrib-3.3.2-11 and later.