Hi OptoFans,
I’d consider this a more advanced topic, for those already comfortable with both tables (click here for a very basic intro to those http://forums.opto22.com/t/pac-control-101-why-when-how-would-i-use-a-table), and pointers (here’s a 101 lesson on pointers: PAC Control 101: Why/when/how would I use POINTERS?).
PAC Control supports one-dimensional lists/tables (like a float table, which is a list of floats).
But what if I want more, like 2D, a table of tables? A list of lists?
Of course, like many things in OptoLand, there’s more than one way to do this. You could use one giant table and decide that the first chunk of data is in elements 0 - 9 (for example), the next in 10-19, etc., like this:
Or, you could use Pointer Table, and have each pointer in that table point to a table – for example, Float Tables loaded with ingredient amounts… where I have a Float Table for each type of cookie I know how to make. Each element in these tables holds how much of a particular ingredient I need. E.g., perhaps element [0] is how many cups of flour, [1] is how many cups of sugar, etc.
Let’s say I know how to make 3 kinds of cookies, and I’ll put those ingredient amounts in 3 appropriately named Float Tables called:
ft_chocolate_chip_cookies
ft_peanut_butter_cookies
ft_red_velvet_cookies
And I’ll load those 3 tables, one per element, into the Pointer Table called:
pt_my_pointer_table
(So I have one “master” pointer table, and 3 float tables vs. the one giant float table.)
Here’s an example of how I might use all this. Let’s say I need to make a shopping list where I add up how much of each ingredient I need, and put that in another Float Table I’ll call:
ft_shopping_list
To do this with one giant table, like the one picture above, my OptoScript might look like this:
Compare this to using the Pointer Table method. In my OptoScript below, I’ve circled the part where people normally need help on the syntax (what’s called “de-referencing” the pointer – in other words, getting the value of the what the pointer is pointing to).
Note that besides the 4 tables, I’m also going to need one pointer to whatever type I’m loading my Pointer Table with: in this case, to a pointer to Float Table, since data I’m storing is floats – specifically the amount of flour, etc. I’ll need in units of cups (so I need the fractional part and therefore floats). I’ll call this pointer:
pft_pointer_to_float_table
I’ll need this “temporary” pointer when pulling each of my cookie ingredient lists out of the master list (the Pointer Table).
What’s going on there? Up at the top I’m initializing the pointer table, using the & which I like to remember by thinking that & or Ampersand starts with A, like “Address.” Because we’re really loading that table with the address of each of the tables. (A pointer is storing the address of the variable rather than a value it’s holding for you, in this case, the address of my table of floats with the numbers of cups of cookie ingredients.)
After that, it’s very similar to the giant table method: I’m going to loop through my list of cookie types, adding up the total amount of ingredients for each type of cookie. I’ll zero out my shopping list, just like before. Then initialize my temporary pointer – since for my outer “while” loop, I’ll loop through each cookie type in turn (each time setting that temporary pointer to point to the float table of the cookie I’m on). For my inner “for” loop, I’ll loop through each ingredient type and add that amount to what’s already in my shopping list for that ingredient.
Why, OptoMary, Why? That looks icky!
Why would I want to use that more complicated Pointer Table method vs. the one giant data table method? You might not if it’s confusing to you and you’re not expecting any changes to, say, the max number of cookies types or ingredients per cookie.
In the example I gave above, I had three types of cookies each with a max of 10 ingredients. But how sure am I that’s not going to change in the future? You could see how multiplying bigger lists by bigger lists could end up eating all your available SNAP PAC memory ( click here for how much that is http://documents.opto22.com/1646_Tech_Note_SNAP_PAC_Memory.pdf ) real fast. Hopefully you can also see how it would be icky if your max of 10 later needed to be changed to something bigger.
So if you expect these lists to grow in the future, or perhaps you’ve had some programming experience in the past (or would like more in the future), give pointers, tables, and pointer tables a try!
Comments? Questions?
-OptoMary