Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })
07-17-2018, 04:00 PM
Post: #21
 ttw Member Posts: 281 Joined: Jun 2014
RE: Easy as { 1 2 3 }?
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
07-17-2018, 04:51 PM
Post: #22
 BartDB Member Posts: 162 Joined: Feb 2015
RE: Easy as { 1 2 3 }?
(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.}
.

07-17-2018, 08:42 PM
Post: #23
 John Keith Senior Member Posts: 1,028 Joined: Dec 2013
RE: Easy as { 1 2 3 }?
(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.
07-17-2018, 08:49 PM
Post: #24
 John Keith Senior Member Posts: 1,028 Joined: Dec 2013
RE: Easy as { 1 2 3 }?
(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
08-07-2018, 04:07 PM (This post was last modified: 08-07-2018 04:29 PM by pier4r.)
Post: #25
 pier4r Senior Member Posts: 2,248 Joined: Nov 2014
RE: Easy as { 1 2 3 }?
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...

Wikis are great, Contribute :)
08-07-2018, 11:40 PM
Post: #26
 DavidM Senior Member Posts: 986 Joined: Dec 2013
RE: Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })
(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.
08-08-2018, 07:06 AM (This post was last modified: 08-08-2018 07:15 AM by pier4r.)
Post: #27
 pier4r Senior Member Posts: 2,248 Joined: Nov 2014
RE: Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })
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     \>>   \>>

Wikis are great, Contribute :)
 « Next Oldest | Next Newest »

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