List Commands Library for 50g

[Werner]

brickviking: Something like RAND 1 + 1 - should do it.
1e-15 <= RAND <= 0.999999999999, according to Joe
The range of RAND

Cheers, Werner

[HP67]

(10-03-2017 08:31 PM)Joe Horn Wrote:  

(10-03-2017 07:34 PM)HP67 Wrote:  I have an SX put away. If I have to I can run a program indefinitely until it produces a 1 or drains the batteries

No need to do that. As Werner explained above, the RPL RAND function CANNOT return either 0 or 1, ever, guaranteed. Even the 50g AUR manual is wrong about this.

Thanks for the clarification.

[John Keith]

(10-04-2017 01:06 AM)brickviking Wrote:  

(10-03-2017 08:31 PM)Joe Horn Wrote:  ... As Werner explained above, the RPL RAND function CANNOT return either 0 or 1, ever, guaranteed. Even the 50g AUR manual is wrong about this.

Hm. So how do I actually GET a value between 0 and 1 inclusive from a random function, at least in my 50G? I'm even more surprised that the venerable AUR has an error!

(Post 109)

I can't see how it would matter in the real world. Assuming the range was 0 to 1 inclusive, your chance of getting either a 0 or a 1 would be 1 in 5E13. If you left your calculator plugged in and generating random numbers continuously you would be very unlikely to see a 1 or a 0 in your lifetime.

John

[Thomas Okken]

(10-04-2017 12:44 PM)John Keith Wrote:  

(10-04-2017 01:06 AM)brickviking Wrote:  Hm. So how do I actually GET a value between 0 and 1 inclusive from a random function, at least in my 50G? I'm even more surprised that the venerable AUR has an error!

(Post 109)

I can't see how it would matter in the real world. Assuming the range was 0 to 1 inclusive, your chance of getting either a 0 or a 1 would be 1 in 5E13. If you left your calculator plugged in and generating random numbers continuously you would be very unlikely to see a 1 or a 0 in your lifetime.

John

Maybe it's just me, but my software design philosophy is "write code that is correct," not "write code that has a low chance of failure."

[Eric Rechlin]

(10-04-2017 02:32 PM)Thomas Okken Wrote:  Maybe it's just me, but my software design philosophy is "write code that is correct," not "write code that has a low chance of failure."

To be fair, this is just a pseudo-random number generator, and not a real random number generator, so no matter what it will never be truly "correct". I don't see how it is an issue, since it would never be a real world problem as John pointed out, and fixing the code to match the documentation was likely never feasible. The documentation could always be updated, of course, and then the code would be "correct" enough to meet your philosophy, I guess.

[Thomas Okken]

(10-04-2017 03:43 PM)Eric Rechlin Wrote:  

(10-04-2017 02:32 PM)Thomas Okken Wrote:  Maybe it's just me, but my software design philosophy is "write code that is correct," not "write code that has a low chance of failure."

To be fair, this is just a pseudo-random number generator, and not a real random number generator, so no matter what it will never be truly "correct". I don't see how it is an issue, since it would never be a real world problem as John pointed out, and fixing the code to match the documentation was likely never feasible. The documentation could always be updated, of course, and then the code would be "correct" enough to meet your philosophy, I guess.

You're using a rather unusual definition of "correct" there. Since when does a program have to BE reality? That's an impossible standard to meet. Correctness in the sense of "won't fail," however, is generally doable, and ignoring the difference between "less than or equal" and "less than" is not the way to achieving it.

[Eric Rechlin]

(10-04-2017 03:56 PM)Thomas Okken Wrote:  Correctness in the sense of "won't fail," however, is generally doable, and ignoring the difference between "less than or equal" and "less than" is not the way to achieving it.

That's why I suggested updating the manual to reflect the implementation, which then wouldn't be ignoring anything.

[DavidM]

Another question (actually two)

A question has come up about the "count" argument that is passed to LSDIV. In its present form, the count argument for LSDIV designates the number of sublists to create:

{ 1 2 3 4 5 6 } 2 LSDIV => { { 1 2 3 } { 4 5 6 } }

