Re: NCL bug

From: Dave Allured <dave.allured_at_nyahnyahspammersnyahnyah>
Date: Wed Sep 14 2011 - 17:11:31 MDT

Gus,

No, a system restart should not normally change roundoff behavior.
What *might* change behavior is any change at all in your test
script, including print statements.

You indicated that the behavior was reproducible, at least
sometimes. If you can get the discrepancy to reproduce, please
print relevant values with sprintf to 9 significant digits for type
float. (That length should be enough to guarantee that you are
seeing unique binary values.)

Try retesting with your exact original test script. If the behavior
changes when a print statement is added, or with other seemingly
unrelated changes, that is significant, and you should follow up
with Mary Haley and NCL support. Otherwise, I can't say more
without speculating.

I tried your original script on two platforms, NCL 5.2.1 on Mac OS,
and NCL 5.1.1 on 64-bit Linux, and got the answer !Equal! in both cases.

--Dave

On 9/14/2011 3:03 PM, Ghassan J. Alaka, Jr. wrote:
> Dave,
>
> Sorry for the delay in my response. I appreciate your attention to this
> matter.
>
> When I ran the sample code you provided, I got the same floating point
> number for y and x(90). This made me a bit suspicious, so I ran my
> nclbug.ncl code (Attached below) to make sure I was still having the
> same problem. Sure enough, x(90) = 0.9 this time around, so the
> "problem" is hiding for a bit or somehow got fixed. The only difference
> is that I restarted my system. Can the floating point roundoff change
> just by restarting the system?
>
> Gus
>
> On 9/12/11 1:02 PM, Dave Allured wrote:
>> Gus,
>>
>> This is a classic example of roundoff error. The number 0.9 does not
>> have an exact representation in standard floating point binary. Your
>> code has computed 0.9 as an NCL "float" by two different methods:
>>
>> (1) x = ispan(0,100,1)*.01, then take x(90)
>> (2) Entered directly as an NCL constant "0.9"
>>
>> Now, the NCL print statement does *not* display all significant digits
>> by default. If you show all significant digits with the sprintf
>> function, the issues will become clearer:
>>
>> mac56:~ 3> ncl
>> NCAR Command Language Version 5.2.1
>> ncl 1> x = ispan(0,100,1)*.01
>> ncl 2> y = 0.9
>> ncl 3> print (sprintf ("%15.9f", x(90)))
>> (0) 0.899999976
>> ncl 4> print (sprintf ("%15.9f", y))
>> (0) 0.899999976
>>
>> On my system, the two methods get exactly the same floating point
>> number. But floating point roundoff can vary from system to system.
>> Do you get two different numbers by the above method?
>>
>> --Dave
>>
>> On 9/12/2011 10:49 AM, Ghassan J. Alaka, Jr. wrote:
>>> Hi,
>>>
>>> I have found a bug in NCL version 5.1.1, although a colleague of
>>> mine confirmed that the same error in NCL version 6.0.0.
>>>
>>> If I create an array (called "x") that contains increments from 0 to
>>> 1 by 0.01, I run into problems when x should equal 0.9. The print()
>>> function says that x(90) = 0.9, yet x(90)> 0.9 after some
>>> investigation. This only seems to be occurring at x = 0.9. Why is
>>> this the case?
>>>
>>> I have attached a simple script to view this error.
>>>
>>> Thank you,
>>> Gus Alaka
>>>
>>>
>>> nclbug.ncl
>>>
>>>
>>>
>>>
>>> ;================================================================
>>> ; Load scripts
>>> ;================================================================
>>>
>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl"
>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_csm.ncl"
>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/shea_util.ncl"
>>>
>>>
>>> begin
>>>
>>> ;x = fspan(0.,1.0,101)
>>> x = ispan(0,100,1)*.01
>>>
>>> val1 = ind(x.eq.0.1)
>>> val2 = ind(x.eq.0.5)
>>> val3 = ind(x.eq.0.9)
>>>
>>> print(""+val1)
>>> print(""+val2)
>>> print(""+val3)
>>> print(""+x(90))
>>>
>>> if(x(90).eq.0.9)then
>>> print("!Equal!")
>>> end if
>>>
>>> if(x(90).lt.0.9)then
>>> print("!LessThan!")
>>> end if
>>>
>>> if(x(90).gt.0.9)then
>>> print("!GreaterThan!")
>>> end if
>>>
>>> ; if x(90) = 0.9 (as seen from print()), why doesn't x(90) = 0.9?
>>> ; This problem does not seem to exist at 0.8, 0.7, 0.6, etc.
>>>
>>> end
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Sep 14 17:11:20 2011

This archive was generated by hypermail 2.1.8 : Fri Sep 16 2011 - 11:24:25 MDT