[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-11 Thread thiemowmde
thiemowmde added a comment. I'm sorry, but I do not understand that example at all. Where does a 0.4 come from in your example? 1.4+-1 is internally stored as { amount: 1.4, before: 0.4, after: 2.4 }. This is, when displayed via the formatter, displayed and later parsed as 1.4+-1. You can say

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-10 Thread thiemowmde
thiemowmde added a comment. In https://phabricator.wikimedia.org/T95425#1353657, @daniel wrote: 24+/-10 can be written as 20 (because we don't care about the 4) This is simply wrong. These are two completely distinct values. But I'm already repeating myself. TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-10 Thread daniel
daniel added a comment. @thiemowmde: i think this becomes a lot clearer when you think about your original value being in meter, and you are trying to display it in feet. The we must apply rounding based on the uncertainty, otherwise we would be introducing false precision. And if we do this

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-10 Thread thiemowmde
thiemowmde added a comment. 15+/-1 feet becomes 5+/-1 meter which becomes 16+/-1 feet. The before and after values are not there to mark irrelevant digits. There is no such thing as an irrelevant digit in Quantity values. We do have this in Time, but not in Quantity. TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-10 Thread thiemowmde
thiemowmde added a comment. The rounding is wrong no matter what. 24+/-10 becomes 20+/-10 with the current formatting. This is not even remotely the same value. TASK DETAIL https://phabricator.wikimedia.org/T95425 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-06-10 Thread daniel
daniel added a comment. What rounding would be correct then, and would also work with unit conversion? I agree that the current output is a bit odd when the uncertainty interval is included. 24+/-10 can be written as 20 (because we don't care about the 4), but I agree that writing it as 20+/-10

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-04-15 Thread thiemowmde
thiemowmde added a comment. Separate? How? I don't understand. A formatter that silently manipulates 1.5+-1 to 2+-1 does change the actual value by 66%. You can't argue that such a major data loss is insignificant. TASK DETAIL https://phabricator.wikimedia.org/T95425 REPLY HANDLER ACTIONS

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-04-14 Thread thiemowmde
thiemowmde added a comment. Sorry, I have to disagree. There may be a sweep spot where such a formatting for display is ok, but rounding 1.9+-1 to 2+-1 is clearly **wrong**, at least in my opinion. These two strings describe two completely different values. TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T95425: Quantity rounding causes data loss when editing

2015-04-14 Thread daniel
daniel added a comment. They are two different intervals, sure. If you however consider the +/- as an uncertainty, they are nearly the same in the sense that the difference is insignificant. An uncertainty interval of +/-1 is the explicit statement that any difference 1 is insignificant. If