07-23-2019 04:12 PM
I have the number format set to scientific notation (two decimal places).
If I enter the following into the entry line:
and press Enter, the calculator correctly outputs
1.00E-9+2.00E-8 (on the left)
2.10E-8 (on the right)
However, if I then copy the sum back into the entry line (either to modify a number or to add more operations) the line shows up as
which mostly defeats the point of using scientific notation in the first place. The same thing happens with large numbers. This makes editing equations extremely cumbersome as numbers that should only be a few characters long end up taking up a third of the line. Additionally, it is easy to lose track of the order of magnitude of numbers with more than 6 leading/trailing zeroes.
I understand that numbers with many significant digits must be shown in full in the entry line, but there's no reason why 1E-9 can't be displayed as such instead of 0.000000001. Please tell me I'm missing something, and this is not a limitation of the HP Prime.
07-23-2019 05:18 PM - edited 07-23-2019 05:19 PM
The issue is:
"However, if I then copy the sum back into the entry line (either to modify a number or to add more operations) the line shows up as
Here's a screen capture:
The bottom line ("0.000000001+0.00000002") is the problem. The numbers were entered in scientific notation by the user. The program displays them back in scientific notation in the history. But when the line is copy-pasted into the entry field, the numbers now show up in the wrong number format.
07-24-2019 03:23 AM
I agree it is inconsistent with the number format setting. However when the command line is in edit mode, a number can be entered in any format and only gets converted to the number format setting once ENTER is pressed. So I can only guess that it was chosen to default all pasted numbers on the command line to standard format until entered.
07-24-2019 09:32 AM
That's unfortunate, I was hoping it was just user error on my part.
I found another thread on this topic, made in 2017:
(notice the usual suspect again submitting a response without actually addressing the question)
I will return the HP Prime and stick with the TI Nspire, which works as expected. A shame, I liked the interface of the Prime a lot more.
07-24-2019 09:48 AM
Thank you for linking that topic. The important answer there is from Tim Wessman as he is on the HP Prime devolopment team.
07-24-2019 10:25 AM - edited 07-24-2019 10:27 AM
Yes, his response is what convinced me to return the Prime. If the developers don't understand that there's no loss of accuracy by expressing 0.000000001 as 1E-9, there is just no hope. His assumption about other graphing calculators working the same way is wrong, as well. The TI Nspire behaves as expected. In fact, the TI-89 Titanium (released in 2004) handled small numbers correctly as well.
Interestingly enough, the HP Prime does use common sense formatting when the default standard formatting would grow too long. Here are some examples:
1) 1e-12 gets pasted as 0.000000000001
2) 1e-13 gets pasted as 1e-13
3) 1e11 gets pasted as 100000000000
4) 1e12 gets pasted as 1e12
5) 1.234e-9 gets pasted as 0.000000001234
6) 1.2345e-9 gets pasted as 1.2345e-9
07-25-2019 09:38 AM
For anyone reading this in the future, this is how the TI-NSpire and TI-89 behave:
1) 1E-3 gets pasted as 0.001 (TI-NSpire) or .001 (TI-89) (9 digits earlier/better than HP Prime)
2) 1E-4 gets pasted as 1.E-4 (both)
3) 1E13 gets pasted as 10000000000000 (both) (2 digits later/worse than HP Prime)
4) 1E14 gets pasted as 1.E14 (both)
Of course, if the calculator's copy operation simply copied what the user actually typed, none of this would be a problem. The user's preferred formatting would be preserved.