[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Wostr added a comment. In T95425#2410249, @Nikki wrote: This just came up on-wiki again at https://www.wikidata.org/wiki/Wikidata:Project_chat#Rounding_when_uncertainty_over_10_is_given where someone added a statement with 547±17 (which is 530-564) and instead it displays 550±20 (which is 530-570)

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Nikki added a comment. This just came up on-wiki again at https://www.wikidata.org/wiki/Wikidata:Project_chat#Rounding_when_uncertainty_over_10_is_given where someone added a statement with 547±17 (which is 530-564) and instead it displays 550±20 (which is 530-570).TASK DETAILhttps://phabricator.wi

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

thiemowmde added a comment. F3239746: Tanker_in_English_Channel_2.png TASK DETAIL https://phabricator.wikimedia.org/T95425 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde Cc: Thryduulf, Addsho

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

thiemowmde added a comment. This argument is invalid for multiple reasons: 1. It does not matter if you call it a "range" or a "possibility". For all arguments shared that's the same. - In 1.5±1.0 it's possible that the tanker is sitting somewhere between 0.5 and 2.5. But it's **impossible**

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. @thiemowmde: That's what happens when you use precision to express a range. I agree that it's confusing. +/-1 says that anything after the decimal point is insignificant. If you construct a range from that, the result is counter-intuitive. TASK DETAIL https://phabric

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

thiemowmde added a comment. F3230294: Tanker_in_English_Channel.png TASK DETAIL https://phabricator.wikimedia.org/T95425 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde Cc: Thryduulf, Addshore

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

thiemowmde added a comment. @daniel wrote: > The reason 350±150 is shown as 400±200 is that rounding is applied based on > the uncertainty I'm afraid this does not explain anything. The uncertainty is +/-150. Not +/-200. Rounding to +/-150 would mean ... rounding to 2 * 150 = 300? But why?

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. The reason 350±150 is shown as 400±200 is that rounding is applied based on the uncertainty, and the same rounding is applied to the uncertainty itself (basically, you cannot be more precise about the uncertainty than about the value itself). The reason we apply roundin

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Thryduulf added a comment. In https://phabricator.wikimedia.org/T95425#1624288, @daniel wrote: > As far as I know, this is resolved for the editing use case. Rounding still > applies for HTML output. I think this should be either reworded or closed. This is still causing data loss, just for th

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Thryduulf added a subscriber: Thryduulf. Thryduulf added a comment. This is still causing incorrect data to be displayed. I've entered a value of 350±150 because the source gives a range of 200-500. However this is displayed as 400±200 which gives a range of 200-600 which is incorrect and mislea

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. As far as I know, this is resolved for the editing use case. Rounding still applies for HTML output. I think this should be either reworded or closed. TASK DETAIL https://phabricator.wikimedia.org/T95425 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/p

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1606173, @thiemowmde wrote in part: > Proof of concept: https://github.com/DataValues/Number/pull/43 I don't fully understand this example, but I did notice all the examples seem to provide displayed uncertainties that are an

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

thiemowmde added a comment. > for the same reason 1964 with the precision set to century will be rendered > as 20th century, not 1964+/-50. Irrelevant, misleading comparison. Quantities do not have a precision, they have a lower and upper bound. > principle of consistency Wut? How is the ex

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. @Jc3s5h I don't see how any of the differences you mention are relevant in the context of precision/uncertainty. TASK DETAIL https://phabricator.wikimedia.org/T95425 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc:

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1602763, @daniel wrote in part: > @thiemowmde for the same reason 1964 with the precision set to century will > be rendered as 20th century, not 1964+/-50. If you want a solution to be analogous to the way time is handled, the

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. @thiemowmde for the same reason 1964 with the precision set to century will be rendered as 20th century, not 1964+/-50. Basically, we have two conflicting principles here: the principle of least surprise agrees with you thiemo (I entered one thing, but see another, wtf?)

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

Jc3s5h added a comment. In https://phabricator.wikimedia.org/T95425#1602377, @daniel wrote in part: > > We could just drop rounding, but that would lead to //false precision// when > applying unit conversion. So we could apply rounding only if we do conversion > - but that would be even mor

[Wikidata-bugs] [Maniphest] [Commented On] T95425: [Bug] Quantity formatter rounding causes significant data loss

daniel added a comment. Round trip stability for rendered output is nice, but was never a design goal. In fact, it doesn't work for most things. If this is not about editing, saying it causes "data loss" is misleading. "Quantity rendering does not preserve precision" would be descriptive. But