[ncl-talk] Minor concerns for the "num" function

[Dennis Shea]

Yes, the following are prototyped as requiring type 'logical'

*num* <https://www.ncl.ucar.edu/Document/Functions/Built-in/num.shtml>,
*dim_num*
<https://www.ncl.ucar.edu/Document/Functions/Built-in/dim_num.shtml>,
*dim_num_n*
<https://www.ncl.ucar.edu/Document/Functions/Built-in/dim_num_n.shtml>

---
I prefer strong typing also.
---
I went back over previous releases to see if the '*num*' prototyping had
been 'relaxed'.

6.1.0: October 28, 2012: *dim_num_n*
<https://www.ncl.ucar.edu/Document/Functions/Built-in/dim_num_n.shtml>
=> *fixed
a bug in the prototyping of this function*
                                                                  No idea
what the 'bug' was.
6.0.0: 30 May 2011: *num*
<http://www.ncl.ucar.edu/Document/Functions/Built-in/num.shtml>  - a long
will be returned if you're on a 64-bit system and the count is >= 2 GB
5.1.1: June 16, 2009: *dim_num_n *added to built-in library
4.2.0.a027: 30 December 2002: *dim_num*:
<http://www.ncl.ucar.edu/Document/Functions/Built-in/dim_num.shtml> Counts
the number of *True* values of the n-1 rightmost dimension for all
dimensions 0...n-2

---
%> cat > tst_num.ncl
A = (/True,False,False,True/)
a = (/ 1  ,  0,    0  ,  1 /)
nA = num(A)
na = num(a)              ;* warning message*
print(nA)
print(na)

===
%> ncl tst_num.ncl

*warning:*Argument 0 of the current function or procedure was *coerced to
the appropriate type *and thus will not change if the function or procedure
modifies its value

Both 'nA' and 'na' = 2 so it worked for integer 0,1

I **speculate** *NCL's coercion* is the culprit.
*Speculation^2*: Likely, this has been present since 1995!!! Yikes.

This subtle issue is not likely to be altered ... especially now.

===
I'll add something to the documentation of these functions.

D


On Wed, Aug 14, 2019 at 10:41 AM Dave Allured - NOAA Affiliate via ncl-talk
<ncl-talk at ucar.edu> wrote:

> Please note that in the documented prototypes for the functions num,
> dim_num, etc., the stated input data type is logical only.  It looks like
> the ability for numeric input was added as an afterthought, then the
> documentation was not properly updated.  In my opinion this complicates the
> use and understanding of these functions.  I would prefer that the num
> family functions accept only type logical, and return a type error for
> numeric input.
>
> If you want functions that count non-zero numeric values, then add them
> explicitly with new names.  This is just my opinion, but I prefer strong
> type safety when programming.
>
>
> On Wed, Aug 14, 2019 at 8:19 AM Rashed Mahmood via ncl-talk <
> ncl-talk at ucar.edu> wrote:
>
>> Hi Rick,
>> Thanks for the answer.
>> I thought it should be 7, so that it is equal to the results from
>> dimsizes. But, of course, this is not a good comparison, comparing two
>> different functions.
>> I agree that it would consider 0 values as False, as is written in
>> documents.
>>
>> Cheers,
>> Rashed
>>
>>
>> On Wed, Aug 14, 2019 at 3:55 PM Rick Brownrigg <brownrig at ucar.edu> wrote:
>>
>>> Hi Rashed,
>>>
>>> It seems to me the functions are working as advertised, given that they
>>> are counting "true" values, not counting number of non-missing values. And
>>> as you likely know, its quite common in many programming languages (C/C++,
>>> Go, Python, Javascript) for a 0 value to represent boolean False, and
>>> anything non-zero to be True.
>>>
>>> In your example here:
>>>
>>> cd = (/9,10,0,0,0,5,8./)
>>>
>>> are you suggesting the answer should be 7 or 4?
>>>
>>> Rick
>>>
>>>
>>> On Wed, Aug 14, 2019 at 3:25 AM Rashed Mahmood via ncl-talk <
>>> ncl-talk at ucar.edu> wrote:
>>>
>>>> Hi All,
>>>> My concern is ignoring "0" when the num and it's relatives (dim_num*)
>>>> functions do a counting when NOT evaluating a certain condition.  I do know
>>>> that it is clearly written in the documents that "All numerical values *except
>>>> for 0* evaluate to True."
>>>>
>>>> My concern is that* if someone forgets about this "0" exception*,
>>>> things could go very wrong: Here is how:
>>>>
>>>> ab = fspan(0,30,20)
>>>>   print(num(ab)+" ... "+dim_num_n(ab,0)+" ... "+num(ab.ge.0)+" ...
>>>> "+dimsizes(ab))
>>>> (0) 19 ... 19 ... 20 ... 20
>>>>
>>>>   cd = (/9,10,0,0,0,5,8./)
>>>>   print(num(cd)+" ... "+dim_num_n(cd,0)+" ... "+dimsizes(cd))
>>>> (0) 4 ... 4 ... 7
>>>>
>>>> But these does not fail and give fatal error when used without any
>>>> condition, although there is not so helpful warning message. The concern is
>>>> that if these cannot provide right answer these must give error message
>>>> suggesting that 0 values occurred while counting or something similar?
>>>>
>>>> Cheers,
>>>> Rashed
>>>>
>>> _______________________________________________
> ncl-talk mailing list
> ncl-talk at ucar.edu
> 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/20190815/9afe7aa1/attachment.html>