HP50G bug ?

[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