Bug: HP Prime can't do Log's

[davimle]

I bought my daughter (who is a Sophomore in H.S.) an HP Prime when she needed a graphing calculator, instead of the TI-84 that is recommended (and used by everybody else in her class), partly because it seems to be a superior machine (touch screen, graphing speed, display, CAS mode, etc.) and partly because my wife and I are both engineers and we both loved our HP 28S calculators from our days at the university.

However, aside from the fact that the HP Prime doesn't solve quadratics as easily as the TI-84, we have run into what seems like a pretty basic bug (which may be a deal-breaker). The Prime can't do Log's of arbitrary base and get the right answer! Luckily my daughter is pretty good at math and pointed out to me that the calculator is not getting the right answer, rather than blindly believing the result. This can be quite a pain in more complex formulas, and also leads me to question what else does the Prime get wrong?!

Here are some really simple examples: (Again, math that underclass students in H.S. should get right.)

Log(base 3) of 81. Answer should be 4. (81 = 3^4)
Log(base 5) of 125. Answer should be 3. (125 = 5^3)

However, this is what the Prime returns:

Code:

  LOG(81,3)  = 3.99999999999
  LOG(125,5) = 3.00000000001

When suggested by HP support, switching to Engineering or Scientific display mode, it seems to get the right answer:

Code:

  LOG(81,3)  = 4.00000000E0
  LOG(125,5) = 3.00000000E0

However, since fewer digits are shown, this just seems to be a case of rounding. (e.g. with the first one, doing ANS - 4 returns -1.00000000E-11 just as one would expect.) So this doesn't feel like the a real solution. In addition, my daughter hates Scientific or Engineering mode and immediately switched it back to Standard. I have not had much luck with HP Support, in fact one representative insisted that the answers returned by the calculator were correct and that they were simply more precise. It's a shame that people in the US can't do math, perhaps this is one area where having support outsourced to India would mean getting someone who knew what the right answer was?

Both the market leader (TI-84) and a low-cost alternative (Sharp) calculator return the correct answer to both of these examples. It makes me sad that the HP Prime cannot. It is even more infuriating that HP support doesn't seem to understand that a calculator that can not calculate a correct answer is not worth much (even with color, fancy touch screens, etc.) In the area of math, there still is a right vs. wrong answer, rather than just being "opinion" or "close enough" unlike so many other things these days. (Anybody else remember Pentium FDIV?)

So I wanted to know: 1) Has anyone else run into this problem? and did HP seem to understand the gravity of the situation? and perhaps more importantly 2) Have others gotten wrong answers to other calculations that we should know about?

Thanks in advance. I'm currently torn between waiting and hoping that HP will come up with a fix, or returning the calculator as defective and being a "sheep" by getting my daughter a TI-84 Plus CE.

[Han]

If you are looking for exact results, why not use the CAS?

Quote:However, aside from the fact that the HP Prime doesn't solve quadratics as easily as the TI-84

Roots of 2x^2-x-1 --> proot([2,-1,-1])

Seems pretty easy enough I would think.

[cyrille de brébisson]

Hello,

Precision is, as always, touchy when one talks about floating points.
The classical example of 1/3*3 comes to mind (should return 0.999999... on all numerical calcs that do not try to doctor the results or mic numerical and symbolic. Hence, could claim that no calc can do math)...

Prime does give the correct answer to LN(81) and to LN(3) (within the calculator 12 digit accuracy). And dividing these 2 answers by each others do indeed yield 3.99...99).
What is 'funny' is that removing 2 digits of accuracy to these results and doing the division, will yield (after rounding), 4. A 'more precise result'.

So, we are in the 'interesting case' where more precision returns a less accurate result, and less precision will return a more accurate result.

This is, as noted above, a normal occurrence of floating point arithmetic.


People do tend to forget that Floating point arithmetic is rarely exact (the cases where it is are, from a statistic standpoint, rare). But is designed to be self consistent and to avoid accumulation of errors on long calculations.


