I just uploaded v1.0_2 which has some tests that revel the smoking gun
or at least a little whiff of gun smoke.
All fail reports I've seen are for a single failed test to see if data
values for -180 and 180 degrees longitude are the same for all latitudes
in the file from pole to pole inclusive. That's .6 degree interval for
301 points total. The specific point that fails is 89.4 degrees. These
files scan south to north so this is the last latitude except the 90 or
the pole. Since the pole is a point, all longs should have the same
value. It may "fail" for 90 north too and still pass this test.
The data in the file is stored as a continuous sequence of 32 bit values
starting at a given point in the file. The data for this type of GRIB
file scans a row of longs west to east 180 to 180 degrees and lats from
south to north -90 to 90. The first data point is (-90,-180) and the
last is (90,180). Data point (-89.4,-180) is 601 further into the file
than (-90, -180).
I have a method called lalo2offset() that takes a lat and long and
returns an offset into this data. I've demonstrated that it returns a
different value for both (89.4, -180) and (98.4, 180) on 64bit use
longdouble systems than on any other CPAN Testers system. It's off by one.
The code is this:
# shift long east until Lo1 = 0 and make sure any long
# > 360 degrees is moved back into the range of 0 - 360
$thislong = $long + $self->lo_shift;
if ( $thislong > 360 ) {
$thislong -= 360;
}
$out = ( ( ( $lat - $self->La1 ) / $self->LaInc ) * $self->Ni )
+ ( ($thislong ) / $self->LoInc );
return sprintf "%d", $out;
-------------------------------------------------------------------
lo_shift = 180 so for -180 and 180 $thislong is 1 and 360
$lat = 89.4
La1 = -90
LaInc = LoInc = .6
Ni = 601
Using my HP calculator--
for $long = -180, (((89.4 - -90)/.6) * 601) + (0 /.6) = 179699
for $long = 180, (((89.4 - -90)/.6) * 601) + (360 /.6) = 180299
On 64bit uselongdouble systems lalo2offset() returns 179698
and 180298.
Hmmm! I'm still investigating. I'm preparing a new test will explore
this bug in more detail.
At this point I won't be surprised to find something wrong with my
assumptions...
