Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Andy Armstrong <andy@he...>  20060714 00:25:56

I've added wbtbin to the testo test harness script. The test method is to transform reference/wbt200.bin into a gpx file and compare it against a baseline gpx file (reference/wbt200.gpx). The test's failing when run on a different platform than the one that created the baseline data because the speed field  which is computed  varies pretty wildly from platform to platform with the same input data. In one case a speed that's calculated as 0.026882 m/s on one platform is computed as 0.000000 on another  but the error isn't always the same. Here's the code I'm using: wpt>speed = radtometers( gcdist(RAD(st>plat), RAD(st>plon), RAD(lat), RAD(lon))) / (rtim  st>ptim); I've added debug so that the code now looks like this: double speed, gcd, dtim, rtm; gcd = gcdist(RAD(st>plat), RAD(st>plon), RAD(lat), RAD(lon)); dtim = rtim  st>ptim; rtm = radtometers(gcd); speed = rtm / dtim; db(4, "Speed: %f (gcd=%.10f, dtim=%f, rtm=%.10f, %f, %f > %f, %f, % lu > %lu)\n", speed, gcd, dtim, rtm, st>plat, st>plon, lat, lon, (unsigned long) rtim, (unsigned long) st>ptim); Here's the kind of output I'm seeing (this is the diff between a run on a Mac OS X box and a Linux box): 190,194c190,194 < Speed: 0.000000 (gcd=0.0000000000, dtim=5.000000, rtm=0.0000000000, 54.786850, 2.344346 > 54.786851, 2.344346, 1150135427 > 1150135422) < Speed: 0.019008 (gcd=0.0000000149, dtim=5.000000, rtm=0.0950416476, 54.786851, 2.344346 > 54.786852, 2.344345, 1150135432 > 1150135427) < Speed: 0.019008 (gcd=0.0000000149, dtim=5.000000, rtm=0.0950416476, 54.786852, 2.344345 > 54.786853, 2.344345, 1150135437 > 1150135432) < Speed: 0.026882 (gcd=0.0000000211, dtim=5.000000, rtm=0.1344091870, 54.786853, 2.344345 > 54.786853, 2.344344, 1150135442 > 1150135437) < Speed: 0.026882 (gcd=0.0000000211, dtim=5.000000, rtm=0.1344091870, 54.786853, 2.344344 > 54.786854, 2.344342, 1150135447 > 1150135442)  > Speed: 0.019008 (gcd=0.0000000149, dtim=5.000000, rtm=0.0950416476, > 54.786850, 2.344346 > 54.786851, 2.344346, 1150135427 > > 1150135422) > Speed: 0.000000 (gcd=0.0000000000, dtim=5.000000, rtm=0.0000000000, > 54.786851, 2.344346 > 54.786852, 2.344345, 1150135432 > > 1150135427) > Speed: 0.000000 (gcd=0.0000000000, dtim=5.000000, rtm=0.0000000000, > 54.786852, 2.344345 > 54.786853, 2.344345, 1150135437 > > 1150135432) > Speed: 0.000000 (gcd=0.0000000000, dtim=5.000000, rtm=0.0000000000, > 54.786853, 2.344345 > 54.786853, 2.344344, 1150135442 > > 1150135437) > Speed: 0.019008 (gcd=0.0000000149, dtim=5.000000, rtm=0.0950416476, > 54.786853, 2.344344 > 54.786854, 2.344342, 1150135447 > > 1150135442) Assuming that hasn't wrapped too badly you can see that the input values are the same on both platforms  but that the output value of gcdist() differs considerably. This would appear to be the source of the error  I assume the values getting passed into gcdist() are at the limit of the range of the trig functions therin. Does anyone have an opinion on whether this is likely to be correct and how it should be fixed?  Andy Armstrong, hexten.net 
From: Ron Parker <ron@pa...>  20060714 00:39:03

Andy Armstrong wrote: > Assuming that hasn't wrapped too badly you can see that the input values > are the same on both platforms  but that the output value of gcdist() > differs considerably. This would appear to be the source of the error  > I assume the values getting passed into gcdist() are at the limit of the > range of the trig functions therin. > "considerably" is a bit of a stretch... > Does anyone have an opinion on whether this is likely to be correct and > how it should be fixed? > > I think there wouldn't be any shame in rounding the results from gcdist to the nearest 1e7. One meter is about 1.6e7, so that'll get you pretty close most of the time. I'm not sure whether I'd recommend trying to put the rounding into the current gcdist function, though, or just doing it in your own code. On the other hand, if the distances really are on the order of 13 centimeters, your speed can't be all that high. Are you rounding it to a sane number of sigfigs? 
From: Andy Armstrong <andy@he...>  20060714 00:55:19

On 14 Jul 2006, at 01:39, Ron Parker wrote: > "considerably" is a bit of a stretch... I meant in a lexical sense  I realise the actual errors are tiny :) >> Does anyone have an opinion on whether this is likely to be >> correct and >> how it should be fixed? > > I think there wouldn't be any shame in rounding the results from > gcdist to the nearest 1e7. One meter is about 1.6e7, so that'll > get you pretty close most of the time. OK. > I'm not sure whether I'd recommend trying to put the rounding into > the current gcdist function, though, or just doing it in your own > code. I'll add it to my own code. > On the other hand, if the distances really are on the order of 13 > centimeters, your speed can't be all that high. Are you rounding > it to a sane number of sigfigs? I'm rounding the gcdist to 1e7 now  and it's solved the problem, thanks :) There's another patch coming your way Robert...  Andy Armstrong, hexten.net 
Sign up for the SourceForge newsletter:
No, thanks