HP50G bug ?

[John R. Graham]

Still on the main HP web site in the US.

- John

[Han]

The most recent firmware was from 2009. I don't think they're going to release any updates anytime soon despite having had reports of really bad bugs since then. Moreover, I'm sure the Prime updates are higher on the priority list. I do wish they could have maybe just one person devoted to updating the HP50G ROM given that they are still selling the calculator.

[Claudio L.]

(12-12-2014 09:35 PM)Han Wrote:  The most recent firmware was from 2009. I don't think they're going to release any updates anytime soon despite having had reports of really bad bugs since then. Moreover, I'm sure the Prime updates are higher on the priority list. I do wish they could have maybe just one person devoted to updating the HP50G ROM given that they are still selling the calculator.

The next update for the 50g is called newRPL, it will still take a while longer but it will come. I followed this thread and implemented the operators the way it was expected here.
Originally, all operators on lists were passed directly to their elements and returned a list:
{ 1 2 }
{ 1 2 }
==
would return { 1 1 } (which is true for each element).
By reading this thread, I realized it's more useful if all "test" operators return a single true/false value.
So it now does the element-by-element, but then it combines all the intermediate true/false values into a single one:
{ 1 2 }
{ 1 2 }
==
returns 1 if all elements are equal. In general, all tests return true only if all elements of a list test true. This is recursive, so lists of lists work as expected.
Also, reals vs integers is not a problem:
{ 1.000 2.0 }
{ 1 2 }
==
returns 1 as expected. This is by design, as there's a single numeric type visible to the user. In this thread, the main problem was caused by a compiler optimization, which also cannot happen by design (lists cannot contain pointers, only objects).
In that regards, newRPL will be more user-friendly, as it will require less knowledge of the internal technicalities.
I'll release demo number 4 with these improvements very soon.

Claudio

[Han]

(12-15-2014 05:49 PM)Claudio L. Wrote:  The next update for the 50g is called newRPL, it will still take a while longer but it will come. I followed this thread and implemented the operators the way it was expected here.
Originally, all operators on lists were passed directly to their elements and returned a list:
{ 1 2 }
{ 1 2 }
==
would return { 1 1 } (which is true for each element).
By reading this thread, I realized it's more useful if all "test" operators return a single true/false value.
So it now does the element-by-element, but then it combines all the intermediate true/false values into a single one:
{ 1 2 }
{ 1 2 }
==
returns 1 if all elements are equal. In general, all tests return true only if all elements of a list test true. This is recursive, so lists of lists work as expected.
Also, reals vs integers is not a problem:
{ 1.000 2.0 }
{ 1 2 }
==
returns 1 as expected. This is by design, as there's a single numeric type visible to the user. In this thread, the main problem was caused by a compiler optimization, which also cannot happen by design (lists cannot contain pointers, only objects).
In that regards, newRPL will be more user-friendly, as it will require less knowledge of the internal technicalities.
I'll release demo number 4 with these improvements very soon.

Claudio

I think returning 1 or 0 would at least make it consistent with the behavior in the HP48S/G series and the HP49G/G+ and HP50G (excluding bugged cases). There is also a "SAME" command, and you could always implement new "equality" commands for other types of equality.

[Gilles]

(12-15-2014 05:49 PM)Claudio L. Wrote:  Also, reals vs integers is not a problem:
{ 1.000 2.0 }
{ 1 2 }
==
returns 1 as expected.

Claudio

I'm very happy about this new RPL project.
Note that on the 50G :

{1. 2.} {1 2} == gives 1
{1. 2} {1 2} SAME gives 0 (not exactly the same)
{ 1 2 3 4 } { 1 2 9 4 } « == » DOLIST gives {1 1 0 1}
{ 1 0 1 0 } { "A" "B" "C" "D" } IFT gives {"A" "C"}

Note that :

{ 0 0 0 0 } { "A" "B" "C" "D" } IFT returns .... nothing !

in my opinion a {} return will be far better (same problem with DOSUBS or DOLIST returning nothing in some cases...) l think it is important in new RPL to know 'à priori' how many object returns on the stack with a command...

The Annexe F of the AUR is very interesting about parallel list processing with the 50G

[Claudio L.]

(12-15-2014 09:08 PM)Gilles Wrote:  I'm very happy about this new RPL project.
Note that on the 50G :

{1. 2.} {1 2} == gives 1
{1. 2} {1 2} SAME gives 0 (not exactly the same)