Now, of course, as stated by someone earlier, if you want 'exact' math (not precise, but exact), then you can use the CAS where logb(81,3) will return 4. You can find logb in the template menu/key (next to the x,t,theta key).

> "In the area of math, there still is a right vs. wrong answer"
This can (and often is) debated, and is a very interesting question all by itself!
Everyone would agree that, in lots of math problems, there is not 'a right answer', but 0 to n right answers to a question (some questions do not have answers, and some do have more than 1)...
I am pretty sure that they are some provably wrong answers to a given questions (ie, an answer that can not be justified)
Gödel has nicely proven that they are some undecidable answers to some questions (ie, answers for which we can not know if they are right or wrong).
Of course, there is always the problem of interpretation and context of the question/answer pair.
The same answer can be right in a given context and wrong in another (6+6=2, in the context of 10 mod arithmetic).
In the case at hand, LN(81,3)=3.999..99 in the context of 12 digit decimal precision floating point arithmetic. It is equal to 4 in the context of 10 digit precision floating point!

I guess that aspect of things is why I like math. Not for the calculation but for the "philosophy" (phylosomath) behind it!

Cyrille

[Dieter]

(12-14-2015 06:35 AM)cyrille de brébisson Wrote:  Prime does give the correct answer to LN(81) and to LN(3) (within the calculator 12 digit accuracy). And dividing these 2 answers by each others do indeed yield 3.99...99).

Please forgive my ignorance, and maybe I get something wrong here, but: if there is a built-in function log(a, b) I would expect it to be evaluated with the usual 15 digit internal precision. Else there is no benefit compared to a manually calculated ln(a)/ln/b). ;-)

Another example: take for instance the 35s and its function for the xth root of y. Manually calculating the cube root of 125 via 3 [1/x] [y^x] returns 4,99999999999. Using the dedicated XROOT function (125 [ENTER] 3 XROOT) yields the exact result 5. Simply because of the extended 15-digit internal precision. That's what I would have expected here as well for the log(a, b) function.

Dieter

[retoa]

(12-14-2015 07:02 AM)Dieter Wrote:  Please forgive my ignorance, and maybe I get something wrong here, but: if there is a built-in function log(a, b) I would expect it to be evaluated with the usual 15 digit internal precision. Else there is no benefit compared to a manually calculated ln(a)/ln/b). ;-)

logb(81,3) returns the "right" answer 4 on my Prime, in both Home and CAS.

Are you getting a different result?

[cclinus]

Hi davimle,

You may try to select Rounded to 10 for Number Format?
   
   
You may feel more comfortable with this setting.

But I think HP should consider to extend the internal precision to 15-digit and rounded to 12-digit for display.

Regards,

[jebem]

(12-14-2015 07:52 AM)retoa Wrote:  

(12-14-2015 07:02 AM)Dieter Wrote:  Please forgive my ignorance, and maybe I get something wrong here, but: if there is a built-in function log(a, b) I would expect it to be evaluated with the usual 15 digit internal precision. Else there is no benefit compared to a manually calculated ln(a)/ln/b). ;-)

logb(81,3) returns the "right" answer 4 on my Prime, in both Home and CAS.

Are you getting a different result?

My physical PRIME gives different results depending on:
- What command we use: logb() or LOG()
- What environment we use: CAS or HOME

A) For logb(), it doesn't matter whether you are in HOME or in CAS mode:
logb(81,3) = 4
Ans-4 = 0

B) For LOG(), it depends on the environment:

B.1) HOME mode
LOG(81,3) = 3.99999999999
Ans-4 = -0.00000000001

B.2) CAS mode
LOG(81,3) = 4
Ans-4 = 0

[CR Haeger]

(12-14-2015 04:26 AM)davimle Wrote:  I bought my daughter (who is a Sophomore in H.S.) an HP Prime when she needed a graphing calculator, instead of the TI-84 that is recommended (and used by everybody else in her class), partly because it seems to be a superior machine (touch screen, graphing speed, display, CAS mode, etc.) and partly because my wife and I are both engineers and we both loved our HP 28S calculators from our days at the university.