It has been suggested that the count argument should represent the number of sublist elements in each sublist instead of the count of sublists:

{ 1 2 3 4 5 6 } 2 LSDIV => { { 1 2 } { 3 4 } { 5 6 } }

Once again, I am ambivalent about this and don't have a strong preference in either direction. So...

Question 3: Which quantity do you think the count argument should specify for LSDIV?

• 3A=Sublist Count
• 3B=Sublist Size
  

Related to the above is a similar question for LDIST. The count argument for that command currently specifies the number of sublists to distribute the list elements into:

{ 1 2 3 4 5 6 } 2 LDIST => { { 1 3 5 } { 2 4 6 } }

With a similar treatment to the above question, the following would be the new result:

{ 1 2 3 4 5 6 } 2 LDIST => { { 1 4 } { 2 5 } { 3 6 } }

My own personal preference for this one is to keep it the way it is, mostly because I tend to think of the LDIST/LCLLT pair as being focused on "count of piles" instead of "size of piles" (LDIST was originally created while thinking of distributing cards into N hands). But I wouldn't call this a strong preference; I have no problem going with the consensus on this, regardless of the outcome.

Question 4: Which quantity should the count argument specify for LDIST?

• 4A=Sublist Count
• 4B=Sublist Size
  

[Brad Barton]

New to the discussion, so pardon if I missed something earlier.

How about both?

LSDIVE - argument specifies number of Elements in each list
LSDIVL - argument specifies number of Lists generated

LDISTE - argument specifies number of Elements in each list
LDISTL - argument specifies number of Lists generated

Maybe those commands are too long, but it's at least a consistent argument implementation.

Brad

[ttw]

Normally, most uses of pseudo-random-number generators do not generate 0.0 or 1.0. (This is for those approximating a real number on the unit interval.) Some common transformations of PRNGs fail on encountering 0 or 1. Example: generate an exponential distribution by taking Y=A*Log(U) where U is a real number on (0,1) and A is the proper constant to get the proper exponential (and Log is whatever log function is cheap to evaluate.) Similarly, the Box-Muller method of generating two independent normal random variates is: Y1=Sqrt(-2*Ln(U1))*Sin(2*Pi*U2) and Y2=Sqrt(-2*Ln(U1))*Cos(2*Pi*U2). Again there is a failure should U1 be zero.

I usually achieved this by generating a uniformly distributed integer J between 0 to 2^M, then transforming to an approximate by taking (2*J+1)/2^(M+1).

[Thomas Okken]

(10-06-2017 03:04 AM)ttw Wrote:  Normally, most uses of pseudo-random-number generators do not generate 0.0 or 1.0. (This is for those approximating a real number on the unit interval.)

"Most uses of pseudo-random-number generators do not generate 0.0 or 1.0"

Did you mean:

"Most pseudo-random-number generators do not generate 0.0 or 1.0"

Or did you mean

"Most uses of pseudo-random-number generators do not expect 0.0 or 1.0"

I'm asking because your statement, as it is, makes no sense. "Uses" of RNGs don't make those RNGs behave one way or another. RNGs are either able to produce 0.0 and/or 1.0, or they're not. And the code that uses those numbers should be written in a way that is correct when 0.0 or 1.0 occur, if it is possible for either or both of those extremes to occur.

[pier4r]

(10-05-2017 11:31 PM)Brad Barton Wrote:  New to the discussion, so pardon if I missed something earlier.

How about both?

If it is not difficult, I would support this.

[John Keith]

(10-05-2017 08:18 PM)DavidM Wrote:  Another question (actually two)

A question has come up about the "count" argument that is passed to LSDIV. In its present form, the count argument for LSDIV designates the number of sublists to create:

{ 1 2 3 4 5 6 } 2 LSDIV => { { 1 2 3 } { 4 5 6 } }

It has been suggested that the count argument should represent the number of sublist elements in each sublist instead of the count of sublists:

{ 1 2 3 4 5 6 } 2 LSDIV => { { 1 2 } { 3 4 } { 5 6 } }

Once again, I am ambivalent about this and don't have a strong preference in either direction. So...

