Bug: HP Prime can't do Log's

[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