Thanks in advance. I'm currently torn between waiting and hoping that HP will come up with a fix, or returning the calculator as defective and being a "sheep" by getting my daughter a TI-84 Plus CE.

Similar situation with my Daughter in US High School. Bought the HP Prime but not for her (yet...) - though it is invaluable for me helping her with her homework. In our case, she rarely actually has to graph anything and for this she uses an old TI84. Normally, she uses a TI36X Pro ($18) for homework and calculator portions of quizzes/tests. Mostly though, its pencil and paper work. If she really shows a strong aptitude and interest in math, then maybe she will pickup the HP Prime.

In your case, perhaps this is a "teachable moment" where you can discuss floating point precision, Home vs CAS, LOG() logb() and LOG()/LOG() and/or number formats?

As others have stated, proot(), a number of *solve commands are able to solve polynomial roots. In addition, pcoeff() is a handy function to create polynomial coefficients from roots.

[Han]

Perhaps the most indispensable lesson for any new user is the [Help] key. Typing any command on the command line and pressing help will bring up its help. Secondly, the catalog is equally important. So if one does not know whether a certain command exists, it is possible to try to guess the command in the catalog.

[Toolbox] -> select "Catlg" from the menu at the bottom of the screen

While in this catalog, just type out what you think might be a command name. For example, typing SOL would bring the catalog to the SOLve command. Then pressing help while that entry is highlighted will bring up the help for that command.

[carey]

Amazing!

So far, replies to davimle's straightforward concern about wrong answers being returned by the HP Prime when computing logs of arbitrary bases, e.g., log(base 3) of 81 and log (base 5) of 125, have:

- quoted Godel's Incompleteness theorem;
- questioned whether there are right or wrong answers in math;
- discovered that while the wrong answer is obtained in one part of the calculator's environment (HOME), the correct (different) answer can be obtained in the calculator's Computer Algebra System (CAS) environment.
- suggested making the log error a teachable moment.

I wonder what Bill Hewlett's reply would have been?

[Tim Wessman]

(12-14-2015 07:26 PM)carey Wrote:  Amazing!

...

I wonder what Bill Hewlett's reply would have been?

So I guess you are saying every calculator HP has ever made that doesn't compute TAN(ATAN(1)) to be exactly 1 should have been recalled? (I'm pretty sure only the 49/50 in CAS mode would return that btw)

What about 1/3*3? Because none of them will (Again, except for CAS mode).

This has to due with the question of "guard digits". On the TI you actually have extra rounded digits *that are not shown* and hide the error from the user. This is done simply to avoid asking this type of question. The discussion was around the "why is this result not what you expected" and in fact is correct following the same logic used by all previous HP machines.

There are plenty of viable reasons to kick Prime if you were a 48 user - this isn't one of them though.

[Tim Wessman]

(12-14-2015 07:02 AM)Dieter Wrote:  Please forgive my ignorance, and maybe I get something wrong here, but: if there is a built-in function log(a, b) I would expect it to be evaluated with the usual 15 digit internal precision. Else there is no benefit compared to a manually calculated ln(a)/ln/b). ;-)

...

That's what I would have expected here as well for the log(a, b) function.

Yes, this could be the expected behavior. We've looked at it and you are right that an improvement can be done here. Internally, that was coded the way it was in order to support more then plain integer arguments (complexes, lists, etc). We've added a special path for integers to ensure that 15 digits will be used. Thanks for pointing that out!

As a side note, there were lots of functions in the 48 series coded in a similar manner that would only do 12 digit calculations because internally it was just calls to a series of userRPL functions.

[Tim Wessman]

Quote:However, aside from the fact that the HP Prime doesn't solve quadratics as easily as the TI-84

You have two ways to solve this immediately that come to mind. First, use the CAS solve command.

