Why do commands behave inconsistently?

[Orome]

If I have a list in Home and choose List > REVERSE from the toolbox, I get a reversed list as a result, but if I have a list and choose List > SORT, I get the list followed by SORT(), which can't be evaluated.

For example, if I have
{2, 5, 8, 3, 6, 9}
and choose List > REVERSE I get
{9, 6, 3, 8, 5, 2}
but if I instead choose List > SORT I get
{2, 5, 8, 3, 6, 9} SORT()
which is unusable.

Why do these behave differently, and how am I supposed to know that they do?

[CyberAngel]

(03-24-2020 09:32 PM)Orome Wrote:  If I have a list in Home and choose List > REVERSE from the toolbox, I get a reversed list as a result, but if I have a list and choose List > SORT, I get the list followed by SORT(), which can't be evaluated.

For example, if I have
{2, 5, 8, 3, 6, 9}
and choose List > REVERSE I get
{9, 6, 3, 8, 5, 2}
but if I instead choose List > SORT I get
{2, 5, 8, 3, 6, 9} SORT()
which is unusable.

Why do these behave differently, and how am I supposed to know that they do?

I tried this on many emulators and a real calculator.
I used RPN and Algebraic.
It always worked correctly

Perhaps you do not have the latest software?
– –
VPN

[toml_12953]

(03-24-2020 09:32 PM)Orome Wrote:  If I have a list in Home and choose List > REVERSE from the toolbox, I get a reversed list as a result, but if I have a list and choose List > SORT, I get the list followed by SORT(), which can't be evaluated.

For example, if I have
{2, 5, 8, 3, 6, 9}
and choose List > REVERSE I get
{9, 6, 3, 8, 5, 2}
but if I instead choose List > SORT I get
{2, 5, 8, 3, 6, 9} SORT()
which is unusable.

Why do these behave differently, and how am I supposed to know that they do?

Both work OK for me. See attachment.

[Orome]

CyberAngel Wrote:  I tried this on many emulators and a real calculator.
I used RPN and Algebraic.
It always worked correctly

Perhaps you do not have the latest software?

I've tried it (in both Algebraic and RPN) on the (latest) iOS and macOS apps, and hardware calculators with the latest (2.1.1.14433 / 2020 01 21 on a D) and some of the earliest (2013 11 25 / 5447 on an A) software.

It behaves as I describe above on all except the very old software, were it works as expected. A recently introduced bug, perhaps?

[victorvbc]

(03-25-2020 01:32 PM)Orome Wrote:  

CyberAngel Wrote:  I tried this on many emulators and a real calculator.
I used RPN and Algebraic.
It always worked correctly

Perhaps you do not have the latest software?

I've tried it (in both Algebraic and RPN) on the (latest) iOS and macOS apps, and hardware calculators with the latest (2.1.1.14433 / 2020 01 21 on a D) and some of the earliest (2013 11 25 / 5447 on an A) software.

It behaves as I describe above on all except the very old software, were it works as expected. A recently introduced bug, perhaps?

I can't replicate it either. Maybe you could share a specific set of instructions on how to get this behavior?

[Orome]

victorvbc Wrote:  I can't replicate it either. Maybe you could share a specific set of instructions on how to get this behavior?

See videos:

• REVERSE
• SORT
  

[DrD]

I have tried to confirm Orome's REVERSE() and SORT() lists, using both the posted list, and other lists, in both [HOME] and [CAS]. After lots of testing, I have not had ANY problem show up.

In earlier versions, there were times when the various models would behave in strange ways, after a lot of programming, or entry line activities. Whenever that would happen, I found that, (for example, on the VC), performing a Calculator | Reset, (from the menu bar), cleared the problem.

It is important to have a current backup, before doing that Reset. Using the CK, "Restore" using the current backup, and ALSO perform a "Refresh." That always worked for me. However, with the latest versions, I have not had any more similar problems.

I don't know if this will be helpful, in Orome's case, but I offer this workflow, just in case it hasn't been tried ...

[Orome]

DrD Wrote:  I don't know if this will be helpful, in Orome's case, but I offer this workflow, just in case it hasn't been tried ...

Keep in mind that I'm not only seeing this on the latest hardware running the latest software (2.1.1.14433 / 2020 01 21 on a D), in both the (latest) iOS and macOS apps. The only place I don't see it — and get the expected behavior — is on my old Prime (2013 11 25 / 5447 on an A).

It's possible that at some point I restored to all three of the misbehaving calculators from the same backup and put them all in one of the odd states you mention. (The A would be immune, since it doesn't work with the CK.)

So: I'll try reinstalling my emulators and see where that gets me.

[Orome]

Orome Wrote:  So: I'll try reinstalling my emulators and see where that gets me.

No luck. A complete iOS reinstall of the HP Prime Pro (which wipes everything associated with the app an fully resets it to "factory" settings) still behave as described above in the OP and videos.

[victorvbc]

(03-25-2020 03:26 PM)Orome Wrote:  

victorvbc Wrote:  I can't replicate it either. Maybe you could share a specific set of instructions on how to get this behavior?

See videos:

• REVERSE
• SORT
  

If you press Enter after selecting Sort, doesn't it sort the list?

That's what I observe in my calculator.

[Orome]

victorvbc Wrote:  If you press Enter after selecting Sort, doesn't it sort the list?

Yes. The question is why selecting [REVERSE] reverses immediately, while [SORT] places SORT() in the command line (requiring a subsequent [ENTER]).

[Joe Horn]

(03-25-2020 03:50 PM)Orome Wrote:  

victorvbc Wrote:  If you press Enter after selecting Sort, doesn't it sort the list?

Yes. The question is why selecting [REVERSE] reverses immediately, while [SORT] places SORT() in the command line (requiring a subsequent [ENTER]).

Just a hypothesis: Perhaps it's because REVERSE always and only allows one argument, but SORT allows either one or two arguments (see its Help screen). In RPN, REVERSE can assume that it will always and only take one argument from the stack. But SORT can only know whether to take one or two arguments if you tell it to, by typing SORT(1) or SORT(2), respectively. My hypothesis can be tested by seeing if similar behavior occurs with other single-argument functions and other multiple-argument functions.

[Orome]

(03-25-2020 05:59 PM)Joe Horn Wrote:  Just a hypothesis: Perhaps it's because REVERSE always and only allows one argument, but SORT allows either one or two arguments (see its Help screen).

Very likely!

[DrD]

Quote:I've tried it (in both Algebraic and RPN) on the (latest) iOS and macOS apps, and hardware calculators with the latest (2.1.1.14433 / 2020 01 21 on a D) and some of the earliest (2013 11 25 / 5447 on an A) software.

It behaves as I describe above on all except the very old software, were it works as expected. A recently introduced bug, perhaps?

IF it fails for you in both Algebraic and RPN, then two arguments needed from the stack, (for RPN sort()), doesn't explain the failure in Algebraic entry mode.

#Orome: Does your example also fail in Textbook entry mode?

[Orome]

(03-25-2020 08:49 PM)DrD Wrote:  IF it fails for you in both Algebraic and RPN, then two arguments needed from the stack, (for RPN sort()), doesn't explain the failure in Algebraic entry mode.

#Orome: Does your example also fail in Textbook entry mode?

Sorry my sentence is garbled: the mention of Algebraic relates to it working there on a single argument.

So to be clear: [SORT] evaluates just fine on a single argument in Algebraic mode everywhere I've tried it, but when used in RPN it does not evaluate X (or the command line if occupied) and instead places SORT() on the command line. This is different (without any indication in the UI) from [REVERSE], which evaluates X.