HP 10bii+ Margin/Markup bug

[Rick314]

Thank you Gene, but I think you are defending HP too much. I am a retired HP firmware project leader with 30+ years experience, much of it in user interface design, and this is a bug. You said "Page 47-48 of the manual simply state that to use MU and MAR together, compute the CST and PRC first, then compute the other value." Nothing in that manual example says anything about the sequence shown being the only way or even the recommended way to use the feature. Also that argument doesn't apply to MU-MAR conversions, since CST and PRC are not required (and might not be known) at all. You saying "Not a bug per se, since the machine works as the manual specifies" implies that nothing is promised except the values and solving sequences given in the manual. That logic could justify any entry-solution sequence not demonstrated in the manual as being intentionally unsupported. That isn't how HP determines what a bug is. (I know.)

Thank you Albert, but I think "Both ways will give different results" is incorrect. Your first equation determines MU from PRC and CST. No problem. The second determines MU from MAR. No problem. All the following conversions are mathematically possible:

MU to MAR
MAR to MU
MU, CST to PRC, MAR (in either order)
MU, PRC to CST, MAR (in either order)
CST, PRC to MU, MAR (in either order)
CST, MAR to MU, PRC (in either order)
PRC, MAR to MU, CST (in either order)

As you read down the list, all required equations exist: MAR = f(MU), MU = f(MAR), PRC = f(MU,CST), MAR = f(MU,CST), CST = f(MU,PRC), MAR = f(MU,PRC), etc. HP calculators keep track of which values are entered and which values are being solved for. All the above should be recognized and properly programmed.