Little explorations with HP calculators (no Prime)

[Gerson W. Barbosa]

(04-10-2017 03:22 PM)telemachos Wrote:  To solve the two-triangles problem (pier4r's Post 122, above), I assumed that ABC was equilateral and had side length 12 units. That made its area 36√3 square units and made (x, y, z) = (6, 4, 3) units.

The law of cosines yielded side lengths (d, e, f) = (3√7, 7, 2√7) units for DEF. With an HP 50g in Exact mode (–105 CF) and with Rigorous mode on (–119 CF), Heron's formula then gave 21√3/2 square units for the area of DEF.

Finally, I scaled the areas of ABC and DEF by the factor 24/36√3 = 2/3√3, making those areas 24 (as required) and 7 square units respectively.

I did all of that with pencil and paper as well, but I was glad to have learned something about Rigorous mode, and to have written the little UserRPL program embodying Heron's formula.

Congratulations!

Since we correctly assumed the shape didn't matter, it strikes me that we all have missed perhaps the most convenient shape of all:



Best regards,

Gerson.

[pier4r]

So I'm slowly reading the general forum from the start, I'm at page 15 (of currently 81). I will likely need some life-factorial-extension to go through the archives of the previous forum (and after that I still will have the comp.sys.hp48 newsgroup and other forums to read).

Anyway I read an interesting post where one user, Alvaro, complained against stack operations. Now I'm not agreeing with him, I do remember when I played around with assembly that keeping the stack ordered was quite challenging, so I know that the stack is needed in certain designs.

The userRPL stack is gold in comparison with keeping order in ram. Still I find it not so ideal unless one provides a good commentary of the operations, due to the overhead in reconstructing what is going on. (there is also at least one nice thread about "how to comment stack operations" in this forum)

Anyway I recently find out, thanks to comments in other threads, about the free 42, that is a neat project. I checked the unofficial manual written in 2010 (with the occasion I thank the author) and I saw that the hp 42 and the free 42 are keystroke programmable in a way that closely resemble assembly.

There is a difference though, with the hp 42 one has, if I'm not mistaken, 100 registers that can be directly addressed. Those are quite handy to avoid all the stack manipulations to keep values available. Now as far as I know the equivalent of those registers in userRPL are global or local variables. I do not know any pattern to reserve part of the stack to variables that can afterwards recalled consistently, without actually creating any named variable. Am I wrong?

[ttw]

(04-04-2017 06:36 PM)pier4r Wrote:  Thanks for sharing (I'll have to check more the article from J.H.), yes it is pretty similar to what I thought as second idea. Would be interesting is someone has some other approaches (apart from ROLL ROLLD or even those but with subtle optimizations).

Actually with my shuffle I'm fine, the only point I started to be concerned "how many shuffles do I have to do to have a random order compared to the one from the start?"

Something like this https://www.youtube.com/watch?v=AxJubaijQbI (forgive me for the video, but it is interesting, check at least the first 45 seconds, there are also links to papers in the description)

If you use Joe Horn's code to shuffle the list, a single shuffle is completely random. A new shuffle would give you a new ordering. What his code does is place the any element into slot 1, then any remaining element into slot 2, etc.

[John Keith]

(04-14-2017 08:53 AM)ttw Wrote:  If you use Joe Horn's code to shuffle the list, a single shuffle is completely random. A new shuffle would give you a new ordering. What his code does is place the any element into slot 1, then any remaining element into slot 2, etc.

That is a classic algorithm: Fisher-Yates shuffle

The RANDPERM function on the Prime does a similar thing.

John

[pier4r]

(04-14-2017 08:53 AM)ttw Wrote:  If you use Joe Horn's code to shuffle the list, a single shuffle is completely random. A new shuffle would give you a new ordering. What his code does is place the any element into slot 1, then any remaining element into slot 2, etc.

Yes (thanks for the reminder, I was forgetting to read that article!). Just he does a number of ROLLs equal to the range. I wonder what should be a "good" lower bound, of course changing the approach a bit.

@John keith: thanks for sharing the link!

[Joe Horn]

(04-14-2017 12:26 PM)John Keith Wrote:  

(04-14-2017 08:53 AM)ttw Wrote:  If you use Joe Horn's code to shuffle the list, a single shuffle is completely random. A new shuffle would give you a new ordering. What his code does is place the any element into slot 1, then any remaining element into slot 2, etc.

That is a classic algorithm: Fisher-Yates shuffle

Actually, no. Fisher-Yates is a method for shuffling an already-existing array. So it requires two loops: one to generate the array, and another to shuffle it. My method doesn't do that; it shuffles the array WHILE creating it, all in one loop. In the Wikipedia article cited above, that's called "The Inside-Out Algorithm". The article unfortunately gives no name for its discoverer, nor date for its discovery.

[pier4r]

Joe, nice that you used discovered and not invented.

[pier4r]

For personal needs I'm slowly building a userRPL directory with a couple of utilities to handle lists, utilities that are not present in the built in functions (as far as I know).

My quick searches ( site:hpmuseum.org rpl list functions library ) returned no useful entries. By chance does anyone know whether someone did already a similar work, with a "stable" result? (the library should handle userRPL lists, not necessarily being written in userRPL)

PS: I read until 34 of the general forum here. There are a lot of interesting threads (it is a pity that there is no way to extract them quickly). The most recent were: work by the US government about military activities (nuclear bombs), and routines for HP calculators ; Valentin Albillo mini challenges, if 9x9 = 29 what is the square of 69 ? ; some analysis by Namir about random generators (the pity is that he does his nice work on Excel and not letting a calculator crunch everything)

[Gerson W. Barbosa]

(04-18-2017 04:15 PM)pier4r Wrote:  My quick searches ( site:hpmuseum.org rpl list functions library ) returned no useful entries. By chance does anyone know whether someone did already a similar work, with a "stable" result? (the library should handle userRPL lists, not necessarily being written in userRPL)

http://www.hpcalc.org/details/6529

[pier4r]

Thanks! I will try. With that name I would have never found it.

[pier4r]

I'm trying to understand the commands for list processing in userRPL. DOLIST, DOSUBS, NSUB, ENDSUB, STREAM (others?)

If I understood correctly STREAM is the most simple approach because it works on a pair of elements in input, then comes DOLIST that is a bit more generic and then DOSUBS (that allows the usage of NSUB/ENDSUB).

Am I mistaken?

[DavidM]

(04-19-2017 12:22 PM)pier4r Wrote:  I'm trying to understand the commands for list processing in userRPL. DOLIST, DOSUBS, NSUB, ENDSUB, STREAM (others?)

If I understood correctly STREAM is the most simple approach because it works on a pair of elements in input, then comes DOLIST that is a bit more generic and then DOSUBS (that allows the usage of NSUB/ENDSUB).

Am I mistaken?

You could also add ΣLIST, ΔLIST, and ΠLIST to your, um, list.

And you may want to start your exploration by considering even simpler constructs, such as:

Code:

{ 1 2 3 }
3
*

or

Code:

{ a b c }
{ 1 2 3 }
/

...since many simple functions also do something meaningful when given one or more lists as parameters.

[pier4r]

@DavidM: yes a lot of functions works also on list (there is a section in the user guide about this and user defined functions that works on list).

I was meaning something like "apply a RPL program to a list" (even if a function is a program as well). For what I know there is STREAM, DOSUBS (NSUB, ENDSUB), DOLIST.

STREAM seems the most simple, since it reads one element after another (after reading the first two)
DOLIST allows a bit more work, reading more elements when specified.
DOSUBS seems the most generic, allowing as many elements as defined inputs of a RPL program (or function). I wonder how the number of inputs are detected, maybe DOSUBS parses the program before.

This if I'm not mistaken.

[DavidM]

(04-19-2017 03:56 PM)pier4r Wrote:  I was meaning something like "apply a RPL program to a list" (even if a function is a program as well). For what I know there is STREAM, DOSUBS (NSUB, ENDSUB), DOLIST.

STREAM seems the most simple, since it reads one element after another (after reading the first two)
DOLIST allows a bit more work, reading more elements when specified.
DOSUBS seems the most generic, allowing as many elements as defined inputs of a RPL program (or function). I wonder how the number of inputs are detected, maybe DOSUBS parses the program before.

This if I'm not mistaken.

The Advanced Users Reference gives some insight into how those commands interpret the stack contents prior to execution.

I don't think the program/function is parsed for evaluation, other than checking to see if it is only one command (thereby allowing the "n" argument to be skipped). The results of the function passed as an argument are checked, though.

Consider these DOSUBS examples:

Code:

{ 1 2 3 4 5 6 7 } « + » DOSUBS

Note: 'n' not needed because the program is a single command. The same output is generated if '2' is used for n.
The output is a list of each subgroup of 2 items added together: { 3 5 7 9 11 13 }

That one seems very sensible, and probably exactly what you would expect. Let's change it a little:

Code:

{ 1 2 3 4 5 6 7 } 2 « + 0 DROP » DOSUBS

I had to explicitly set 'n' this time because the program isn't a single command. Looking at the program, you can see that it is essentially the same thing as before (+), but then it does something silly (0 DROP), which effectively does nothing at all (puts 0 on the stack then drops it). As such, the results are exactly the same as before: { 3 5 7 9 11 13 }.

Now for a twist. Let's keep the same input, but change the program to something entirely different (and totally unrelated to the actual input):

Code:

{ 1 2 3 4 5 6 7 } 2 « DROP2 x y z » DOSUBS

The given program in this case actually ignores the two parameters it's given (DROP2), then returns 3 arbitrary items on the stack as its result: x y z. You might be tempted to think this would result in an error, but the 50g is happy to execute the DOSUBS command and comes up with the following result:
{ x y z x y z x y z x y z x y z x y z } (6 sets of "x y z").

So you begin to see that DOSUBS really doesn't care much about the results of the function, and will simply group those results together in a result list based on the count of items in the source list taken 'n' at a time.

If you really want to confuse yourself , ponder the following question: How does DOSUBS know how many stack items were returned by the program/function it was given as an argument? I would suggest you try some experiments with DOSUBS (similar to the above) to formulate an answer.

These commands are complex creatures that perform a large number of behind-the-scenes operations. That's probably why they aren't known for their performance. I also find that I can't seem to remember exactly how they work (and all their quirks) without spending significant time with experiments and reading the manuals, which is probably why I rarely end up using them.

[pier4r]

DavidM, once again nice reply!

These commands are complex creatures that perform a large number of behind-the-scenes operations. That's probably why they aren't known for their performance. I also find that I can't seem to remember exactly how they work (and all their quirks) without spending significant time with experiments and reading the manuals, which is probably why I rarely end up using them.

Yes I do forget them too, even more that I just used them a bit. Interesting your question, I do assume that somehow they put the results in a list or they keep track of the stack length. I will have to investigate.

Your mention to the performance is also interesting, although they may be more handy for operations without caring about the performance. I just made a selection sort algorithm with them, that by itself is not great, and to order 50 elements it uses 45 seconds. (SORT uses 0.5 seconds, Sort from Groferlist uses 3 seconds)

[ttw]

Note about SORT.

SORT seems to be a merge-sort based method. This takes order N*log(N) time to sort. A selection sort (hardware, software, by hand....) takes order N^2 time and thus for anything more than around 10 elements will lose badly.

I did lots of tests of list-based, array-based, loop-based, (FOR START DO) and firmware routines (matrix and vector and the like). For some things, the clever routines were best. For others (and there was no way to guess ahead of time), just a loop was best.

One common (actually the first routine I wrote) was to fill a list with numbers from 1 to N. A loop was the fastest; I tried using SEQ but that was slower. My fastest was:
<< -> N << 1 N FOR I I NEXT N ->LIST >>>>

The list-processing capabilities are rather limited on the HP50. (Defaults for Sumlist and Prodlist are incorrect and mean that these need a wrapper around them to check the inputs and they do not have all the list commands needed.) There are two type of list commands, multiple list and reduction. MAX could be the maximum between lists or the maximum of a list (I wrote a listmax using STREAM but it again needs a complicated wrapper to handle cases of 1 element or 0 elements or non-list or empty stack or the like.) These cause a big performance hit and complicate programs.

[pier4r]

(04-19-2017 09:58 PM)ttw Wrote:  I did lots of tests of list-based, array-based, loop-based, (FOR START DO) and firmware routines (matrix and vector and the like). For some things, the clever routines were best. For others (and there was no way to guess ahead of time), just a loop was best.

Interesting (I missed this post for those days, sorry). By chance did you document the results / routines somewhere? Like in the software library here on the forum?

Anyway, while I'm trying to slowly solve the puzzle that I proposed about list processing here I reached the challenge 6. I'm super slow due to trivial mistakes that I do not discover quickly. Like "value 'var' STO-" instead of "'var' value STO-" (somehow I always mess with non commutative STO operations).

Aside from the fact that the code of DavidM does not include a challenge 6 solver, so I will have to compare against myself ( :sad: ) , I have two problems.


First problem is about inserting a list in a list.

Quote:Side question: I am not able to put a list in a list

I mean {1 2 3} {1 2 3} + returns {1 2 3 1 2 3}. What is the operation to return {1 2 3 {1 2 3} } ?

Second problem (it is a nice by product problem, I'm happy when I find those). To test the challenge 6 code, I use a program to generate a random list of N integers between minValue and maxValue (both extremes included). Now if minValue is 1 and maxValue is 10, given 100 elements, what is the probability of getting a valid list for the challenge 6? (challenge 6: verify that in a list of 100+ positive integers, every integer appears a number of times equal to its value)

I'll attack it as soon as I get enough sleep, I guess it is like "how can I partition a number".

[ttw]

I have a bunch of these. I never commented on them except in comp.sys.hp48 but not much discussion. The only other one of note was that the command IDIV2 was slower than / LASTARG MOD then working with the remainder followed by FLOOR then working with the quotient. I used this in my fast continued fraction stuff. I also use this in a "convert integer to digits of an arbitrary positive base" for my modified Halton sequences.

I have since seen some other code for CFs and Halton sequences. As I needed partial results, I couldn't use these codes.

I'll try to time some of the things and post some timings.

[peacecalc]

Hello pier4r,

Quote:What is the operation to return {1 2 3 {1 2 3} } ?

Try

Stack 5: 1
Stack 4: 2
Stack 3: 3
Stack 2: { 1 2 3}
Stack 1: 4

And then key in the command ->LIST and... ygwyw (you get what you want).

[pier4r]

Thanks peacecalc, the same was suggested by davidM.

This means that if I have a list I need to explode it and then compact it again.

Still I need to work out how many randomLists on average I should produce to get a valid input for the list processing test. (see post #197)