1. Press CAS.
2. Toolbox->CAS->solve->solve (CAS button is at the bottom of the screen)
3. Type your equation, followed by =0,x (giving something like solve(x^2+3*x-3=0,x) )
4. Press ENTER. See something like {1/2*(-sqrt(21)-3),1/2*(sqrt(21)-3)}

The "proot" command already mentioned. This can be found in the toolbox->CAS->Polynomial->Find Roots entry.

(12-14-2015 04:26 AM)davimle Wrote:  However, since fewer digits are shown, this just seems to be a case of rounding. (e.g. with the first one, doing ANS - 4 returns -1.00000000E-11 just as one would expect.) So this doesn't feel like the a real solution.

Actually, you've hit EXACTLY on the solution the other calculators are using! All other manufacturers do an internal fudging on the display using "guard digits". These are extra numbers at the end are not shown to the user and are used to accumulate the error in a non visible spot (the display is rounded to remove them when shown to the user).

Try this fun thing and you'll see what I mean. On the other units do a 1/3 and evaluate. Now, multiply that by 3 again doing Ans*3 in a second step. You will get 1. Now do it again, but this type don't use the Ans*3, but rather type the number you see shown to you. (.3333333333...) with the exact number of 3s and multiply by 3. This time, you'll end up with .999... instead.

To make Prime behave most closely here to the TIs, you want to turn on the "Rounded" display option. The "standard" that is default on Prime is the exact same behavior and default on your old 28s units you used in college.

Quote:and did HP seem to understand the gravity of the situation?

Yes, we did understand and correct it in the source. When/if there is an update it will be included.

[carey]

I think the simple question is why a problem that a high school student can solve exactly, e.g., log (base 3) of 81 = 4 does not return exactly 4 on the Prime, but does return 4 on most current calculators (and computational software).

Thank you for your explanation about “guard digits” — it was very helpful, but disagree that in this case it would “hide the error from the user.” As cyrille correctly pointed out in this case “more precision returns a less accurate result, and less precision will return a more accurate result.”

Not trying to kick the prime, just trying to get a straight answer. I'm satisfied with the guard digit explanation but disagree that not using them is an advantage in this case.

[DrD]

(12-14-2015 07:26 PM)carey Wrote:  Amazing!

I wonder what Bill Hewlett's reply would have been?

Perhaps your own opinion might have greater merit,
for you can choose to try or buy;

A "reply," Bill Hewlett cannot compose it,
for decomposing is the reason why.

-Dale-

[Fortin]

http://www.math.ku.edu/~huang/CAMseminar...ecrets.pdf

I'd take the Prime's supposed "inaccuracy" over what these TIs do any day.

[davimle]

Wow! I think I definitely came to the right place instead of continuing to waste time with HP Support. I am happy to see that there is such an active, enthusiastic and vibrant community for the Prime. I'm not sure if it came across correctly my original post, so I wanted to re-emphasize here, both my wife and I love our HP 28S calculators and I even run an RPN calculator on my iPhone because I couldn't stand being without one all the time! If it wasn't for our firm love of HP calculators, I wouldn't have sent our daughter down this path. However, I have to remind people she is only 15 and a Sophomore in a U.S. High School (glad to see the diverse participation here!) dominated by TI's calculators and their teaching curriculum. My daughter is not tech adverse, but she doesn't have a fundamental love of digging into things "behind the scenes", so I would say she is a "typical" user rather than an "expert" user. So thank you so much to everyone who has replied so far, I have definitely learned some new things (which is good!).

@Cyrille (et al) I actually had confirmed that CAS would get the right answer to LOG(A,B), however I had asked my daughter to only use CAS mode for "fun" and to stay away from it day to day because it is not allowed and disabled on tests. Both in class and for SAT, AP, etc. Again, I love the CAS mode and it is extremely powerful, just not as appropriate for someone at the beginning of learning math. (I should have included this in the OP.)