Question 3: Which quantity do you think the count argument should specify for LSDIV?

• 3A=Sublist Count
• 3B=Sublist Size
  

Related to the above is a similar question for LDIST. The count argument for that command currently specifies the number of sublists to distribute the list elements into:

{ 1 2 3 4 5 6 } 2 LDIST => { { 1 3 5 } { 2 4 6 } }

With a similar treatment to the above question, the following would be the new result:

{ 1 2 3 4 5 6 } 2 LDIST => { { 1 4 } { 2 5 } { 3 6 } }

My own personal preference for this one is to keep it the way it is, mostly because I tend to think of the LDIST/LCLLT pair as being focused on "count of piles" instead of "size of piles" (LDIST was originally created while thinking of distributing cards into N hands). But I wouldn't call this a strong preference; I have no problem going with the consensus on this, regardless of the outcome.

Question 4: Which quantity should the count argument specify for LDIST?

• 4A=Sublist Count
• 4B=Sublist Size
  

While I personally prefer 3B and 4B, preceding either LDIST or LSDIV by OVER SIZE SWAP / will convert one version into the other. As long as the method chosen is that preferred by most people, I don't think it is worth making two separate versions of each command.

I don't see how the connection between LCLLT and LDIST is dependent on whether sublist count or sublist size is used, but I do think it is important that LDIST and LSDIV work the same way.

On the other hand, thinking about these commands made me wonder if it would be useful to have another command which would redistribute the sublists, e. g. converting {{ 1 2} { 3 4 } { 5 6 } { 7 8 } } into { { 1 2 3 4 } { 5 6 7 8 } } or vice versa. Of course this could also be done with user code but it would be substantially longer and slower than a built-in command.

John

[John Keith]

(10-05-2017 11:31 PM)Brad Barton Wrote:  New to the discussion, so pardon if I missed something earlier.

How about both?

LSDIVE - argument specifies number of Elements in each list
LSDIVL - argument specifies number of Lists generated

LDISTE - argument specifies number of Elements in each list
LDISTL - argument specifies number of Lists generated

Maybe those commands are too long, but it's at least a consistent argument implementation.

Brad

The problem with those names is that only the first 5 letters of each command are visible in the menus. To avoid confusion it is necessary to choose names such that the first 5 letters are different.

John

[DavidM]

(10-05-2017 11:31 PM)Brad Barton Wrote:  How about both?

(10-06-2017 05:58 AM)pier4r Wrote:  If it is not difficult, I would support this.

Thanks for joining in, Brad! I'm glad you're participating, and look forward to your insights. Pier, I'd only be surprised if you didn't support Brad's suggestion.

I'm really more interested in which situation people see as the most common scenario: a "groups" focus, or an "elements" focus. John's example shows how easy it is to switch between the two.

At present, I'm of the opinion that the library already has more commands than can be easily remembered. No matter how good the documentation is, commands aren't much use if you can't remember or find them. I've already seen evidence that existing commands simply aren't being used in situations where they apply, and I believe the size of current command set is contributing to that (especially if you also include GoferLists in the mix). While I'm not absolutely opposed to adding any last minute commands, they really need to be very compelling to overcome my desire to stabilize the library for a "general release".

(10-06-2017 03:23 PM)John Keith Wrote:  I don't see how the connection between LCLLT and LDIST is dependent on whether sublist count or sublist size is used, but I do think it is important that LDIST and LSDIV work the same way.

I was originally thinking that LCLLT would have to change if LDIST did, but that's not the case. Thanks for making me take a second look!

Case in point. Changing only LDIST, the following holds in both scenarios:

{ 1 2 3 4 5 6 } 2 LDIST => { { 1 3 5 } { 2 4 6 } } LCLLT => { 1 2 3 4 5 6 }
{ 1 2 3 4 5 6 } 2 LDIST' => { { 1 4 } { 2 5 } { 3 6 } } LCLLT => { 1 2 3 4 5 6 }

