HP 10bii+ Margin/Markup bug
|
03-23-2021, 07:51 PM
Post: #1
|
|||
|
|||
HP 10bii+ Margin/Markup bug
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?
|
|||
03-23-2021, 08:08 PM
Post: #2
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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! |
|||
03-23-2021, 08:41 PM
(This post was last modified: 03-23-2021 08:53 PM by Albert Chan.)
Post: #3
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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) |
|||
03-23-2021, 09:05 PM
Post: #4
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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:21 PM
Post: #5
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
(03-23-2021 09:05 PM)Rick314 Wrote: HP calculators keep track of which values are entered and which values are being solved for. 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 ? |
|||
03-23-2021, 09:41 PM
Post: #6
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
> 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. |
|||
03-24-2021, 02:09 AM
(This post was last modified: 03-24-2021 02:26 AM by Gamo.)
Post: #7
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 |
|||
03-24-2021, 02:42 AM
Post: #8
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 |
|||
03-25-2021, 10:53 PM
(This post was last modified: 03-25-2021 10:55 PM by ijabbott.)
Post: #9
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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) — Ian Abbott |
|||
03-26-2021, 07:15 AM
(This post was last modified: 03-26-2021 07:24 AM by Gamo.)
Post: #10
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 |
|||
03-26-2021, 09:54 AM
Post: #11
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 |
|||
03-27-2021, 07:32 PM
(This post was last modified: 03-27-2021 08:20 PM by Rick314.)
Post: #12
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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. Code: # Inp S Exp Other 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. Code: # Inp S Test Expression Code: IF(c=0 AND p=0, u - g/(1-g), Code: ! Clear Data before each use. ! Edit 1: Last table before code, case numbers 07 to 09, 05 to 11 (typos). |
|||
03-27-2021, 09:18 PM
Post: #13
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
(03-27-2021 07:32 PM)Rick314 Wrote: First, simplify variables: 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 ! |
|||
03-28-2021, 12:39 AM
Post: #14
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
> 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? |
|||
03-28-2021, 12:30 PM
(This post was last modified: 03-28-2021 12:33 PM by ijabbott.)
Post: #15
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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.
— Ian Abbott |
|||
03-29-2021, 01:08 AM
(This post was last modified: 03-29-2021 01:16 AM by Gamo.)
Post: #16
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 |
|||
03-29-2021, 04:22 AM
Post: #17
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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, 04:39 PM
(This post was last modified: 04-10-2021 12:05 AM by Rick314.)
Post: #18
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
(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). Code: # Keystrokes Solves For 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). |
|||
03-29-2021, 08:08 PM
Post: #19
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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 MAROnce 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> |
|||
03-30-2021, 07:51 AM
Post: #20
|
|||
|
|||
RE: HP 10bii+ Margin/Markup bug
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. — Ian Abbott |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: