[ncl-talk] Attributes and arrays and lists

Wei Huang huangwei at ucar.edu
Wed Jan 28 10:28:02 MST 2015


Kyle,

The list looplist2 at the end seg. faulted when doing "ListPop" is
definitely a bug.
I have created a JIRA ticket: NCL-2129
<https://vets.development.ucar.edu/jira/browse/NCL-2129> for this.

I will work on this and report back.

Thanks,

Wei

================================================
1850 Table Mesa Dr.
Boulder, CO 80307
Phone: 303-497-8924

On Tue, Jan 27, 2015 at 4:52 PM, Walter Kolczynski <
walter.kolczynski at noaa.gov> wrote:

>  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
>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
>
>
> _______________________________________________
> 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/20150128/366d0a9d/attachment.html 


More information about the ncl-talk mailing list