thiemowmde added a comment.
The fact that the parser "guesses" a precision based on basically zero
information always was and still is wrong. It must default to ±0. Everything
else is misleading and a source of significant confusion and actual errors.
I'm not sure if this is the correct ticket for that since we already have quite
a lot related to this artificial and still unresolved issue.
What the user enters must be respected. When he enters "6" he does not mean
"maybe 5, maybe 7, I do not know". This is misleading. He entered "6". Nothing
else. That's what we know and what we must store. Same is not only true for
integers but for all precisions, may it be 6 million or 1.06. When the user
enters "1.06" he did not meant to enter "I do have a number here but I'm not
sure if it's 1.05 or 1.07, it could be something in between". When he enters
"1.06" he does this because this is what's stated in the source. Exactly this
and not something else. Assuming //anything// is just plain wrong.
- "1.06 feet" is entered via the UI or API. It **must** be stored as { amount:
1.06, unit: feet <https://www.wikidata.org/wiki/Q3710>, upperBound: 1.06,
lowerBound: 1.06 }. This is what we know at this point. Nothing else. There is
no "false precision" in this raw value.[*]
- 1 ft = 0.3048 m, so when converting 1.06 feet to meter it would become
0.323088 m.
- At this point, this //is// false precision. The original value was not that
precise. The original 1.06 feet had 2 decimal places, the last being 0.01 feet
= 0.003048 m.
- This, along with the discussion above, means the precision of the converted
value is at best ±0.05 feet = ±0.001524 meter.
- This is what we store: { amount: 0.323088, unit: meter
<https://www.wikidata.org/wiki/Q11573>, upperBound: 0.324612, lowerBound:
0.321564 }.
- A naive formatter would render this as 0.323088±0.001524 m.
- A formatter with a rounding option could render this as 0.3231±0.0015 m or
0.323±0.002 m, but should never render this as 0.32±0.00 m.
- When converted back to feet, 0.323088±0.001524 m becomes 1.06±0.005 and is
stored as such, resulting in { amount: 1.06, unit: feet
<https://www.wikidata.org/wiki/Q3710>, upperBound: 1.065, lowerBound: 1.055 }.
Yes, this is different from the original, raw value. It must be. Conversion was
applied twice. We can not be sure any more what the original intent was.
- When converting one of the rounded values back:
- 0.3231±0.0015 m becomes 1.06003937±0.00492126 feet. A formatter with
rounding can render this as 1.06±0.005 feet.
- 0.323±0.002 m becomes 1.059711286±0.00656168 feet. A formatter with
rounding can render this as 1.06±0.007 feet.
TL;DR: Store raw values with ±0. Recalculate the ± value and let it grow every
time a value is converted.
[*]We could also store { upperBound: unknown, lowerBound: unknown }. This would
not change the arguments below.
TASK DETAIL
https://phabricator.wikimedia.org/T105623
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: thiemowmde
Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher,
Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r,
Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper,
aude
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
