HP Forums

The HP 10bii+ has MU CST PRC MAR (markup, cost, price, margin) keys. Only certain entry and solve-for sequences are allowed when mathematically the solutions are available. For example (ignoring percent conversions) MAR = MU/(1 + MU). But entering MU and solving for MAR gives an error. Similarly, MU = MAR/(1 - MAR). But entering MAR and solving for MU gives an error. As another example, from page 48 of the user manual, enter 9.6 CST 15 MU and solve for PRC = 11.04 and MAR = 13.04 (OK so far). But start over (C ALL) and try to solve for MAR before solving for PRC. You get an error, even though MAR is known from the entry of MU alone. My guess is that this is because of the way the firmware is using the HP SOLVE app that is inside many of their calculators. They are not keeping track of all possibilities of what can be determined from the values provided. I don't have an HP 10bii (without the +) but would guess the problem exists there too. Or am I misunderstanding something?

While true that MU and MAR can be computed one from another, I think the original 10B and then the two 10BII models never implemented that relationship.

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.

Not a bug per se, since the machine works as the manual specifies, but it could have been implemented to compute it as you point out.

The overriding concern with the HP-10BII+ was to not break any existing 10BII legal keystroke functionality with the addition of new functions. Going back to rewrite the MU and MAR calculations was not considered, AFAIK.

Good catch, however!

Hi, Rick134

You have 2 ways to compute MU:

PRC = CST * (1+MU%)                                    → MU% = PRC/CST - 1
PRC = CST * (1+MU%) = CST / (1-MAR%)        → MU% = 1/(1-MAR%) - 1

2 ways may give different results.
Thus, I believe MU via MAR formula were disabled, on purpose. (vice versa for MAR via MU)

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.

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

The problem is CST/PRC/MU/MAR cannot be reduced to 1 formula (unlike TVM)

If user inputted CST, PRC, MAR, and wanted MU, what is it supposed to return ?

> The problem is CST/PRC/MU/MAR cannot be reduced to 1 formula (unlike TVM)

That is true Albert, but it is not a mathematical requirement. That is why I said "My guess is that this is because of the way the firmware is using the HP SOLVE app that is inside many of their calculators. They are not keeping track of all possibilities of what can be determined from the values provided."

> If user inputted CST, PRC, MAR, and wanted MU, what is it supposed to return ?

That isn't a real-world problem, whereas all cases in my list are. Try your example on the calculator, in the order given. After entering CST and PRC, enter MAR. Stop. What are you trying to do and what do you expect? MAR is determined from CST and PRC, so isn't then a valid input in addition to CST and PRC. Yet it is accepted without error by the calculator. So at that point you don't know what the calculator will use to calculate MU. You have an inconsistent (yet accepted without error) set of inputs. But it doesn't matter since entering CST, PRC, and MAR doesn't make sense.

I have noticed this ERROR too.

When input CST follow by MAR will not

return correct result if follow by MU directly.

CST, MAR → MU // Error
-------------------------------------------------
So I have try to program this Pricing Calculations to
various HP programmable calculators.

This program can calculate between MU and MAR and
almost any combinations of two input with only the exception is
the two input is MU and MAR will not give result for CST, PRC

Here is the link to my post

https://www.hpmuseum.org/forum/thread-15092.html

Gamo 3/24/2021

Just noticed that the HP Prime also give same error when

Input Cost and Margin press solve return Error: 0/0

Example: Cost=55, Margin=45

Answer supposed to be Markup=81.82, Price=100

If input Price and Margin will get answer no problem.

Gamo

One way it could have been done would be to treat MAR and MU as different views of the same variable. Solving for either MU or MAR would still be based on CST and PRC, but solving for MU would solve for MAR at the same time (and vice versa). Also, inputting MU would automatically calculate MAR (and vice versa). After inputting or solving for one, you could RCL the other without solving.

For example:

25 MU (input markup on cost)
RCL MAR (recall margin on price -> 20)

Or:

100 CST (input cost)
125 PRC (input price)
Then,
MAR (solve for margin on price based on CST and PRC -> 20)
RCL MU (recall markup on cost -> 25)
Alternatively,
MU (solve for markup on cost based on CST and PRC -> 25)
RCL MAR (recall margin on price -> 20)

Seem like HP use the Equations Solver for when input two knowns variables
will give result to the remaining two unknown variables.
But will not work for all cases espectually when input CST, MAR → MU, PRC

My program for the HP-12C the algorithm use is when one of the MU or MAR is known
go ahead and convert it then calculate the remaining formula. This method is effective
when user run through the input in series thinks of this like the Ohm's Law program.
User input either in the store register or input all in the stacks and put in zero for the varibles
that need to be solve.

For example:
Cost = 0 // Unknown
Price = 10
Markup = 25
Margin = 0 // Unknown

The Markup is known then convert to Margin
Now got result on both Markup and Margin calculate the remaining formula.

Remark:
But when I try to program this Pricing Calculations to like HP-11C it is very complicated
to imprement all the neccessary situations for all cases with Cost, Price, Markup and Margin.
Took me a long time to get it right and it need to use the "Flags" function extensively in program.


Gamo

According to the HP-10BII+ manual on Appendex B:

Business Percentage formula

MAR = [(PRC - COST) ÷ PRC] x 100
MU = [(PRC - COST) ÷ COST] x 100

Maybe HP use this two formula together with SOLVE function.

I put this two formula to HP Prime SOLVE app and do calculations.

When input two variables with Price and Margin press [Solve]

Error Message said "Cannot find solution"

Gamo

I think this provides an HP 200LX HP CALC Solver function that solves all markup, cost, price, margin (MU CST PRC MAR) problems, finding all possible solution variables by solving for any possible solution variable. It requires that all 4 variables start as 0, then only meaningful situations be solved. I believe this could have been put in the HP 10bii and HP 10bii+ firmware. First, simplify variables:

c = CST
p = PRC
u = MU/100
g = MAR/100

Next, there are only 12 meaningful input-output cases. # = case number, Inp = Input(s), S = Solve for, Other = remaining variable to solve for.
A long nested if-then-else statement is used, based on the S() function and inputs being zero or non-zero. For example S(u) means the user is solving for u. "S(u) & c & p" means the user is solving for u and both c and p are non-zero. The order of cases is important! SOLVER solves by iterating the variable being solved for, searching for a 0 in the expression provided. Consider the 3 S(u) cases. After "S(u) & c & p" is known to be false, it must be true that either c or p (but not both) is an input. In the "S(u) & c" case, once p is defined during its first iteration, further iterations happen in the "S(u) & c & p" case. SOLVER also evaluates the L(var,exp) function (let var have value exp) before any other operators.

In the following table, #, Inp, and S agree with the table above. In the S column the variable in () is the Other variable in the table above. Test shows how SOLVER will identify the case given, in order. [] indicates things that are known, due to prior IF clauses failing, so they need not be tested for. Expression is what SOLVER will try to set to 0.
The above table leads to the following HP 200LX SOLVER function.
That is what I used for development and test. Changing variable names and ordering them as they are on the HP 10bii+ results in the following HP 200LX Solver function.
This development was done using a Windows 10 PC with DOSBox and the 16-bit HPCALC application that is included with the HP 200LX Connectivity Pack. The c p u g function was tested using c=4, p=5, u=0.25, g=0.2 (12 test cases). The MU CST PRC MAR function was tested with MU=25, CST=4, PRC=5, MAR=20 (12 test cases).

Edit 1: Last table before code, case numbers 07 to 09, 05 to 11 (typos).

(03-27-2021 07:32 PM)Rick314 Wrote: [ -> ]First, simplify variables:

c = CST
p = PRC
u = MU/100
g = MAR/100

It might simplify more, with g = -MAR/100. This make equations symmetrical:

p = c + c*u = f1(c,u)
c = p + p*g = f1(p,g)

u = (p-c)/c = f2(p,c)
g = (c-p)/p = f2(c,p)

u = -g/(1+g) = f3(g)
g = -u/(1+u) = f3(u)

(03-25-2021 10:53 PM)ijabbott Wrote: [ -> ]One way it could have been done would be to treat MAR and MU as different views of the same variable. Solving for either MU or MAR would still be based on CST and PRC, but solving for MU would solve for MAR at the same time (and vice versa). Also, inputting MU would automatically calculate MAR (and vice versa). After inputting or solving for one, you could RCL the other without solving.

I like this idea.
Looking back above formulas, we might need the "other view" anyway !

> It might simplify more, with g = -MAR/100...

I don't think that will simplify the final solution.

>> ...treat MAR and MU as different views of the same variable...
> I like this idea.

I don't think this is an implementable Solver concept. But in any case, it would be great if anyone can provide a simpler complete solution to the problem: On any HP calculator, a Solver function (so limited to that tool) that solves all markup, cost, price, margin (MU CST PRC MAR) problems, finding all possible solution variables by solving for any possible solution variable.

Anyone have a simpler way to do that?

Even though margin/markup conversions are slightly suboptimal on the HP 10bii+ (requiring a dummy value for cost or price and solving for the other), at least we can gloat on the fact that this is much better than the TI BAII Plus, which has separate worksheets for "profit" (cost / price / margin) and "percentage change" (old (cost) / new (price) / %change (markup)), with no interaction between the two.

This can be done on the HP-12C with all possible conditions as shown in the clip below.

This same program can make minor change to have user input each four variables

to the TVM functions keys directly to store each variables instead of input all in the stacks.

Clip: https://youtu.be/4n4PA-PgyYs

Gamo

Here is the full version work on the Free42 PC the HP-42S simulation.

This program work on all possible cases including the conversion between MU and MAR.

Program also do the profit calculations as well.

Video Clip: https://youtu.be/yZ785nIjCMo

Gamo

(03-29-2021 01:08 AM)Gamo Wrote: [ -> ]This can be done on the HP-12C ...

Gamo: Sorry, but what you demonstrated does not solve the proposed problem. Maybe that problem isn't clear.

Quote:On any HP calculator, a Solver function (so limited to that tool) that solves all markup, cost, price, margin (MU CST PRC MAR) problems, finding all possible solution variables by solving for any possible solution variable.

This is a user interface problem, not a problem with making a programming language do the required mathematics using additional keys and keystrokes.

The main point of the thread is that HP firmware engineers could have made the MU CST PRC MAR keys on the HP 10bII+ (and other calculators) work as users expect instead of giving errors for valid input-output cases. Specifically, once the 4 variables involved are cleared to zero, these 12 keystroke sequences must work (plus entering the inputs in any order).
That is what the provided HP 200 LX solution does, and all Solves For values are visible immediately after the last keystroke. If implemented on a calculator with a 1-line display (like the HP 10bII+ or 12C or 42 or ...) then doing the additional keystrokes "RCL <second Solved For variable>" would also be allowed. But that's it. No use of any additional keys or keystrokes.

4/9/21 error correction: "02 20 MAR 4 CST MU -> MU, PRC" (corrected) was "02 25 MU MAR -> MAR" (error, duplicate of row 05).

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.
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.

On the HP-17BII (and HP 17bii+), there are separate menus for solving COST, PRICE, M%C (markup on cost), and COST, PRICE, M%P (markup on price, i.e. margin). They share variables with each other, so as long as COST and PRICE have values, they can be used to convert between margin and markup.

It would be nice if they added a third menu for solving M%C, M%P not based on COST and PRICE, but with the variables shared with the other two solver menus.

The HP-17BII (and HP 17bii+) have the ability to solve equations stored by the user, so it is easy to add a formula to convert between mark-up and margin, but there is no way to access or modify the variables used by the built-in conversion functions using this method.