real numbers in Intkey

[Kevin Thiele]

- From: Eric Zurcher

> The proposal you described earlier sounds interesting in that it 
> apparently attempts to allow for different levels of measurement 
> precision by the key designer vs. the key user. I can see the value of 
> that: the designer might have encoded a range of (for example) 
> 3.35-3.85 mm for a taxon; but a user attempting to identify a specimen 
> from the large end of the range, yet able to measure only to the 
> nearest 0.5 mm, might enter a value of "4", which would falsely 
> exclude the taxon.
>
> But the problem I see with this is: how can you reliably infer this 
> precision? In my hypothetical example, the key user can measure to the 
> nearest 0.5 mm. If she enters a value of, say, "4.5", how can Lucid 
> "know" that this reflects a range of 4.25-4.75, rather than a range of 
> 4.45-4.55? There is also a problem with non-fractional values: Does 
> "200" infer a range of 150-250, 195-205, or 199.5-200.5?
>
> I don't see any reliable way get around this problem aside from 
> burdening the user with the need to indicate the estimated error 
> associated with their measurements.

Hi Eric,

I suppose we are making what seems to me to be a standard decimal 
assumption: viz, that if a value is entered with no decimal points (e.g. 
4) then we assume a precision of +/- 0.5 (that is, 3.5-4.5); if a value 
is entered with one decimal point (e.g. 4.0) we assume +/- 0.05 (that 
is, 3.95-4.05).

You're quite right that we can't account for cases where someone wishes 
to nominate another precision - e.g. if someone enters 4.5 and wants to 
state a precision of +/- 0.25, as in your example. Requiring that a user 
nominate their precision precisely would be ideal but would a pain all 
round.

The solution we've implemented is imperfect with respect to such defined 
precisions, but it still seems better to me than the key chucking out a 
taxon coded as 4-5 because a user enters 3.99

The last issue you raise is interesting. In Lucid (as I think in DELTA) 
we require that all numeric data for a given numeric character be 
recorded using the same units - we don't allow one taxon to be recorded 
as having leaves 1-2 mm long (using mm as the unit of measurement) and 
another as having leaves 1-2 m long (using m as the unit). Hence, if 
leaf length is recorded in mm and taxon x is 1-2 and taxon y is 100-200, 
we would treat 1-2 as including 0.5-2.5 (if the user entered an integer 
value) and taxon y as 99.5-200.5. But of course, one could expect a 
larger error for the larger taxon. This would be better handled using a 
percentage error directive such as you have. But this is a separate 
issue and requires a separate solution (unless, getting back to the 
point above, we could allow x to be recorded as 1-2 mm and y as 1-2 m, 
in which case our method would also allow for scaleability of the error. 
But this would be clumsy).

Cheers - Kevin