Re: Possible bug in ncl 6.1.2 when accessing part of character array ?

From: Jatin Kala <jatin.kala.jk_at_nyahnyahspammersnyahnyah>
Date: Mon Nov 18 2013 - 15:12:39 MST

Hi Mary,

I am using "tochar".
> Note that "tochar" was not behaving correctly in versions 6.1.0 and earlier. I see that we didn't include this in our release notes, and I apologize for this. I'll try to remedy this shortly.

That explains the problem i was seeing. Thanks for the explanation.
Cheers,
Jatin.

On 19/11/2013, at 2:37 AM, Mary Haley wrote:

> Jatin,
>
> You didn't show how you were converting the string in the V6.0.0 script. The "0x00" character you're seeing is the end-of-string character.
>
> Let me back up a bit and explain these string conversion functions.
>
> There are now four "convert from string to character" functions:
>
> tochar
> tocharacter (this one is unadvertised)
> stringtochar
> stringtocharacter
>
> The "char" and "character" variations should behave identically to each other. That is, "tochar" is simply an alias for "tocharacter" and "stringtochar" is an alias for "stringtocharacter".
>
> The behavior of tochar should be that *no* end-of-string character is returned, and with stringtochar, there is an end-of-string returned.
>
> This is partly due for backwards incompatibility, and for giving the user two options of what is returned.
>
> So, if you have the string "abcde". this is what you should see:
>
>
> (0) -------------------------------------
> (0) version = 6.1.2
> (0) string = 'abcde'
> (0) ----------tochar(a)-------------
> (0) a
> (1) b
> (2) c
> (3) d
> (4) e
> (0) ----------tocharacter(a)--------------
> (0) a
> (1) b
> (2) c
> (3) d
> (4) e
> (0) ----------stringtocharacter(a)--------------
> (0) a
> (1) b
> (2) c
> (3) d
> (4) e
> (5) 0x00
> (0) ----------stringtochar(a)--------------
> (0) a
> (1) b
> (2) c
> (3) d
> (4) e
> (5) 0x00
> (0) -------------------------------------
>
> Note that "tochar" was not behaving correctly in versions 6.1.0 and earlier. I see that we didn't include this in our release notes, and I apologize for this. I'll try to remedy this shortly.
>
> The documentation for these routines do reflect the differences you see in the behavior:
>
> http://www.ncl.ucar.edu/Document/Functions/Built-in/tochar.shtml
> http://www.ncl.ucar.edu/Document/Functions/Built-in/stringtochar.shtml
>
>
> --Mary
>
> On Nov 17, 2013, at 11:32 PM, Jatin Kala <jatin.kala.jk@gmail.com> wrote:
>
>> Ok, in ncl 6.0.0, the character array has size 12:
>>
>> NCAR Command Language Version 6.0.0
>> The use of this software is governed by a License Agreement.
>> See http://www.ncl.ucar.edu/ for more details.
>>
>>
>> Variable: some_char
>> Type: character
>> Total Size: 12 bytes
>> 12 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [12]
>> Coordinates:
>> (0) a
>> (1) b
>> (2) c
>> (3) _
>> (4) d
>> (5) e
>> (6) f
>> (7) _
>> (8) g
>> (9) h
>> (10) i
>> (11) 0x00
>>
>> In NCL 6.1.2, the extra (0x00) is no longer there, and the size is 11:
>> 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.
>>
>>
>> Variable: some_char
>> Type: character
>> Total Size: 11 bytes
>> 11 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [11]
>> Coordinates:
>> (0) a
>> (1) b
>> (2) c
>> (3) _
>> (4) d
>> (5) e
>> (6) f
>> (7) _
>> (8) g
>> (9) h
>> (10) i
>>
>>
>> That's why my code blew-up…… I just assumed that something as fundamental as the size of an array, irrespective of type, would always be the same, across NCL versions…. I guess this has something to do with the change of characters in NCL from signed to unsigned bytes or something?
>>
>> Cheers,
>> Jatin.
>>
>>
>>
>>
>>
>> On 18/11/2013, at 4:50 PM, Jatin Kala wrote:
>>
>>> Hi NCL developers,
>>> I think there is a bug in ncl/6.1.2. I am simply accessing part of a character array, and i get a different answer if i use 6.1.2 as compared to 6.0.0. Can others please confirm if they can re-produce this (or it's just me).
>>>
>>> Code:
>>> some_char= tochar("abc_def_ghi")
>>> print(some_char(dimsizes(some_char)-4:dimsizes(some_char)-2))
>>>
>>> Outputs:
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ which ncl
>>> /share/apps/ncl/6.0.0/bin/ncl
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ ncl test_char.ncl
>>> Copyright (C) 1995-2011 - All Rights Reserved
>>> University Corporation for Atmospheric Research
>>> NCAR Command Language Version 6.0.0
>>> The use of this software is governed by a License Agreement.
>>> See http://www.ncl.ucar.edu/ for more details.
>>>
>>>
>>> Variable: some_char (subsection)
>>> Type: character
>>> Total Size: 3 bytes
>>> 3 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [3]
>>> Coordinates:
>>> (0) g
>>> (1) h
>>> (2) i
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ module remove ncl
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ module load ncl/6.1.2
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ which ncl
>>> /share/apps/ncl/6.1.2/bin/ncl
>>> [z3381484@monsoon Soil-Albedo-Scripts]$ ncl test_char.ncl
>>> 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.
>>>
>>>
>>> Variable: some_char (subsection)
>>> Type: character
>>> Total Size: 3 bytes
>>> 3 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [3]
>>> Coordinates:
>>> (0) _
>>> (1) g
>>> (2) h
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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 Mon Nov 18 15:13:01 2013

This archive was generated by hypermail 2.1.8 : Fri Nov 22 2013 - 09:36:32 MST