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
_______________________________________________ Therion mailing list [email protected] https://mailman.speleo.sk/listinfo/therion
