Re: Strange error

I'd like to add that we intend to explore whether it would be possible
to perform
integer overflow checking without a big performance hit,
  -dave

On May 4, 2007, at 11:32 AM, David Ian Brown wrote:

> Hi Saji,
>
> First a simple answer to the 64-bit machine question:
>
> On a 64-bit machine you can have bigger integer numbers using NCL. You
> just need to create them as longs. Currently the only way to do this
> is to
> use the 'new' operator.
>
> Using your original example you would say:
>
> ncl 5> a = new(1, long)
> ncl 6> a = 35280
> ncl 7> print(a * 192 * 96 * 4)
> (0) 2601123840
>
> or (showing variable 'a' in detail)
>
> ncl 8> a = a * 192 * 96 * 4
> ncl 9> print(a)
>
> Variable: a
> Type: long
> Total Size: 8 bytes
> 1 values
> Number of Dimensions: 1
> Dimensions and sizes: [1]
> Coordinates:
> Number Of Attributes: 1
> _FillValue : -9999
> (0) 2601123840
>
> Now as to why NCL does not give error messages when you have integer
> overflow, it is because it directly uses
> the underlying C libraries to perform the arithmetic. They don't give
> an error message in this situation so neither
> does NCL. I realize that languages like Ruby and Python may be more
> user friendly in this regard, but you have
> to realize that in an array processing environment like NCL testing
> for overflow on every calculation would
> likely impose a significant cost in performance. It may interest you
> to know (I think this is correct) that the NumPy
> array package for Python does no overflow checking for integers
> either. On the other hand, because it is a mandated
> feature of IEEE floating point arithmetic, there is overflow checking
> (as well as other types of checking) for floating
> point values in NumPy.
>
> I realize that the absence of big integers in 32 bit environments is
> becoming more of an issue. We expect this
> to be solved in the relatively near future as we implement full
> support for NetCDF 4. This support will require
> that we implement a complete set of explicitly sized integer types (8,
> 16, 32, 64 signed and unsigned) that will
> not change (as the long type does now) on different platforms.
> Hope this helps.
> -dave
>
> On May 2, 2007, at 6:29 AM, Saji Hameed wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>>
>>> From: Saji Njarackalazhikam Hameed <saji_at_apcc21.net>
>>> Date: May 2, 2007 9:34:13 AM GMT+09:00
>>> To: Mary Haley <haley_at_ucar.edu>
>>> Cc: David Brown <dbrown_at_ucar.edu>, Rick Grubin <grubin_at_ucar.edu>
>>> Subject: Re: Strange error
>>>
>>>
>>> Hi Mary,
>>>
>>> Thank you for replying and passing on the message to the NCL
>>> developers.
>>>
>>> You are right. But it will be nice, if NCL can return an error
>>> message, instead of erroneous values. An NCL programmer may not
>>> be careful (as in my case) and may erroneously use an expression
>>> that may yield
>>> an integer number bigger than 2^31.
>>>
>>>  o What about a 64-bit machine? Shouldn't NCL compiled for 64-bit
>>>   machines hold bigger integer numbers ? I get the same values in
>>>   our 64-bit machine, running NCL 64-bit binary.
>>>
>>>  o I was using this to calculate something in the context of
>>> outputting
>>>   a huge netcdf file. Since NCL has support for outputting (am i
>>> wrong)
>>>   large netcdf files (>2GB), it may be appropriate to have some
>>> support
>>>   for Big Numbers.
>>>
>>>   - It would be nice, if NCL can automatically convert the type in
>>> such
>>>   situations from ordinary integer to one that can hold Bigger
>>> Numbers
>>>   (i am not conversant with this terminology, so i am afraid my
>>> statement
>>>   may not be clear). Anyway here is an example calculation in Ruby
>>> that
>>>   illustrates this concept
>>>
>>>
>>>   irb(main):001:0> a=35280
>>>   => 35280
>>>   irb(main):002:0> b=a*192*96*4
>>>   => 2601123840
>>>   irb(main):003:0> puts a.class
>>>   Fixnum
>>>   => nil
>>>   irb(main):004:0> puts b.class
>>>   Bignum
>>>   => nil
>>>
>>>
>>>
>>> Best wishes,
>>>
>>> saji
>>>
>>> p.s: We have now set up an automatic climate monitoring system
>>> at the APEC Climate Center that is completely based
>>> on NCL (some glue code is written in Ruby though + NCO is used). The
>>> system accesses specified servers (some of them openDAP) and
>>> retrieves
>>> just the right amount of data everyday at 3pm local time, does
>>> appropriate
>>> analyses and plots some specified figures, all without human
>>> intervention.
>>>
>>> Only possible because of NCL!
>>>
>>>
>>>
>>> * Mary Haley <haley_at_ucar.edu> [2007-05-01 08:44:26 -0600]:
>>>
>>>>
>>>> Hi Saji,
>>>>
>>>> My apologies for letting this one slip. I'm CC-ing our NCL
>>>> developers
>>>> to make sure I have this correct. I think the simple fact of the
>>>> matter is that these are integers, and you can't have an integer
>>>> that
>>>> is bigger than 2^31.
>>>>
>>>> --Mary
>>>>
>>>> On Thu, 26 Apr 2007, Saji Njarackalazhikam Hameed wrote:
>>>>
>>>>>
>>>>> Dear All,
>>>>>
>>>>> I got this strange and a bit frightening values for the
>>>>> following calculation.
>>>>>
>>>>> ncl 0> a=35280
>>>>> ncl 1> print(a*192*96*4)
>>>>> (0) -1693843456
>>>>>
>>>>>
>>>>> I believe that this is because the limit for integer values is
>>>>> reached, but
>>>>> should not NCL return an error or warning message for this.
>>>>>
>>>>> ; Making the numbers floats would give the right value.
>>>>> ;
>>>>> ; ncl 2> print(a*192*96*4.)
>>>>> ; (0) 2.601124e+09
>>>>>
>>>>> I am using NCL version 4.2.0.a035 on a Linux machine.
>>>>>
>>>>> saji
>>>>> ...
>>>>>
>>>>> --
>>>>> Saji N. Hameed
>>>>>
>>>>> APEC Climate Center +82 51 668 7470
>>>>> National Pension Corporation Busan Building 12F
>>>>> Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 saji_at_apcc21.net
>>>>> KOREA
>>>>> _______________________________________________
>>>>> ncl-talk mailing list
>>>>> ncl-talk_at_ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>>
>>>
>>> --
>>> Saji N. Hameed
>>>
>>> APEC Climate Center +82 51 668 7470
>>> National Pension Corporation Busan Building 12F
>>> Yeonsan 2-dong, Yeonje-gu, BUSAN 611705
>>> saji_at_apcc21.net
>>> KOREA
>>>
>>>
>

_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Fri May 04 2007 - 11:40:31 MDT