Thanks, the difference between == and SAME is very subtle when it comes to numbers. In newRPL, 1. and 1 are both numbers, so SAME will return 1, and in your example {1. 2} {1 2} SAME is true.
This is exactly why I think is more user-friendly to say "a number is a number". Unless the user reads the manual and understands that 1. and 1 are different object types, it's hard to figure out why SAME would be false. One is equal to one but not the same as one?... it leaves people scratching their heads.

(12-15-2014 09:08 PM)Gilles Wrote:  { 1 2 3 4 } { 1 2 9 4 } « == » DOLIST gives {1 1 0 1}

This works the same in newRPL, except the number of lists is not an optional argument anymore.
You'd have to use:
{ 1 2 3 4 } {1 2 9 4 } 2 << == >> DOLIST
which is also valid on the 50g, and actually more bullet-proof since the auto-detection of the number of lists only works on select cases.
This is consistent with your thought that all commands must have a defined number of output arguments. I think they should also take a defined number of input arguments.

(12-15-2014 09:08 PM)Gilles Wrote:  { 1 0 1 0 } { "A" "B" "C" "D" } IFT gives {"A" "C"}

Note that :

{ 0 0 0 0 } { "A" "B" "C" "D" } IFT returns .... nothing !

in my opinion a {} return will be far better (same problem with DOSUBS or DOLIST returning nothing in some cases...) l think it is important in new RPL to know 'à priori' how many object returns on the stack with a command...

The Annexe F of the AUR is very interesting about parallel list processing with the 50G

I agree 100%, not knowing the number of arguments makes a command difficult to use. IFT is not yet implemented, and to be honest I didn't know it could operate on lists. I'll take note of this when I implement it (thanks for the heads-up).

Claudio

[Claudio L.]

(12-15-2014 07:07 PM)Han Wrote:  I think returning 1 or 0 would at least make it consistent with the behavior in the HP48S/G series and the HP49G/G+ and HP50G (excluding bugged cases). There is also a "SAME" command, and you could always implement new "equality" commands for other types of equality.

The original behavior was unintentional. I simply defined all operators to be applied recursively element-by-element and return a list of results.
This worked well for addition, subtraction, etc., but it was also returning lists of true/false values for all test operators as a side effect.
I now can identify all "test" operators and produce a single true/false output, without loss of generality (so if/when we add a new test operator, it will work on lists automatically, without changing anything in the code).

Claudio

[Bruno]

Hi Claudio,

the New RPL is implented in C only for the kernel or for the whole system ? (including User commands and Apps)
In other words, New RPL is it a RPL OS 'at all level' (providing and written in RPL system language) or only at the user level ?

[Claudio L.]

(12-16-2014 09:14 AM)Bruno Wrote:  Hi Claudio,

the New RPL is implented in C only for the kernel or for the whole system ? (including User commands and Apps)
In other words, New RPL is it a RPL OS 'at all level' (providing and written in RPL system language) or only at the user level ?

A few commands that need to execute user programs (MAP, DOLIST, etc) have small portions implemented in RPL that allow to "sandbox" the user program.
Other than that, it's all implemented in C, the whole system (for performance reasons). In the future there will be user libraries written in RPL, but they are not implemented yet.

Claudio

[Gerald H]

(12-08-2014 12:15 PM)Gilles Wrote:  Exact mode :

{ 1 2 3 4 5 } 2 MOD
{ 1 0 1 0 1 } ==

Returns 0. (false)
expected is 1. (true)

Use the programme << ->STR >> on both lists before comparison & you should get the answer you expect.

[Claudio L.]

(12-18-2014 03:27 PM)Gerald H Wrote:  Use the programme << ->STR >> on both lists before comparison & you should get the answer you expect.

While it would work in this case, it won't if one list has reals and the other one integers, since ->STR will add the dot, and the string comparison will say it's different.

Claudio

[Gerald H]

(12-18-2014 03:32 PM)Claudio L. Wrote:  

(12-18-2014 03:27 PM)Gerald H Wrote:  Use the programme << ->STR >> on both lists before comparison & you should get the answer you expect.

While it would work in this case, it won't if one list has reals and the other one integers, since ->STR will add the dot, and the string comparison will say it's different.

Claudio

Quite correct & irrelevant to Gilles original posting.

[Claudio L.]

(12-18-2014 04:09 PM)Gerald H Wrote:  

(12-18-2014 03:32 PM)Claudio L. Wrote:  While it would work in this case, it won't if one list has reals and the other one integers, since ->STR will add the dot, and the string comparison will say it's different.

Claudio

Quite correct & irrelevant to Gilles original posting.

How is it irrelevant? Even in exact mode per the original post you may get reals if you have the "Numeric" flag (-3) on, so using ->STR alone will not provide a complete workaround.