Re: Re: ut_inv_calendar

Dave,

Sorry about the lack of clarification. You ask a good question about
what's going on with the floating point values.

Regardless of which option you use, you will always get the same
values for each of the year, month, day, hour, minutes, and seconds
quantities (YYYYMM for option=-1/1, YYYYMMDDHH for option=-3/3, etc).

Using the example you indicated below:

   date = 1.9d
   date_at_units = "days since 1980-1-1 0:0:0"
   d = ut_calendar(date,3)

(option=3 returns YYYYMMDDHH and not YYYYMMDD), you get:

   d = 1980010221

This is year = 1980, month = 01, day = 02, and hour = 21. This is a
truncation, because if you additionally look at the minutes and
seconds by using option=0, they are 36 and 0 respectively.

So, even though option=3 returns a double, you are getting the value
"1980010221" and not "1980010221.60" (which would be the fractional
equivalent of 36 minutes and 0 seconds).

When you get down to seconds, they will be truncated. We can
illustrate this with a slightly more detailed example:

   date = (/1.93293d,1.93294d,1.93295d,1.93296d,1.93297d/)
   date_at_units = "days since 1980-1-1 0:0:0"
   d = ut_calendar(date,0)

   do i=0,dimsizes(date)-1
     x = date(i) - 1.
     x1 = (x - floor(x))*24
     x2 = (x1 - floor(x1))*60
     x3 = (x2 - floor(x2))*60
     print("calculated second = " + d(i,5) + ", actual second = " + x3)
   end do

produces:

      calculated second = 25, actual second = 25.152
      calculated second = 26, actual second = 26.016
      calculated second = 26, actual second = 26.88
      calculated second = 27, actual second = 27.744
      calculated second = 28, actual second = 28.608

I'll try to clarify this in the ut_calendar documentation.

--Mary

>
> 19800102.000 - because the result is truncated
> 19800102.900 - because the fractional part is included
> 19800103.000 - because result is rounded to the nearest integer

On Mon, 7 Jul 2008, Dave Allured wrote:

> Mary, ut_calendar takes a floating point number, not an integer, as input.
> (This is divergent from the original topic.) The association with the
> internal Udunits routine is not visible to NCL end users.
>
> Options +2/-2 through +4/-4 must involve some kind of rounding or truncation
> in cases where the input time value is not the exact floating point
> representation of a certain date, with zero residue and zero roundoff error.
>
> For example, suppose date = 1.9, type double, date_at_units = "days since
> 1980-1-1 0:0:0", and option = 3 (YYYYMMDD type double). I could see three
> possible results for ut_calendar(date,3):
>
> 19800102.000 - because the result is truncated
> 19800102.900 - because the fractional part is included
> 19800103.000 - because result is rounded to the nearest integer
>
> I suggest only that this be clarified in the documentation. The current
> documentation is explicit on this issue for options 4 and -5, and
> sufficiently implicit for option 0.
>
> Thanks for your consideration.
>
> --Dave
>
> Mary Haley wrote:
>>
>> The year, month, day, and hour values returned by the internal Udunits
>> routine are all integers to start with, so there's no rounding or
>> truncating going on at the NCL end of things. Only the "seconds"
>> values are returned as float.
>>
>> Now that I think about it, maybe this option '5' should be '-5',
>> since the other negative options return integers...
>>
>> --Mary
>>
>>
>> On Mon, 7 Jul 2008, Dave Allured wrote:
>>
>>> Reading the documentation for ut_calendar, I see that there already are
>>> several other options for specialized result formats. In light of this
>>> and the symmetry issue with ut_inv_calendar, I think it's reasonable to
>>> add option 5 for integers. I would use this option if available. Thanks
>>> to NCL for adding this one.
>>>
>>> For options +2/-2 through +4/-4, YYYYMM etc. as type double or integer,
>>> are the time values rounded or truncated? I suggest that this be added to
>>> the documentation.
>>>
>>> --Dave
>
> <snip>
> _______________________________________________
> ncl-talk mailing list
> ncl-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Mon Jul 07 2008 - 21:28:16 MDT