Accessing data in linked array on HP-50g
|
06-25-2021, 05:03 PM
Post: #1
|
|||
|
|||
Accessing data in linked array on HP-50g
Hi all,
What is the best way to access data in a linked array on the HP-50g? According to the description I have, a linked array consists of pointers pointing to the actual objects in RAM (or ROM). What matters here is the object being referenced, not the pointer itself. The object only needs to be read, not evaluated. How can I best do this? Solutions preferably in sys RPL. Sincerely, Karel. I use HP-16C, WP-34S emulator, HP-35s, HP-48GX, HP-50g, and HP Prime G2. |
|||
06-26-2021, 01:53 AM
(This post was last modified: 06-26-2021 12:02 PM by Giuseppe Donnini.)
Post: #2
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
(06-25-2021 05:03 PM)cahlucas Wrote: What is the best way to access data in a linked array? At least on the HP-48GX, the following System RPL words work interchangeably with ordinary arrays and linked arrays. GETATELN ( #0371Dh ) # arry --> ob TRUE # lnkarry --> ob TRUE # lnkarry --> FALSE where # specifies a lexicographic element number for arry or a lexicographic pointer table entry number for lnkarry. For lnkarry, GETATELN returns FALSE if the specified element does not exist. Otherwise, it returns the specified element of arry or lnkarry and TRUE. Note that FALSE is only returned for a null pointer within the limits of a linked array, so you have to make sure that # is within the range of arry or lnkarry. This can be checked with the following words: DIMLIMITS ( #035A9h ) arry --> {} lnkarry --> {} Returns a list of binary integer objects representing the dimensionality of arry or lnkarry. The length of the list represents the dimension count and the internals are the dimension limits. ARSIZE ( #03562h ) arry --> # lnkarry --> # For arry, ARSIZE returns the number of elements of the array in #. For lnkarry, it returns the number of pointer table entries of the linked array in #. (06-25-2021 05:03 PM)cahlucas Wrote: a linked array consists of pointers pointing to the actual objects in RAM (or ROM). No, the pointers do not point to objects, but to object bodies. Moreover, the referenced object bodies are not at liberty to live just anywhere in RAM or ROM, but must live inside the body of the containing linked array object itself, because linked arrays, like ordinary arrays, are atomic, not composite. |
|||
06-26-2021, 02:45 PM
Post: #3
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
(06-25-2021 05:03 PM)cahlucas Wrote: Hi all, There's very little in the way of documentation for RPL linked arrays. This thread may have some information of interest to you. As stated by Cyrille in that thread, linked arrays are primarily useful for building large lists of strings. This can come up if you need a library of strings that goes beyond the limits of message tables. I would add that a large list of constants with high numbers of duplicates can also benefit from the use of linked arrrays, and there's an example given in that thread of how to build one (though that example could be improved by using MASD syntax instead). Just curious -- what is your goal for using a linked array here? It may be that a standard array works just as well, and may even be smaller. |
|||
06-26-2021, 05:36 PM
Post: #4
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
(06-26-2021 01:53 AM)Giuseppe Donnini Wrote: At least on the HP-48GX, the following System RPL words work interchangeably with ordinary arrays and linked arrays.Dear Mr. Donnini, Thank you very much for your response. My question with your answer is: How should I translate this into a working program? I am currently making a "pretty print" program for the HP-82240B Infrared printer. All data objects can be printed with this, including symbolics, as well as user and system RPL programs (the latter only in string form), in a clear layout that is very well-arranged, only linked arrays need to be added. So it's about extracting the various objects in the linked array one by one, and then printing them. Or unpack the linked array completely, as possible with a standard array, or list, after which all the objects are on the stack (hopefully). I hope to hear from you soon. Sincerely, Karel. I use HP-16C, WP-34S emulator, HP-35s, HP-48GX, HP-50g, and HP Prime G2. |
|||
06-27-2021, 05:19 PM
(This post was last modified: 01-03-2022 10:30 PM by Giuseppe Donnini.)
Post: #5
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
[ WARNING: The following information relates to the HP-48; it may also apply to the HP-50G, but no warranty is given. ]
Here are a few things you should keep in mind:
The following program, which I tentatively call LA\->, takes a linked array as argument and returns its elements in row order to the stack, followed by a list specifying its dimensions. Non-existent elements are represented by the special placeholder NOVAL. For this reason, the program will not run on an HP-48S/SX. ******************************************************************************* * LA\-> G/G+/GX only ******************************************************************************* * ABSTRACT : Dissects a linked array by returning its elements in row order, * followed by a list of its dimensions. * * STACK : ( lnkarry --> el1...eln { %dim1...%dimx } ) * * * Non-existent elements are represented by xNOVAL. * * * The dimension(s) are always returned in a list, even when the * initial argument is a vector, that is, a one-dimensional linked * array. ******************************************************************************* ASSEMBLE * Binary transfer header. NIBASC /HPHP48-K/ * Unsupported, but stable entry points: =lnkarry EQU #1CCD8 =ARRYLP_DO EQU #37BCB * Rompointer entry points: =~xNOVAL EQU #05B0AB RPL EXTERNAL xNOVAL :: CK1NoBlame ( *Require 1 argument without recording the command* ) CK&DISPATCH1 ( *Dispatch table including second, tag-stripping, pass* ) lnkarry ( *Require linked array, or tagged linked array* ) :: ( lnkarry --> ) ARRYLP_DO (DO) ( *Take apart linked array* ) INDEX@ OVER ( el1...eli-1 lnkarry #i lnkarry ) GETATELN ( el1...eli-1 lnkarry <eli TRUE>|<FALSE> ) ?SKIP ( *If element does not exist,... ) xNOVAL ( ...return xNOVAL instead* ) SWAP ( el1...eli-1 eli lnkarry ) LOOP ( el1...eln lnkarry ) DIMLIMITS ( el1...eln { #dim1...#dimx } ) INNERCOMP ( *Convert bints to reals within dimension list* ) NULL{} SWAP ZERO_DO (DO) SWAP UNCOERCE >HCOMP LOOP ( --> el1...eln { %dim1...%dimx } ) ; ; N.B. The second loop could be optimized by return stack manipulations, but since the chances of encountering a zillionth-dimensional array are reasonably low, I opted for the most legible form. A compiled version of the program, called LAto, is attached to the posting, together with three already compiled linked arrays for testing purposes:
|
|||
06-27-2021, 07:15 PM
Post: #6
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
(06-27-2021 05:19 PM)Giuseppe Donnini Wrote: How does your program handle such non-standard arrays? Did you make provisions for arrays of any type and dimensionality? Dear Mr. Donnini, My program handles as far as I can judge only 'regular' arrays and matrices, both 1 and 2 dimensional (see code). I'll get to work with your code, as far as I can translate the pointers to the HP-50g. This may take some time, so it may take a few days before I will respond. Sincerely, Karel. Code:
I use HP-16C, WP-34S emulator, HP-35s, HP-48GX, HP-50g, and HP Prime G2. |
|||
06-27-2021, 09:43 PM
Post: #7
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
I am quite unfamiliar with the HP-50G, but after a quick check, I found the following:
|
|||
07-19-2021, 12:44 AM
Post: #8
|
|||
|
|||
RE: Accessing data in linked array on HP-50g
I thought I might give this a try, as it seemed like a nice exercise.
Playing around with this, I ran into a couple of wrinkles pertaining to which built-in commands support the various array object types. As an example: you pretty much have to use GETATELN to obtain a specific linked array element. However, GETATELN doesn't work with type 29 matrices. So there's no one-size-fits-all command that performs that function for all array types. Likewise, ^XEQARRY> works well for type 3|4|29 arrays, but not for linked arrays. This is one approach among many -- probably not the best or worst, but it should at least give some ideas for bits and pieces that might be useful for your implementation. It does use two undocumented built-ins that are accurate for a v2.15 firmware (I haven't checked other firmware versions for validity): - SysPR1 (PTR 2F127) is the internal version of the UserRPL PR1 command - DupArryType (PTR 2F2C4) is the code run by the UserRPL TYPE command to determine the type of a regular array object (3|4|29) This implementation uses a "decode the sequential index" approach for determining the labels for each element's indices. It essentially takes the index number of the current element and iteratively divides by the dimensions identified for the object to determine the current element's position label (the indices are converted to 1-based in the process). This is similar to how you might convert a number to a different base, but it uses a list of the dimensions instead of a constant base as the divisor. There's a couple of non-standard techniques used in this implementation which might benefit from further explanation: 1) Placing the main code object onto the return stack allows it to run for both of the overloaded dispatch types identified as part of the CK&DISPATCH1 structure. If the code had been part of library, this would not have been the best approach. In this case, I wanted the program to be fully encapsulated into one code object, and this approach is an efficient way to implement a single code base for multiple object types. 2) The dimensions list is processed using the return stack processing technique. This is an efficient (and fast) way to process each element of a list in sequence. Might be a bit heavy-handed for this situation, but it does show an example of how to do that if you are interested in using that approach with SysRPL programs. Here's the commented code: Code: !NO CODE |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)