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

[Dave Allured - NOAA Affiliate]

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20190814/50ded043/attachment.html>