Post Reply 
Leaving original user input in verbatim on CL after execution... any ideas?
01-30-2017, 02:08 AM (This post was last modified: 02-03-2017 03:29 PM by tastyelectron.)
Post: #1
Leaving original user input in verbatim on CL after execution... any ideas?
Hello all,

I'm a practicing engineer and use my Prime every day for work and use ENGINEERING number formatting exclusively. It appears that when anything is copied from either the Home or CAS history to the commandline, both entries and results alike, my exponents are automatically expanded to full decimal notation.

I regularly work with magnitudes 1E-15 - 1E9, and seeing my entries blow up from, say, 22.0E-12 to 0.000000000022 when I copy something back to the cl is a huge nuissance and slows down my workflow.

Further, eng notation isn't maintained for approximates either, which (understandably) behave completely differently from exacts:
22.86E-12 --> 2.286E-11.
The latter is at least readable, but with an engineering background rather than a pure physics background, it's much less interperable from a glance for me.

I realize that I can work around his to some degree by formulating full exponents on the cl: 1*10^-12, but the result will still pop out 1E-12, and it's ugly to boot. Smile

I'm seeing the same behavior for copies to the Clipboard stack, so it looks like the problem is pretty deep-rooted in the firmware... Easy eng-notation manipulation is hands-down the biggest thing I miss from my crawling, patinaed, TI-89 Undecided

Any help is greatly appreciated!
-Andy
Find all posts by this user
Quote this message in a reply
01-30-2017, 06:59 AM (This post was last modified: 01-30-2017 06:59 AM by Tim Wessman.)
Post: #2
RE: Misbehaving ENG num format... any ideas?
I am definitely not seeing this on my end when I try to reproduce. Is you calcualtor up to date? If so, please describe the exact way you are getting this.

I set to engineering 3, put in 1e-20 or similar examples, and then tapped them to copy back. They all came back in eng notation.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
01-30-2017, 10:36 AM
Post: #3
RE: Misbehaving ENG num format... any ideas?
In the latest release, with both HOME and CAS set to engineering 2, the example, 22.0E-12, placed into the command entry line, enter it, it does show up as 22.0E-12, in history. However, if you then mouse up, and recall 22.0E-12 back to the command line, it is no longer in engineering notation, it becomes: 0.000000000022. It works the same way in both HOME and CAS.

-Dale-
Find all posts by this user
Quote this message in a reply
01-30-2017, 02:47 PM
Post: #4
RE: Misbehaving ENG num format... any ideas?
(01-30-2017 06:59 AM)Tim Wessman Wrote:  I set to engineering 3, put in 1e-20 or similar examples, and then tapped them to copy back. They all came back in eng notation.

Did you try values that could also display as a decimal without a need for exponent notation? E-20 is a bit too small to cause the issue (too many 0s).
Find all posts by this user
Quote this message in a reply
01-30-2017, 05:42 PM
Post: #5
RE: Misbehaving ENG num format... any ideas?
(01-30-2017 06:59 AM)Tim Wessman Wrote:  I am definitely not seeing this on my end when I try to reproduce. Is you calcualtor up to date? If so, please describe the exact way you are getting this.

I set to engineering 3, put in 1e-20 or similar examples, and then tapped them to copy back. They all came back in eng notation.

Hey Tim,

I'm running 10637 on my hardware, and 11226 on my emulator on my android - both are showing the same behavior.

[[Home]]
Number Format: ENGINEERING 3
CL> 1E3 [enter]
1.000E3
[double-tap the entry or result in history to copy back to the CL]
CL> 1000

[[CAS]]
Number Format: ENGINEERING 3
CL> 1E3 [enter]
1.000E3
[double-tap the entry or result in history to copy back to the CL]
CL> 1000

thanks!
-Andy
Find all posts by this user
Quote this message in a reply
01-30-2017, 06:08 PM
Post: #6
RE: Misbehaving ENG num format... any ideas?
CASIO-like ENG key for HP Prime: http://www.hpmuseum.org/forum/thread-5039.html
Find all posts by this user
Quote this message in a reply
01-31-2017, 02:56 PM
Post: #7
RE: Misbehaving ENG num format... any ideas?
(01-30-2017 06:08 PM)Simone Cerica Wrote:  CASIO-like ENG key for HP Prime: http://www.hpmuseum.org/forum/thread-5039.html

Neat. I've implemented something similar, but the above is a bit more advanced.
In mine, I've added the following to my USERKEYS program:
Code:
KEY K_Eex()
BEGIN
IF (HFormat==0) THEN
   3►HFormat
ELSE
   0►HFormat
END
END
Which is a quick shortcut to swap between Standard number formatting and the last Engineering number formatting used. It's activated by pressing [Shift][User][EEX] (and then [ESC] because the prime jumps to either the Apps screen or a generic Help screen when this variable is changed. A small bug, but tolerable Wink)

Unfortunately both my solution and the Casio-like ENG key only operates on items within the History (or a new evaluation which then appears in the History). The issue I'm describing in this thread is when items are copied either from the History, or pasted from the Clipboard stack, once they appear on the command line any existing engineering (or scientific formatting for that matter) is disregarded and the expression is converted to standard format. "1.00E9" in the history will copy to the command line as "1000000000." and after hitting [Enter] will again be represented in the history as "1.00E9" - a huge pain when tweaking large complex expressions!

-Andy
Find all posts by this user
Quote this message in a reply
01-31-2017, 03:11 PM
Post: #8
RE: Misbehaving ENG num format... any ideas?
(01-31-2017 02:56 PM)tastyelectron Wrote:  
(01-30-2017 06:08 PM)Simone Cerica Wrote:  CASIO-like ENG key for HP Prime: http://www.hpmuseum.org/forum/thread-5039.html