Further, thank you for pointing out that the machine may be doing LN(A)/LN(B) behind the scenes. I hadn't thought too hard about how LOG(A,B) was implemented, but this makes sense and the results do confirm this seems to be what is happening. And I agree with @CR Haeger about a "teachable moment" and maybe we can talk about numerical methods! (Hadn't thought it would come up so soon, but may be a good opportunity.) Though I do agree with @Dieter that if this is what is happening behind the scenes, then additional precision should be used to hide this from the user.

@Han thank you for pointing out proot() she did not find that, and now I have downloaded the full User Guide for her. Looks like just what she wanted, so thank you, I had not found this via Google search. (Probably because I was searching on "quadratic".) Knowing what to type, or where to find functions will certainly help. I will check tonight (she has the calculator at school now) if it also works in non-CAS modes. I will look more at the Help and Catlg methods and point her to these. Thx.

@TW, she was using the Solver app before, but it would only return one root and would require some guessing on a "seed" to return the other root. Again, as you know as a "teaching" calculator, the others put in a more "easy to use" function.

@cclinus thank you for pointing out the "Rounded to 10" number format. I think this may make sense in that 11 was a bit "odd" anyways. This might be a useful work-around and alternative to Scientific or Engineering formats, given they also round.

@retoa & @Cyrille I think you have the "winner" here! Sorry that I did not know there was a logb(A,B) function. My daughter only showed me LOG(A,B) and it seemed to be working other than the few problematic cases. Also thank you for pointing out the template menu, she will like using that because she was complaining that the Sharp has better algebraic entry of log(B)A. I also confirmed this returns correct answer in Home mode last night same as @jebem.

In fact, after downloading the full User Guide, I can not find the LOG(A,B) function documented. So looks like there is more than one way to do a log of arbitrary base. (Not sure how she figured it out, but she found LOG(A,B).) I'll have her stick to the template and logb.

@carey you made me laugh out loud (in a good way!) I am reminded of the popular Engineer vs. Mathematician jokes. Being an engineer, you know how I side, but it's always refreshing to learn something new.

@TW thank you for the detailed explanation. As an engineer I understand the complexities of numerical approximations and limited precision, however as a "teaching" calculator in addition to a scientific and engineering calculator you have to play some of the same tricks as your competitors. I'm glad the problem made it through to the right technical team at HP. The responses I got from the Support representatives were not reassuring.

Thankfully, I think the consensus here is using 15 digit precision for the LOG(A,B) calculation solves the problem. Are we to correctly assume that is what was already being done for logb(A,B)? Given that LOG(A,B) seems to be undocumented, I am fine with sticking with logb(A,B). Might want to make sure the Support team knows to point people there as a solution rather than trying to say that the successive error returns the right answer. Any reason for both logb() and LOG() each with different implementation?

Finally, nothing but love and appreciation to everyone who took their time to point. I really am heartened by the fun responses I read here. I feel much better about the Prime knowing what is happening behind the scenes. Now I just have to hope the ACT comes to their senses before my daughter has to take it to avoid having to buy any TI calculator!

[Tim Wessman]

(12-14-2015 09:36 PM)davimle Wrote:  @TW, she was using the Solver app before, but it would only return one root and would require some guessing on a "seed" to return the other root. Again, as you know as a "teaching" calculator, the others put in a more "easy to use" function.

Well, since you are in the solve application, try pressing the "plot" button and you can quickly see a graph. That can be helpful in situations like this. NUM will switch back to the solve screen.

Currently, solving in the solve app will just return the single result like you've mentioned. That is in fact the identical numerical solver found in your 28S (speaking from an algorithm and behavior perspective).

One other thing you might not have discovered yet (but I suspect your daughter already has), press the LOG key and then press the "HELP" button. It will pull up contextual help for nearly everything in the system. I suspect she found it there. There are about 250-300 pages of documentation built into the calculator. :-)

For anyone interested, the code originally was like this:

Code:


  THPObj *ln[2];
  ln[0]= CallLN(f, Params, 1);
  ln[1]= CallLN(f, Params+1, 1);
  THPObj *ret= CallDIV(f, ln, 2);
  ln[0]->Delete(); ln[1]->Delete();

We've added a special case right before the first code for real inputs as the benefit outweighs any downside here.The _L on the div function returns the "user" 12 digit normalized result.

Code:

// case of LOG in base b...
  HP_Real r1, r2;
  if (Params[0]->GetReal(&r1) && Params[1]->GetReal(&r2))
  { Errors er; 
    if (!fError(er= filn(&r1, &r1)) || !fError(er= filn(&r2, &r2))) return THPObj::NewError(er);
    return THPObj::NewReal(fidiv_L(&r1, &r2, &r1), &r1);
  }

[John Colvin]

It is interesting to note that the template logb returns ln(a)/ln(b) (change of base) for non-integer results in Home mode.

[cyrille de brébisson]

Hello,

davimle, THANKS for that wonderful reply!

A couple of extra info here:
> [if ln(a)/ln(b)] is what is happening behind the scenes, then additional precision should be used to hide this from the user.

One of the thing that I was trying to point out in my earlier post is that this might or might not work depending on the input. More precision does not always equate to 'better' result. In this particular case (log(81,3), it does, but it might make things worse for other inputs).


For info, internally, calculators only know how to calculate ln(a-1).


The CAS, of course does things differently, it does it symbolically so as not to loose any precision.


If/when working with logs between home and CAS, pay attention to the different notation! This can be a pitfall!
Prime, in Home uses the 'computational' notation LN and LOG to distinguishes the natural and common logarithm, with the additional twist that LOG(a,b) means log in base b. In home, LN and LOG are NOT case sensitive.

The CAS however, which comes from the symbolic (and 'higher math') branch of math, only know how to work with natural log.
Here, the home compatibility and CAS original design do clash. As a result, LN, ln and log are natural log. LOG and log10 are common log and logb is the log in base b (really, these 3 last forms are just shortcut for entering LN(a)/LN(b)).
(always pay attention to what happen to your input when you press ENTER!)


This site: http://www.purplemath.com/modules/logs3.htm does have some interesting tidbits, for example:"Warning: If you eventually progress to much-more advanced mathematics, you may find that sometimes "log(x)" means the base-e log or even base-2 log, rather than the common log."


This goes back to something that I often have to point out. Math is VERY context dependent! Every math sentence seems to precise and so unambiguous until you realize how much information is context sensitive and then you realize how imprecise it actually is!


This set aside, I wanted to rebound on floating point arithmetic (because it is linked with the above).
All HP calculators designers have always taken the point of view that calculations should be based purely on the numerical user input, with no attempts to try to assume what the user wanted and correct (fudge) either the input or the outputs (one exception is the small items removal for the 48 matrix calculations functions, but this one was user selectable).

This decision was based on the assumption that users has a 'number' education and could interpret the result as needed for their use and the context. This was certainly true of our first users (who came from the slide rule time), later users (professional and university students), finance users (they know what their number mean).

However, the new generation of students (and math teachers), because they have grown being told that math are precise, right or wrong, and because they have been told that computers/calculator are 'good at math', are assuming that the result of the computer or calculator is 'right' (for what definition of right? one might ask). Because all their exercises fall 'right', they are also assuming that non integers result are incorrect.

A couple of example that show this trend:
- I once saw a student redoing a division 5 times (each time correctly), because the result was not a 'simple' number and he assumed that he messed up somewhere!

- I once showed a math teacher that, in excel, 100-99.99-0.01 is not 0, and he ended up reinstalling windows to 'fix the problem'!


Anyhow, thanks for the good discussion! Enjoy your HP Prime and doing math with your daughter. I certainly do enjoy doing the same with my son (who then gets yelled at by the teacher when he later tells her that she is wrong :-)

Cyrille