Re: Working with the := operator

Thanks for the clarification, Wei. I see I was trying to use it a bit
beyond its initial intentions. However, I would certainly welcome some
extension of the operator to allow for the use I portrayed, but I also
understand creating such functionality while still being time efficient is
probably not a simple task.

Thanks again for the info.

Kyle

----------------------------------------
Kyle S. Griffin
Department of Atmospheric and Oceanic Sciences
University of Wisconsin - Madison
Room 1421
1225 W Dayton St, Madison, WI 53706
Email: ksgriffin2@wisc.edu

On Wed, May 29, 2013 at 10:43 AM, Wei Huang <huangwei@ucar.edu> wrote:

> Kyle,
>
> The re-assign operator ":=" is not intended for memory-efficeint.
> The basic idea is to give use a way t re-use variable names
> (or to save a 'delete' commend).
>
> Originally, if we have code:
>
> avar = 123 ; avar is an integer.
> ;do some work with avar.
> delete(avar)
> avar = 456.7
> ;do some work with avar.
>
> With re-assign operator ":=", the above code can change to:
>
> avar = 123 ; avar is an integer.
> ;do some work with avar.
> avar = 456.7
> ;do some work with avar.
>
> Clearly, the re-assign operator ONLY saved a "delete(agar)" line.
>
> In the NCL source code, it did exactly the same thing above.
> In the "avar := 456.7" line, what NCL did is to check
> if there is anything named avar, if not, then create a variable named
> "avar",
> here the type is float, and assign value "456.7"; if yes,
> then NCL wipe-out anything related to "avar", and
> then create a variable named "avar",
> here the type is float, and assign value "456.7".
>
> In your example, NCL is doing what mentioned above,
> which at line: "x := x(::4)", NCL wipes anything related
> to "x" first, when NCL reads in the left hand side of the
> line, then when NCL tries to read "x(::4)", "x" becomes
> undefined, which is what NCL tells us in the error message.
>
> We will discuss what NCL should do for this case,
> and we certainly welcome users give us their idea as well.
>
> Here, we thank you for giving us a clear example to
> demonstrate an issue.
>
> Wei
>
> huangwei@ucar.edu
> VETS/CISL
> National Center for Atmospheric Research
> P.O. Box 3000 (1850 Table Mesa Dr.)
> Boulder, CO 80307-3000 USA
> (303) 497-8924
>
>
>
>
>
>
> On May 28, 2013, at 3:28 PM, Kyle Griffin <ksgriffin2@wisc.edu> wrote:
>
> Hi everyone,
>
> In the most recent version of NCL, the reassignment operator (:=) was
> introduced. However, most of the times I've attempted to use it, I haven't
> been able to do so successfully. I've noticed that this happens at times
> where I use the operator in an attempt to re-assign itself, as I've
> included below.
>
> While a temporary variable would be an obvious workaround to this problem,
> I was wondering if this was the intended behavior of the operator and/or if
> there is any way to allow the type of use I've included below in a
> memory-efficient manor? If so, that would definitely make this operator
> significantly more useful in my work.
>
> Copyright (C) 1995-2013 - All Rights Reserved
> University Corporation for Atmospheric Research
> NCAR Command Language Version 6.1.2
> The use of this software is governed by a License Agreement.
> See http://www.ncl.ucar.edu/ for more details.
> ncl 0> x=ispan(0,100,1)
> ncl 1> x:=x(::4)
> fatal:["Execute.c":7270]:performASSIGN_VAR_VAR_OP: x is undefined
> fatal:["Execute.c":8126]:Execute: Error occurred at or near line 1
>
> ncl 2>
>
>
> Thanks,
>
>
> Kyle
> ----------------------------------------
> Kyle S. Griffin
> Department of Atmospheric and Oceanic Sciences
> University of Wisconsin - Madison
> 1225 W Dayton St, Madison, WI 53706
> Email: ksgriffin2@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
Received on Wed May 29 10:00:51 2013