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
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
>