Stream: fhirpath
Topic: Decimal = vs ~
Bryn Rhodes (Feb 01 2019 at 06:21):
GF#19356 points out that the test in the testDivide group, 1.2 / 1.8 = 0.67 is behaving with equivalent semantics, not equality semantics. We should either change the test to use equivalent or clarify that the equality semantics round to the least precise value, the same as equivalent semantics do.
Grahame Grieve (Feb 01 2019 at 19:58):
The question we should ask is firstly about functional outcomes - how do we want equality to work, and how do we want equivalence to work?
Grahame Grieve (Feb 01 2019 at 19:59):
under the current exact match rules, we cannot do 1.2 / 1.8 = X because there's no way to express the internal imprecision of a 32 bit floating point number in decimal
Grahame Grieve (Feb 01 2019 at 20:01):
in other implementations, I've done = means to the lowest precision, and ~ means +/- 5%
Bryn Rhodes (Feb 01 2019 at 20:26):
When you say lowest precision, I'm confused, because the test says 1.2/1.8 = 0.67, but 1.2/1.8 = .666666..., but are we saying that we want the least precise (i.e. two digits of precision in this case)?
Paul Lynch (Feb 01 2019 at 20:30):
There is also some confusion about the meaning of precision. My understanding was that the FHIRPath meaning of precision was the number of digits after the decimal place. "1.2" has two significant digits, but one digit of precision.
Bryn Rhodes (Feb 01 2019 at 20:30):
That's my understanding of precision.
Bryn Rhodes (Feb 01 2019 at 20:31):
But saying "lowest precision" to me implies 0.0000001 (assuming 8 digits of precision).
Paul Lynch (Feb 01 2019 at 20:32):
So, in that case, 1.2/1.8 ~ 0.7.
Oh- - I read "lowest precision" meaning "least precision".
Grahame Grieve (Feb 01 2019 at 20:47):
I did indeed mean least precision. but yes, I should have been talking about significant digits
Paul Lynch (Feb 01 2019 at 20:50):
I don't think the concept of significant digits has any place in fhirpath.
Grahame Grieve (Feb 01 2019 at 20:53):
so you don't think we should be able to say 1.2/18 = X?
Paul Lynch (Feb 01 2019 at 20:56):
I don't know what to do about 1.2/1.8 =. But, the FHIRPath spec deals with digits of precision, by which I understand it to mean digits after the decimal point. Maintaining precision, 1.2/1.8 would be 0.7. Maintaining significant digits, 1.2/1.8 would be 0.67. [Edit: I was avoiding using operators here. I am not saying what FHIRPath's "=" should be, but just showing the distinction between the two concepts of significant digits and precision.]
Bryn Rhodes (Feb 01 2019 at 21:05):
I disagree.
Bryn Rhodes (Feb 01 2019 at 21:06):
I think 1.2/1.8 is 0.6666667
Bryn Rhodes (Feb 01 2019 at 21:06):
This is just talking about whether we need to say that to get a true out of the equality comparison.
Bryn Rhodes (Feb 01 2019 at 21:08):
Otherwise, we'd have to carry that precision semantic through all the operators. I don't think we're suggesting that, right?
Bryn Rhodes (Feb 01 2019 at 21:09):
So the proposed change is for =, values must be equal, comparison is done on values rounded to the precision of the least precise operand. Trailing zeroes after the decimal are ignored in determining precision.
Paul Lynch (Feb 01 2019 at 21:09):
The same as a for ~?
Bryn Rhodes (Feb 01 2019 at 21:10):
And for equivalence: values must be equal within +/-5%, with comparison done on values rounded to the precision of the least precise operand. Trailing zeroes after the decimal are ignored in determining precision.
Paul Lynch (Feb 01 2019 at 21:10):
+/- 5% of which operand?
Bryn Rhodes (Feb 01 2019 at 21:14):
Good question, Grahame? My take is that the absolute value of the difference between them is less than 10 times the place value of the comparison precision.
Bryn Rhodes (Feb 01 2019 at 21:48):
Mulling this a bit more, if we do this, it means 0.1 = 0.15 will be true. Is that really what we want?
Paul Lynch (Feb 01 2019 at 21:49):
I think you mean 0.1 ~ 0.105.
Bryn Rhodes (Feb 01 2019 at 21:50):
No, I mean 0.1 = 0.15.
Bryn Rhodes (Feb 01 2019 at 21:50):
If equal is defined as the values are the same to the least precise value, then the comparison would be performed at the tenths-place, and it would return true.
Paul Lynch (Feb 01 2019 at 21:51):
Oh. But, in that case at least, 0.15, rounded to 1 digit of precision would give you 0.2.
Bryn Rhodes (Feb 01 2019 at 21:54):
True, missed that. So 0.1 = 0.14 is true.
Paul Lynch (Feb 01 2019 at 21:56):
I think I would prefer to just say that 1.2/1.8 = 0.66666667
Bryn Rhodes (Feb 01 2019 at 21:58):
Me too, 0.1 = 0.14 is a bridge too far, I think.
Brian Postlethwaite (Feb 02 2019 at 04:02):
Doesn't that depend what you are measuring?
Brian Postlethwaite (Feb 02 2019 at 04:08):
A change in temp of 5% F or C are different if we're comparing freezing point temps
Grahame Grieve (Feb 02 2019 at 21:15):
I do indeed carry semantic precision through. But I don't understand 1.2/1.8 = 0.66666667 - where did the choice of precision come from? is 1.2/1.8 != 0.6666667 ?
Grahame Grieve (Feb 02 2019 at 21:15):
what about 1.2/1.8 = 0.666666667 ?
Lloyd McKenzie (Feb 02 2019 at 21:47):
Is my understanding correct that, based on significant digit rules, 5 = 4.9? If so, does that mean that 4.9 >= 5?
Bryn Rhodes (Feb 03 2019 at 22:09):
@Lloyd McKenzie , the current specification just says decimal values must be "exactly equal". The proposal being considered here is to relax that to say that the comparison is done by rounding the operands to the precision of the least precise operand, but that has some significant effects, one of which you are pointing out (5 = 4.9 would be true).
Bryn Rhodes (Feb 03 2019 at 22:13):
@Grahame Grieve , the suggestion comes from the required precision of 8 digits. Systems may support more precision, but they must support at least 8. But the test would only work for systems that supported exactly that level of precision. The simplest option is, as the comment suggests, to change the test to use equivalent rather than equal.
Lloyd McKenzie (Feb 03 2019 at 22:14):
5 = 4.9 I could almost live with. 4.9>= 5 is pretty scary...
Grahame Grieve (Feb 03 2019 at 22:36):
so
1.2 / 1.8 = 1.6666667
1.2 / 1.8 = 1.666666667
1.2 / 1.8 != 1.666667
1.2 / 1.8 != 1.67
1.2 / 1.8 ~1.67
1.2 / 1.8 !~ 1.6
Grahame Grieve (Feb 03 2019 at 22:37):
1.2 / 18000000 = 0.0000001
Grahame Grieve (Feb 03 2019 at 22:38):
12000000/1.8 = 6666666.6666667
Bryn Rhodes (Feb 03 2019 at 22:38):
1.2 / 1.8 = 1.66666666 (to whatever precision your platform specifies)
Grahame Grieve (Feb 03 2019 at 22:39):
I'm just sticking with 8 digits... I have whatever precision is desired, but actually use significant figures, since the maths was developed for UCUM...
Bryn Rhodes (Feb 03 2019 at 22:42):
1.2 / 18000000 = 0.00000006, right? (or 7 if you're rounding it)
Grahame Grieve (Feb 03 2019 at 22:42):
ah yes, I miscounted
Paul Lynch (Feb 04 2019 at 15:25):
I'm just sticking with 8 digits... I have whatever precision is desired, but actually use significant figures, since the maths was developed for UCUM...
@Grahame Grieve Significant digits present a couple of difficulties. 1) You have to keep track of trailing zeros somehow, because 1.00 has more significant digits that 1.0, but if you store that as a number the computer won't see the difference; 2) There is ambiguity in interpreting the number of significant digits for a number like "100". If one uses significant digits, ideally the numbers should be entered in scientific notation (e.g. 1.23*10^6) to make it clear how many significant digits are meant, but it seems unlikely that someone filling in a form of (for example) blood pressure readings would do that.
Grahame Grieve (Feb 04 2019 at 19:34):
I keep track of the significant figures so I can see a difference. The ambiguity is build into the human representation and nothing I can do about that
Last updated: Apr 12 2022 at 19:14 UTC
