Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1656983, @daniel wrote:
> In https://phabricator.wikimedia.org/T105623#1656325, @Mike_Peel wrote: > > > As posted on wikidata-l, taking the current approach of +- 1 SF is a really > > bad idea. As an example, say you have a length of 100m. Which significant > > digit do you assume is correct? Is this +- 100m, 10m or 1m? What if it's > > referring to the length of a 100m run, where the accuracy could be much > > higher than the significant digit given, e.g. 100m +- 1cm? Or what if it's > > the size of a crater on a distant planet, where it might be 100m+-50m? Or > > if the actual value is 100m +- 3m, but we say that it's +- 1m (which I see > > is the default in this case), which might be believable to readers but very > > misleading in reality? > > > The problem with defaulting to +/-0 or "unknown" significance is that we > can't apply rounding - and if we can't apply rounding, we can't apply > conversion without introducing false precision. For example, 2m +/-0 would > convert to 6.56167979ft +/-0. This implies a precision to sub-micron levels, > which would very likely be wrong, and also not useful in infoboxes. If > however we assume 2m+/-0.5, that converts to 7ft (+/-1.6). That's much more > sensible, and avoids false precision. > > If we did not plan to support unit conversion, I would be ready to go along > with your argument. We would simply say we don't know th precision. With unit > conversion however we can't do this. And relying on the conventions for > specifying significant digits seems the best we can do. That makes sense in the back-end to make sure that converted values have reasonable levels of precision, but does it have to be in the front-end as well, or stored in the database? A line of code that checks whether the uncertainty has been set or not, and assumes a minimum uncertainty for conversion purposes, should handle this issue smoothly, without mis-estimates of the uncertainty of the given value being displayed to readers. > > If there's no uncertainty given, then please just say that rather than > > trying to make one up! > > > We are not making one up. The precision is given implicitly in the decimal > notation of the number, using the convention of significant digits. This is > quite unambiguous for cases like 3.20 (three significant digits) or 2.3e3 > (2300 with two significant digits). It's ambiguous for input like 200 or 1700 > - there's a good chance that the zeros are insignificant, but we don't really > know. We should improve our UI to help the user with correct input. I'm not convinced that the implicit assumption you're making here will work for most situations, so it really shouldn't be displayed to the reader. We should definitely be encouraging editors to add more accurate estimates of uncertainties at the same as the numbers are added though! One thing I'm particularly worried about here is that there doesn't seem to be a good way to tell assumed uncertainties and referenced uncertainties apart - which will be a huge headache to fix once this data format is in common usage! So please, let's get this right asap! TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mike_Peel Cc: Mike_Peel, 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
