Stream: hapi
Topic: Ucum library question
Grahame Grieve (Jul 04 2018 at 22:21):
see https://github.com/FHIR/Ucum-java/issues/7 : which classes should I add equals etc to, and what's the grounds for equality?
My working answer for the first question is Decimal and Pair.
My working answer for the second question is, 'by decimal representation' but that's not fully correct in the corner cases - but where it's not correct, I don't know what would be.
@Bryn Rhodes @James Agnew @Patrick Werner
Bryn Rhodes (Jul 04 2018 at 22:32):
Consider Unit as well?
Bryn Rhodes (Jul 04 2018 at 22:33):
As far as the grounds for equal, that they are the same value at the maximum precision of either input?
Grahame Grieve (Jul 04 2018 at 22:36):
it should be the minimum precision if we're going to think like that
Bryn Rhodes (Jul 04 2018 at 22:36):
But then 1 would equal 1.1, we don't want that, right?
Grahame Grieve (Jul 04 2018 at 22:36):
but the real question for me is: are we trying to object equals,or concept equals?
Grahame Grieve (Jul 04 2018 at 22:37):
we might well want 1 to equal 1.1, though we wouldn't want 1.0 to equal 1.1
Bryn Rhodes (Jul 04 2018 at 22:37):
Depends how it's being used in the code, the bug report indicates it's being used as concept equals, but is implemented as object equals.
Bryn Rhodes (Jul 04 2018 at 22:38):
It's hard to imagine how it would be useful as an object equals.
Grahame Grieve (Jul 04 2018 at 22:39):
hmm that's not quite what I mean. lt's be more specific:
is 1.0000e2 = 10.000e1?
Grahame Grieve (Jul 04 2018 at 22:39):
do we want to know whether they are the same representation or have the same meaning?
Bryn Rhodes (Jul 04 2018 at 22:40):
I would say yes, but that's because I'm assuming that this is being used in the context of determining whether or not two quantities are the same, and I wouldn't want different representations of the same value to cause that to be false.
Grahame Grieve (Jul 04 2018 at 22:41):
well, let's see what Patrick as to say...
Michael Lawley (Jul 04 2018 at 22:41):
In Java would generally adopt the pattern of equals being object equals and have a separate method for concept equals (if required)
Grahame Grieve (Jul 04 2018 at 22:41):
because usually questions about equals are actually questions about lists and maps
Grahame Grieve (Jul 04 2018 at 22:42):
yes I have this:
public boolean equals(Decimal value, Decimal maxDifference) {
Decimal diff = this.subtract(value).absolute();
return diff.comparesTo(maxDifference) <= 0;
}
Patrick Werner (Jul 05 2018 at 20:58):
I would say yes, but that's because I'm assuming that this is being used in the context of determining whether or not two quantities are the same, and I wouldn't want different representations of the same value to cause that to be false.
i totally agree. Different representations of the same value should equal. I personally would ignore precision for equals(), as considering it will make it complicated.
1 precision 1 should equal 1 precision 2
Patrick Werner (Jul 05 2018 at 20:59):
so basically i'm thinking about object equals ignoring precision.
Grahame Grieve (Jul 05 2018 at 21:10):
you can never ignore precision. Does 1.01 equal 1?
Patrick Werner (Jul 05 2018 at 21:28):
no, but 1 to 1.0 or 1.00
Grahame Grieve (Jul 05 2018 at 21:37):
well, you are ignoring precision selectively.
Grahame Grieve (Jul 05 2018 at 21:37):
because 1 = 1.01 in most scientific frameworks
Grahame Grieve (Jul 05 2018 at 21:37):
where as 1.00 != 1.01
Patrick Werner (Jul 10 2018 at 12:16):
after further reflection i agree with @Grahame Grieve equals() should be about object equality, comparing actual values should be handled by concept equals methods
Patrick Werner (Jul 10 2018 at 12:24):
i added generated equals and hashCode for Decimal and Pair to my pull request
Last updated: Apr 12 2022 at 19:14 UTC
