[ncl-talk] Attributes and arrays and lists

[Walter Kolczynski]

Kyle,

My understanding is that the list only holds a reference to the 
variable, which is why when you delete the variable, the list now 
references something that doesn't exist (something that doesn't come up 
in Java). I have a utility function I use to create an anonymous copy to 
add variables to lists without fear of them being deleted:

;
; Creates an anonymous copy of a variable for inclusion in lists without 
causing issues if the variable is deleted.
;
if isdefined("echo") then undef("echo") end if
function echo(variable)
     local variable2
     begin
     variable2 = variable
     return variable2
     end ; echo

Then you can just add it to a list like so:
ListPush( listName, echo(variable) )

All of the elements in the list will retain all of their metadata when 
you pop them off or access them directly via [ ].

- Walter

On 27-Jan-15 11:13, Kyle Griffin wrote:
> Hi all,
>
> Some questions as to the interactions between all three of these 
> (attributes, arrays, and lists) and some discussion as to the desired 
> functionality of each.
>
> I've included (in raw text) some code at the end that demonstrates 
> some of my concerns.
>
> First: Is it possible for individual elements of an array to maintain 
> their individual attributes while in an array? (Parts 1/2 below)
> Current practice is to set any individual attributes to the attributes 
> of the array variable and, when individual elements are returned, 
> return the elements with all attributes from the array, even if the 
> attributes have been changed or others added.
>
> Secondly, I know Lists are relatively new additions to NCL, but I'd 
> also like to question how variables are handled when the lists are 
> being created. (Parts 3/4 below)
> It seems that there is not a functional way to create a list without 
> having a unique variable for each member (e.g. Part 3). This is a nice 
> workaround to my question above, as each member keeps its own 
> attributes as well.
> However, in order to use these lists in a more practical sense, the 
> addition of a variable via a loop does *not* work well, although I 
> believe it is working as designed. When a variable is added to a list, 
> the original variable must be maintained in memory and any changes to 
> that variable outside of the list will be reflected inside the list as 
> well. This makes sense, as the variable is simply a member of the list 
> - the list is simply an organizational structure for pre-existing 
> variables. In order to do this in a loop, one would need to have a 
> unique name for each variable to be added to the list OR disassociated 
> the variable that is being added to the list from its reference 
> variable outside the list. The unique_string function, while useful 
> for attribute names, does not work for variable names, e.g.
>
> varname = unique_string("")
> $varname$ = ....data to put in list...
>
> As a result, lists are essentially useless without a unique, hand-made 
> variable for each member, something that is simply not practical in 
> many situations.
>
> The biggest red flag I've seen, however, is when trying to add only 
> the value of the variable, via (/.../), to the list. This would be a 
> potential alternative to creating individual variables and allowing 
> for subsequent alterations to the variable in order to add attributes, 
> for example. The subsequently created list, when popped with ListPop, 
> instantly seg faults.
>
> As I write this email, I realize that my Java training from many years 
> ago comes to mind, especially the ArrayList functionality. I'm not 
> 100% sure that's what I've tried to describe in this email, but it 
> might be a start, where "objects" (any variable with attributes) can 
> be stored (like lists) but with the index functionality of arrays as 
> well. It still doesn't get around the "unique name" issue, however. 
> Thanks for reading...I'm sure these are lofty goals to see any of this 
> in the future, but the apparent desire to add lists tells me there is 
> some motivation for this type of data structure even if the current 
> utility of Lists seems unintentionally low.
>
>
> Kyle
>
> test code (on 64-bit RHEL, 6.2.1):
> begin
>
>   a = True
>   a at thing = 1
>   a at thing2 = 2
>   b = True
>   b at thing = 10
>   b at thing3 = 20
>   c = True
>   c at thing = 100
>   c at thing2 = 200
>
>   ;Part 1
>   arraylist = new(3,typeof(a))
>   arraylist(0) = a
>   arraylist(1) = b
>   arraylist(2) = c
>   print(arraylist(0)) ;expecting value/atts of a
>   k = arraylist(0)
>   print(k at thing) ; keeps atts of arraylist, which are those of c
>   delete(k)
>   print("###############################")
>   ;Part 2
>   arraylist2 = (/a,b,c/)
>   print(arraylist(0))
>   k = arraylist(0)
>   print(k at thing) ; does same as first example.
>
>   print("###############################")
>   ;Part 3
>   thelist = NewList("fifo")
>   ListPush(thelist,a)
>   ListPush(thelist,b)
>   ListPush(thelist,c)
>   print(thelist) ; keeps values AND attributes
>
>   print("###############################")
>   ;Part 4
>   looplist = NewList("fifo")
>   looplist2 = NewList("fifo")
>   do i=0,2
>     thevar = i
>     thevar at att1 = i*12.0
>     ListPush(looplist,thevar)
>     ListPush(looplist2,(/thevar/))
>   end do
>   print(looplist)
>   y=ListPop(looplist)
>   print("First var from list, should be 0 with att of 0:")
>   print(y)
>   print("###############################")
>   print(looplist2)
>   print("###############################")
>   x=ListPop(looplist2)  ; SEG FAULT here.
>   print(x)
>
> end
> ----------------------------------------
> Kyle S. Griffin
> Department of Atmospheric and Oceanic Sciences
> University of Wisconsin - Madison
> Room 1421
> 1225 W Dayton St, Madison, WI 53706
> Email: ksgriffin2 at wisc.edu <mailto:ksgriffin2 at wisc.edu>
>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150127/1bca0889/attachment.html