(10-06-2017 03:23 PM)John Keith Wrote:  On the other hand, thinking about these commands made me wonder if it would be useful to have another command which would redistribute the sublists, e. g. converting {{ 1 2} { 3 4 } { 5 6 } { 7 8 } } into { { 1 2 3 4 } { 5 6 7 8 } } or vice versa. Of course this could also be done with user code but it would be substantially longer and slower than a built-in command.

This can be achieved with:

Code:

\<<
  DUP SIZE
  SWAP LXIL
  DUP SIZE
  ROT / LSDIV
\>>

Yes, I know it's more than a few commands, but not by much. And I'm still planning to do some more tweaking of LXIL and LSDIV for speed (once I know the direction to take on the latter).

Perhaps this could show up as a command in some later release after the general one? That's worth considering.

[John Keith]

(10-06-2017 05:52 PM)DavidM Wrote:  This can be achieved with:

Code:

\<<
  DUP SIZE
  SWAP LXIL
  DUP SIZE
  ROT / LSDIV
\>>

Ha! That is the exact code I came up with. As a side note, if LSDIV were changed to use sublist size rather than sublist count, the above code would be reduced to:

Code:

\<<
DUP SIZE SWAP
LXIL SWAP LSDIV
\>>

[John Keith]

(10-06-2017 03:04 AM)ttw Wrote:  Normally, most uses of pseudo-random-number generators do not generate 0.0 or 1.0. (This is for those approximating a real number on the unit interval.) Some common transformations of PRNGs fail on encountering 0 or 1. Example: generate an exponential distribution by taking Y=A*Log(U) where U is a real number on (0,1) and A is the proper constant to get the proper exponential (and Log is whatever log function is cheap to evaluate.) Similarly, the Box-Muller method of generating two independent normal random variates is: Y1=Sqrt(-2*Ln(U1))*Sin(2*Pi*U2) and Y2=Sqrt(-2*Ln(U1))*Cos(2*Pi*U2). Again there is a failure should U1 be zero.

The Marsaglia polar method is more robust; if RAND returns either a 0 or a 1, it will merely be rejected during the testing phase, and a new pair of random numbers will be generated.

The Marsaglia method is a longer program than the Box-Muller method, but runs a bit faster.

John

[pier4r]

(10-06-2017 05:52 PM)DavidM Wrote:  Pier, I'd only be surprised if you didn't support Brad's suggestion.

MOAR! Seriously I already explained myself multiple times* and I am slowly trying to "fill the gap" collecting programs that I found interesting. So far (and for a while) I will be focused in searches about list processing programs. Although google is not really that precise, but it is ok.

* commands that reduce development/testing time even if they are a composition of 3 commands: they are great.

[DavidM]

I've updated the first post in this thread with the latest version (1.1.2b1). My hope is that this version of the library represents what will soon be the first "official" release.

No new commands were added this time, but one was removed (LNDUP). There really was no reason to keep that one, as the UserRPL command sequence "NDUPN →LIST" is essentially equal in performance and smaller as well.

I've actually put in a fair amount of time "refining" many of the commands since the last release. In most cases, this amounted to rewriting strategic parts of the commands in assembly language in order to maximize performance. While a few saw modest gains, many are now substantially faster as a result. One (LCLLT) can now handle larger lists than it could before due to its being more efficient with available memory.

The recent discussion regarding argument changes for LDIST/LSDIV seemed to indicate preferences for one of the following:
- include commands for every combination of command and argument
- change the commands to expect sublist size instead of sublist count
- doesn't matter

Given how easy it is to switch between the two potential inputs in a calling program, it really seems unnecessary to me to have separate commands for both contexts. The only person that seemed to have a strong preference was John Keith, indicating a preference for sublist size. Correspondingly, I went ahead and changed the two commands to now use the given argument as a sublist size instead of a sublist count.

My plan is to allow some time for testing this release (perhaps 2-3 weeks, depending on participation). I'll fix any discovered issues, and then post a "release candidate" if substantial changes were made. If only minor changes are needed, the next release should be the final one.

Thanks again for everyone's participation, help, and support!

[pier4r]

Kudos!

For LNDUP (that was neat nonetheless) I will collect the userRPL alternative in the userRPL collection of the hp calc torrent.

I need to remember to add the NDUP \->LIST to the collection though.