Neat. I've implemented something similar, but the above is a bit more advanced.
In mine, I've added the following to my USERKEYS program:
Code:
KEY K_Eex()
BEGIN
IF (HFormat==0) THEN
   3►HFormat
ELSE
   0►HFormat
END
END
Which is a quick shortcut to swap between Standard number formatting and the last Engineering number formatting used. It's activated by pressing [Shift][User][EEX] (and then [ESC] because the prime jumps to either the Apps screen or a generic Help screen when this variable is changed. A small bug, but tolerable Wink)

The program above always returns either 0 or 3 (because it always returns the result of the last operation within the program). The way the user keys works is that when the re-defining program returns a number, the user-key system will mimic the key corresponding to that keycode. So 0 is the keycode for the [App] key, and 3 is the keycode for the [Help] key. You can use return() and specify a different keycode. Another alternative is to return a string (even an empty one) which starts the command line.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
01-31-2017, 04:10 PM
Post: #9
RE: Misbehaving ENG num format... any ideas?
(01-31-2017 03:11 PM)Han Wrote:  The program above always returns either 0 or 3 (because it always returns the result of the last operation within the program). The way the user keys works is that when the re-defining program returns a number, the user-key system will mimic the key corresponding to that keycode. So 0 is the keycode for the [App] key, and 3 is the keycode for the [Help] key. You can use return() and specify a different keycode. Another alternative is to return a string (even an empty one) which starts the command line.

Nice. Thanks for the tip!
Fixed ENG↔Standard hotkey for history entries only:
"USERKEYS":
Code:
KEY K_Eex()
BEGIN
IF (HFormat==0) THEN
   3►HFormat
ELSE
   0►HFormat
END;
RETURN "";
END;

-Andy
Find all posts by this user
Quote this message in a reply
01-31-2017, 04:54 PM
Post: #10
RE: Misbehaving ENG num format... any ideas?
The issue here is that these are "display" modes only. If you are copying a number back, HP calcs have always shown them in "full edit" mode. Since you are well under the limits of what fits in 12 digits, the digits are copied back. If it doesn't fit in 12 digits, then e notation is used.

Part of the problem is here trying to understand the intent of the user. For example, say you are set to ENG 3, and have typed 1.2345. It will show as 1.235e0. When you click COPY on that, should it return what is displayed and may be expected? Or all the digits? Is is more problematic to be reurning a mix? (image a formula with 4 numbers in it, of which 2 are copied back using e notation and the other 2 with more digits)

What could possibly improve things here is to have an additional check to see 1) do all digits entered fit in the first part of the eng formatted display perfectly, and 2) if so, return the value to the command line using e notation.

Thus 1.2345 would be copied back as 1.2345 in ENG 3 mode, but ENG 4 it would come back as 1.2345e0. Out of curiosity, how does the 89 you mention handle that? Do you just lose the '4' in one case?

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
01-31-2017, 10:46 PM (This post was last modified: 01-31-2017 10:46 PM by tastyelectron.)
Post: #11
RE: Misbehaving ENG num format... any ideas?
... Haha, wow. Tim, you are absolutely right. Behavior on a TI-89 is exactly the same in this regard, which makes sense, given the loss of precision depending on whichever representation the device is set to at any given point, as you've pointed out. I didn't realize that I was mis-remembering how things were in 89-land since when I opened my Prime a few months back I had put down the 89 and seriously haven't picked it up again, even once, until now. Big Grin The Prime is great machine.

However, what IS different is that on the 89, is that when I press [=] to execute what's on the CL, the entry remains on the CL in verbatim, untouched. Thus even though the command is parsed and reinterpreted to the current number format, executed, and placed into history as that (exactly the same behavior as Prime), I can still modify my input as I had originally written it to tweak or build upon, as needed.

Apologies for the mix up, is there any way to retain my entry, verbatim, on the CL after I press [ENTER]?

Cheers,
-Andy
Find all posts by this user
Quote this message in a reply
02-03-2017, 05:36 PM
Post: #12
RE: Leaving original user input in verbatim on CL after execution... any ideas?
Note that I've retitled the thread, as this issue is more of a feature request than a bug in ENG number format handling; I'll close this and start a new thread if appropriate.

I'm ultimately aiming to be able to type in an expression on the Command Line, press [ENTER] to execute the command, and have my original input remain on the CL in verbatim so that I can interpret and tweak it easily as needed.

To recap the use-case I've described earlier, when I'm writing input entirely in ENGINEERING number formatting (220E-9, for instance) on the CL, once I hit [ENTER] to execute the command, my original input disappears, any numbers that I've written inside that expression are interpreted as exact numbers or rationals where possible, and displayed in History according to the current Number Format settings; however, since numbers were reinterpreted as exacts, once copied back to the CL for further editing they appear in Standard number formatting (0.00000022) for editing. As a human that thinks in Engineering number formatting, the interpreted expression that Prime prefers is treacherous for me to interpret and edit since I have to count out each 0 to get an idea of magnitude.

So for options I can see:
  1. I'm hoping there's just a setting buried somewhere to simply leave the entry on the CL untouched after pressing [ENTER]... this would be ideal
  2. Use the clipboard: Select ALL, Copy, [ENTER], Paste
  3. Take advantage of the QUOTE() function to grab the CL contents, drop them into a local variable, execute the contents, and then dump the variable back out on the CL.

If the last two options are the only route, I'd like to at minimum map them to [ENTER] as a userkey... but I'm not sure how much power I have to manipulate the clipboard or manipulate the CL from that script. Undecided Any tips?

-Andy
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)