*solve - a bug in survex having this among data ?

[Wookey]

+++ Andy Waddington [05-09-15 23:51 +0100]:
> On Thursday 2005-09-15 16:08, Olly Betts wrote:
> 
> > The problem is that the file is processed in order, and each *solve
> > executed when it is seen, so you must have the *fix before the first
> > *solve, and also the *equates to link each survey to the previous
> > one must be with the survey which they apply to, not all at the end.
> 
> Way back when we were trying to dream up a universal cave survey
> data exchange format, it was one of my most cherished requirements
> that there should be a definition of a format to describe a cave survey,
> and perhaps, a definition of a format to say what to do with those data,
> but that the two were of a differnet order entirely and should not be
> mixed.
> 
> *solve falls into the category of things you tell your program to do with
> the survey data, and I still think it is quite inappropriate to be in a file
> which contains the raw data.

True - it's a hack - you should normally never have any *solves. But it's quite handy.

In theory you would have external info saying 'read this, solve, read the
other, solve', but in practice that's going to end up with a file almost
exactly the same as a survex data file with a *solve in it.

If you want to try an implment a proper, clean 'external info', feel free.
It could list a set of survey-groups to process, for example. 

On the other hand you can view *solve as being part of the dataset if you
look at it as a label that says 'this part of the dataset is independent of
later data'. In that sense it is not an action, but a part of the dataset. I
have to admit I don't find this argument terribly convincing, because a
dataset can be process with or without *solves, so it's not intrinsic.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/