HP 10bii+ Margin/Markup bug

[Rick314]

I want to digress to a related Big Picture topic. The classic software development lifecycle is Requirements, Design, Coding, Test, Debug, Release, Support. Detailed requirements are key to minimizing iteration in the remaining steps. These 12 requirements are the foundation of this problem, and what I am guessing the calculator firmware engineers never produced.

(03-23-2021 09:05 PM)Rick314 Wrote:  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)

Once these requirements are clear multiple designs present themselves and the simplest one can be implemented. I chose a Solver solution. I think any calculator with programmable USER keys can do similarly using the following design (pseudo-code) for each of the 4 keys involved.

Code:

if <this variable can be solved for by non-zero values in the other 3>
then begin
   <solve for this variable and save its value>;
   if <any other zero-valued variables can now be solved for>
   then <solve for each of them too>;
   <recall this variable's value to the display>;
end else
   <save the user-entered value to this variable>;

Again, my point is that the calculator firmware engineers could have made the MU CST PRC MAR keys work better by realizing and solving the 12 cases that actually make sense.