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