Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })

[ttw]

The SIGN function behaves strangely too.

{0 1 -1 0. 1. -1,} SIGN yields {'?' 1 -1 0. 1. -1.}

It has taken a bit of work to get around this behavior. For a list 'X' I usually do:

X 1. * SIGN XQ

[BartDB]

(07-17-2018 04:00 PM)ttw Wrote:  The SIGN function behaves strangely too.

{0 1 -1 0. 1. -1,} SIGN yields {'?' 1 -1 0. 1. -1.}

It has taken a bit of work to get around this behavior. For a list 'X' I usually do:

X 1. * SIGN XQ

The behaviour is exactly as described in the AUR:
"In exact mode, the sign for argument 0 is undefined (?). In approximate mode, the sign for argument 0 is 0"

Your first 0 is an exact 0 (no trailing decimal mark), hence the undefined result. By multiplying with 1. (approximate 1) you are making all elements approximate, hence 0 will become 0. and the result of SIGN will be 0. as described. (Interesting that you then convert the result to all numbers to quotient (exact) format when half your list was decimal format to start with).

Also if you set Flag -03 then SIGN will return {0. 1. -1. 0. 1. -1.}
.

[John Keith]

(07-17-2018 01:41 PM)DavidM Wrote:  == also ignores tags, which can be useful at times. But the increased flexibility of == comes with a price: it is noticeably slower. So in cases where performance is an issue, it's better to use SAME if you know that the objects in question are compatible with its strictness. In my experience, the most common issue that comes up for compatibility is exact vs. approximate numbers.

The slowness is especially bad with exact integers, not as bad with approximate numbers. All comparison operators are very slow when applied to exact integers.

[John Keith]

(07-17-2018 02:11 PM)Massimo Gnerucci Wrote:  OK, so DM 48 <> "48GX clone".
Now the post makes sense.

Not necessarily, I was expressing my personal wishes only. I have no knowledge of what Swiss Micros are working on. I would think that if it was going to be similar to the HP 50g they would call it the DM50.

John

[pier4r]

OT: request to David, could you improve the initial title? Google finds nothing and I had to resort to the MyBB search that is not totally bad if one has enough keywords
END OT.

Today I got for the first time a problem similar to this. On my 50g version 2.15 . Somehow one of my programs incremented a list until { 6. 6. } (n1) and another compared it to a list set to { 6. 6. } manually in a global variable and the 50g said "nope, they are different".

I checked with TYPE. Both are seen as type 5 and the numbers inside, the "6.", are type 0.

The funny part is that the second time that the program tries the comparison, it works. Don't ask me why. The first time it fails, the second time it works. I don't know how to fix it at the moment.

With SAME I get identical results (that is, the two lists are different).

n1: the subprogram starts with a list {1. 0.} and increments it until { 6. 6.} in base 7

update1: ok solved, I guess my beloved hp50g has a bit of problems. After a ON+F4 (test of the system) and a ON+F3 , now the system sees the two lists identical again.
update2: nope, somehow the program is behaving as before now. The two lists are different the first time, and equal the second time. Go figure...

[DavidM]

(08-07-2018 04:07 PM)pier4r Wrote:  OT: request to David, could you improve the initial title? Google finds nothing and I had to resort to the MyBB search that is not totally bad if one has enough keywords
END OT.

Hopefully the first subject is now more explicit.

(08-07-2018 04:07 PM)pier4r Wrote:  Today I got for the first time a problem similar to this. On my 50g version 2.15 . Somehow one of my programs incremented a list until { 6. 6. } (n1) and another compared it to a list set to { 6. 6. } manually in a global variable and the 50g said "nope, they are different".

I checked with TYPE. Both are seen as type 5 and the numbers inside, the "6.", are type 0.
...

update2: nope, somehow the program is behaving as before now. The two lists are different the first time, and equal the second time. Go figure...

I'm going to go out on a limb and guess that you are using a version of ListExt prior to the one I recently sent you via email (1.2.0). In particular, the I→NL command is what I would guess is the root of the problems you are running into. In pre-1.2.0 versions, it would create explicit reals in the -9..9 range instead of references to built-in ROM versions of those. 1.2.0 (and forward) fixes that, and reals should match as you would normally expect.

The problem you'll face, though, is that LDDUP in version 1.2.0 is broken in that it doesn't de-dup sublists that match (see the post in the ListExt thread). I'm a little short on time due to family obligations at the moment, but I'll attempt to remedy that as soon as possible with a 1.2.1 update.

[pier4r]

Thanks for the answer! And no I increment the list with get and put. No ListExt involved there if I am not mistaken. So I use the 2.15 RPL library.

I did a workaround knowing the amount of steps to do and making a loop instead of a comparison.

And thanks for the title change.

here is the code to increase the list (to get the position of the actual roll of X dice)

Code:


gpIncrDicePos
  \<<
    gvFalse "lvIsIncreased" DROP
    
    0 "lvPosToIncrease"   DROP
    
    \->
    lvIsIncreased
    lvPosToIncrease
    
    \<<
      gvDicePosActual SIZE 'lvPosToIncrease' STO
      
      WHILE
        lvIsIncreased NOT
        lvPosToIncrease 0 >
        AND
      REPEAT
        gvDicePosActual lvPosToIncrease GET
        IF
          @if the position to increase can be increased
          DUP
          gvDicePosMax lvPosToIncrease GET
          <
        THEN
          @then increase it
          1 + @increased value
          @prepare to put it in
          gvDicePosActual
          lvPosToIncrease
          ROT PUT 
          'gvDicePosActual' STO
          
          @said it is increased
          gvTrue 'lvIsIncreased' STO
        ELSE
          @delete the value on the stack
          DROP
          
          @put a 1 in the position as reset
          gvDicePosActual
          lvPosToIncrease
          1 PUT 'gvDicePosActual' STO
          
          @diminish the position to increase
          'lvPosToIncrease' 1 STO-
        END
      END
      
      IF
        lvPosToIncrease 0 \<=
      THEN
        @increased all the way through!
        @put to max
        gvDicePosMax 'gvDicePosActual' STO
      END
    \>>
  \>>