[Therion] Handling of tape and backtape in survey data

[Bill Gee]

Hi Olly -

Many thanks for the answers.  I think I will give BACKTAPE a try the next time I do some survey, if only to see what happens.

My question about significant digits is really related to how much precision can and should be carried through a calculation.  If compass readings are taken to four significant digits, then the mean of two such numbers is really only good to about three and a half significant digits.  Displaying more significant digits implies more precision that actually exists.  A compass reading even from a DistoX2 is probably accurate to only +/- 2 least significant digits.

https://en.wikipedia.org/wiki/Significant_figures[1]

However, you have an excellent point about easting and northing data.  Those number can be measure accurately to enough significant digits that a double-precision data type is needed.

Speed is not an issue.  Survex and Therion both compile my biggest maps in seconds.  Shaving a few seconds is of little benefit.

And to your last comment about furlongs ...  LOL!  I remember a huge argument some years ago about what the speed of light is in furlongs per fortnight.  It was a hoot!

Thanks!

========
Bill Gee




On Monday, December 27, 2021 3:56:04 PM CST Olly Betts wrote:
> On Sat, Dec 25, 2021 at 08:50:26AM -0600, Bill Gee wrote:
> > 1) Does Therion also recognize the BACKTAPE data type?
> 
> It seems not - there's no match in the source code repo for:
> 
> git grep -i BACKTAPE
> 
> > 2) What does Survex do if both TAPE and BACKTAPE are given?  Does it
> > average the two readings?  Does Therion do the same thing?
> 
> Survex warns if they differ by more than 3 standard deviations, and then
> takes the mean of the readings.
> 
> > I understand that Therion will use Survex to reduce the centerline
> > data - if Survex is installed.  In case Survex is NOT installed, then
> > Therion reduces the centerline itself.  As a result they might handle
> > this situation differently.
> 
> Also, Therion generates a .svx file behind the scenes, but not
> necessarily the .svx file you'd write yourself given the same data.
> For example, I think Therion collapses backsights to a single reading
> itself before processing with Survex.
> 
> > As I write this, another related question occurred to me.  When either
> > Therion or Survex averages a forward and backward reading, how many
> > significant digits does it carry in the calculation?  Can the
> > significant digits be changed?
> 
> Survex uses double precision for this:
> 
> https://en.wikipedia.org/wiki/Double-precision_floating-point_format
> 
> That has 15-17 significant decimal digits - i.e. many more than matter
> here.
> 
> Using more precision seems overkill.
> 
> If you really want to use fewer it should be possible to build cavern
> to use single precision, but I don't think anyone actually does this.
> We made it an option as decades ago it seemed you might want to do this
> to reduce memory usage (4 bytes per floating point number instead of 8)
> but cavern's memory use is very modest by modern standards, and single
> precision only gives 6-9 significant decimal digits, which isn't even
> enough to reliably store a UTM Northing to the nearest metre so you'd be
> limited in what coordinate systems you could use in such a build.
> 
> I don't see why you'd want to be able to dynamically force rounding to
> fewer significant figures - what's the benefit?
> 
> Downsides of rounding are it would slow things down a bit, and it risks
> introducing systematic biases - a dumb example to make the issue
> clearer: if all readings are to the nearest inch and you round the
> average to the nearest inch and always round 0.5 up, then then assuming
> an even distribution there's an average bias of +0.25 inches on each
> tape reading.  The problem with systematic biases is they accumulate
> rather than tending to cancel.
> 
> There are other rounding schemes which try to address this sort of
> issue (like rounding 0.5 to the nearest even number) but it's hard to be
> certain they might not introduce a more subtle bias (some cave systems
> have dominant direction passage develops along so the distribution is
> may not uniform across odd and even) and there doesn't seem a compelling
> reason to be rounding in the first place.
> 
> > And the same question applies to loop closure calculations.  How many
> > significant digits are carried through the calculations?
> 
> The same.
> 
> The final results are then stored in the .3d file to the nearest cm
> (that's 0.000049710 furlongs for our US readers).  That precision was
> chosen so that coordinate values will fit in a 32 bit integer, and seems
> adequate for the final results.
> 
> Cheers,
>     Olly
> 



--------
[1] https://en.wikipedia.org/wiki/Significant_figures
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20211227/19d83b4b/attachment.htm>