Default value for precision

Specifications ADL
1

DV_PROPORTION Class has an optional “precision” attribute.

When “precision” is not specified in ADL it is unconstrained. What is the default in this case: 0 or -1?

I guess it is -1 but cannot find where this is specified.

DV_PROPORTION[id9002] occurrences matches {0..1} matches {
    numerator matches {|0.0..1.0|}
    type matches {1}
}

From the specification: “The value -1 implies no limit, i.e. any number of decimal places.”
For the UI unlimited decimal places doesn’t look good :wink:
Is there a reasonable default to use for -1?

2

In the XML Schemas the default is set to -1

image

1 Like
3

Well the idea is to place no limit on the value within the data. If the UI imposes say 0 or 1 or 2 place (s) then that is guaranteed to generate valid data.

4

Thank you! Found it in the XML Schema (which I don’t use :blush:).

There is no such default in JSON Schema.

So the question is how did the -1 get into XML Schema? There is no default value for “precision” in BMM files. Was this default added to XML from UML? Or by hand?

p.s.
It would be enough to add a mention of the default to the specifications on the web.

5

It really has to stay as unconstrained unless it has been constrained in the archetype or template. I appreciate this messes up auto-UI but it is really the responsibility of the template owner to go and fix it. The UI should not make any assumptions IMO, or at least they should not be fixed. So it is ok, I think to assume 2 decimal places if unconstrained but that needs to be overridable to whatever is in the template

2 Likes
6

Funny how the two of you assume -1 as 2 decimal places. I assumed 16 :blush: (they are not displayed if not needed).

May I share a screenshot of my auto-UI :innocent: (FiO2 is unconstrained precision field):

Screenshot 2022-03-11 at 11.14.33
Screenshot 2022-03-11 at 11.14.33776×666 45.2 KB

7

We have this problem in our system as well, and haven’t solved it perfectly. There are some possibilities in the Form Design or View definition tooling to limit the number of decimals. The base line will however be what the person responsible for the archetype and the template has defined.

I think we also tend to choose 2 decimals as a default (but have to check further…)

1 Like
8

Theoretically, precision is really the total number of digits in a value, not just the fractional part. If you are working with numbers in the 10^6 range, having 6 decimal places as well is usually useless - probably you don’t need any. But if you are in the 0…1 range, you may want just that.

So a good rule of thumb is to fix the total number of digits to e.g. 4, 6, 8, 10 or whatever, not just the number to the right of the decimal point.

9

That’s a surprise to me, and I 'm pretty sure the tooling applies it to decimal places.

10

Agree. However specifications are explicit: “number of decimal places”.

1 Like
11

Arguably wrong :wink:

1 Like
12

It does because it’s following the specs, which are not quite right. See Wikipedia - significant figures and this table:

sig_figs

The specs are doing the right hand column, but the correct way is the left-hand column.

I don’t know how much the precision field is used, so fixing the definition may be problematic to existing data.

13

Interesting, but I believe that defining the fractional digits as precision is also acceptable, even if maybe less common (scientifically).

And, it is explicitly defined as such in the specs - including functions like is_integral that are based on it - so there is no doubt.

I don’t see a sufficient reason to change this. Given that there‘s also the accuracy, magnitude + fractional digits precision works just fine, in real life? (Or at least not worse than if the definition of precision was different)

5 Likes
14

Agree completely. I didn’t mean to imply that we should change it concretely, was just making a philosophical point :wink:

15

Isn’t there a confusion here with Resolution, which is the no. of digits used to describe the smallest detectable value. It may be constrained for pragmatic reasons in UI, but if a hi-resolution instrument is used, the full resolution might be persisted for further processing, to reduce the compounding of error.

Precision however, is the random variability of a value when repeated, so can be expressed as

  • %
  • SD, variance or other statistical derivatives
  • a defined range of +/- values e.g. for weight in kg, +/- 0.1kg.

(Accuracy is the systematic variation in a measure from the true value, e.g. calibration bias)

These definitions are from the International Vocabulary of Metrology

e.g.
“Resolution: smallest difference between indications that can be meaningfully distinguished.”

1 Like
16

The above IVM gives a coherent set of terms, unlike the Wikipedia article cited e.g. where " Significant figures (also known as the significant digits , precision or resolution ) of a number in [positional notation] are [digits] in the number that are reliable and necessary to indicate the quantity of something." is contradictory or incoherent.
In the IVM
Precision is random variation in repeated measures, so only calculable statistically
Accuracy is systematic variation, so potentially calculable arithmetically
Resolution is as posted above, so in engineering terms the resolvable detail, also calculable arithmetically

They are frequently transposed in dialogue and non-scholarly writing, so are “acceptable” only by custom and practice, so its ad-hoc meaning must be explained in each instance - surely not satisfactory?

Further, if “Precision” is mis-used in place of Resolution, then what is to be used for its proper meaning as above? Surely this is very relevant to healthcare data, where biological (effectively random) variations are widespread? This limits the resolution that is worth achieving by instruments.

So if this seems a philosophical point, yes it is in the old sense of "scientific "
Shouldn’t openEHR’s use of these key metrology terms be consistent?

17

No argument there, and agree that the term ‘resolution’ is the one we should use. I think the best we could do to the specifications is to improve the text, but not to change the name or semantics of the ‘precision’ attribute, since that would be a breaking change.

@colinbro could you please raise a Problem Report here, with a link to this discussion and/or pasted in text, particularly that link above.

1 Like
18

OK, raised as Problem Report [SPECPR-389] - openEHR JIRA
Unfamiliar with that, please edit various fields as needed, or advise

2 Likes