[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-18 Thread Srittau
Srittau added a comment. For reference, another user caught by this bug on the German village pump: https://www.wikidata.org/wiki/Wikidata:Forum#Eigenschaft_f.C3.BCr_.22Anzahl_B.C3.A4nde.22.3FTASK DETAILhttps://phabricator.wikimedia.org/T105623EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-14 Thread daniel
daniel added a comment.@kaldari We have a good plan: don't guess until we need it, don't output a precision if none was entered explicitly, and if we guess, guess half the interval we currently use. The implementation keeps being pushed back, partly due to the need of a UI refactor, partly

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-14 Thread daniel
daniel added a comment.@Yellowcard actually, exact integers are relatively rare. Exact integers with a unit are even extremely rare. But I agree that the +/-1 guess sis wrong. It should be half that, to be consistent with rounding. And the guess should be performed only when and if needed, not

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-14 Thread daniel
daniel added a comment.@Izno the assumption was that any decimal number does have an implied precision, by convention. But as it turns out, there isn't one convention, but at least two, and the resulting behavior is confusing.TASK DETAILhttps://phabricator.wikimedia.org/T105623EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-14 Thread Izno
Izno added a comment.I'm going to make sure my comment at T68580#1260737 is heard in this context as well. What's mostly nuts is having any default precision which is not "we don't know what the precision is".TASK DETAILhttps://phabricator.wikimedia.org/T105623EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-13 Thread Yellowcard
Yellowcard added a comment.I strongly support @Srittau's comment. This is still an extremely annoying bug and should be fixed with high priority. There are plenty of exact integers and the guessed precision of +/-1 makes the data wrong. I cannot understand why this is not fixed.TASK

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-13 Thread kaldari
kaldari added a comment.Did we ever figure out a way forward on this?TASK DETAILhttps://phabricator.wikimedia.org/T105623EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: kaldariCc: Srittau, Edgars2007, Yellowcard, Jonas, JanZerebecki, harej-NIOSH, Thryduulf,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-06-13 Thread Srittau
Srittau added a comment.As someone who mainly enters exact integers, this is one of the most infuriating bugs. I always have to go back and correct the precision after the fact. There are also many, many numbers in Wikidata statements with the very obviously wrong precision +-1. At this point,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2016-04-26 Thread Thryduulf
Thryduulf added a comment. https://www.wikidata.org/w/index.php?title=Q5089194=revision=325544717=314121367 This is another example of how assuming a precision is incorrect - the value given in the source is 135,000,000 gallons without specifying the level of precision. It is very

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-30 Thread Yellowcard
Yellowcard added a comment. @kaldari: I understand the argumentation, but it doesn't convince me. Your statements in the linked bug seem very reasoned to me. We agree that information about uncertainty is very important, but for each data we have to //know// the amount of uncertainty

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-30 Thread kaldari
kaldari added a comment. @Yellowcard: I agree with you in most cases. Most numbers in Wikidata should probably be considered exact values (per https://phabricator.wikimedia.org/T68580) and should not have any assumed uncertainty. Numbers for measurements, however, have to have some assumed

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-30 Thread JanZerebecki
JanZerebecki added a comment. Please see https://phabricator.wikimedia.org/T115269. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki Cc: Yellowcard, Jonas, JanZerebecki, harej-NIOSH,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-30 Thread harej-NIOSH
harej-NIOSH added a comment. @kaldari captures it well. Measurements have inherent uncertainty, since measurement instruments such as scales can only measure out to so many decimal places. So if a scale tells you something has 3.24 grams of mass, it could be 3.239 or 3.241, but the scale

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-29 Thread kaldari
kaldari added a comment. @Yellowcard: We have to choose an uncertainty in order to do unit conversion. There's no way around that fact. TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: kaldari

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-29 Thread Yellowcard
Yellowcard added a comment. @kaldari: There's nothing against uncertainty, but the default uncertainty for values that don't have any. I'm especially talking about counting values without any unit. For what I understand, unit conversation should also be possible without known uncertainty?

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-29 Thread Yellowcard
Yellowcard added a subscriber: Yellowcard. Yellowcard added a comment. Having a default in general is not reasonable. If there is a sourced uncertainty, the input has to include exactly this uncertainty, not a default one. It here is no sourced uncertainty, guessing one is simply wrong. It is

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-26 Thread kaldari
kaldari added a comment. Are we still investigating this or have we reached the conclusion that +/- 0.5 is the most sensible default for rounding and unit conversion? TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-12 Thread daniel
daniel added a comment. Here is another take on the 1 vs 0.5 issue, from //Uncertainties and Significant Figures// http://facultyfiles.deanza.edu/gems/lunaeduardo/UncertaintyandSignificantFig.pdf (a random find, not an authoritative source): > > > 1. Uncertainty in a Scale Measuring

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-11 Thread daniel
daniel added a comment. @Jc3s5h Well, if we have additional information about the methods and tools used for the measurement, we should use them, sure. The source should state them, and we should record them. That's the simple case. But the question we are trying to answer here is what to use

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-10 Thread Jc3s5h
Jc3s5h added a comment. thiemowmde's quote from the buffalostate.edu site uses ellipsis to omit a critical passage: "Then, for your work in PHYS 152L, the uncertainty in the measurement is taken to be this value." This document is used in conjunction with an (apparently undergraduate)

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-09 Thread daniel
daniel added a comment. Thank you for digging this up, Thiemo! I think the last document you quote is most relevant to our use case: we need the uncertainty interval to apply correct //rounding// for display, especially after unit conversion. As Kaldari mentioned earlier, using +/- 1 is

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-10-08 Thread Mike_Peel
Mike_Peel added a comment. Any news on progressing this issue? TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mike_Peel Cc: harej-NIOSH, Thryduulf, Mike_Peel, Jc3s5h, thiemowmde, kaldari,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-24 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1660386, @daniel wrote in part: > . . . > - the //magnitude// of the uncertainty interval should be order of magnitude > of the least significant digit (not twice that -- so +/-0.5, not +/-1). That's OK for a guessed

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-22 Thread daniel
daniel added a comment. @Thryduulf Thanks for the input. I See where you are coming from. The trouble is: in order to apply conversion and meaningful comparison, we //have// to assume some level of uncertainty. Assuming +/-0 leads to strange results for display, and mismatches in queries. It

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread daniel
daniel added a comment. @Jc3s5h what, then, would be an example for a reliable/acceptable source giving us a number with no hint at the uncertainty? When should we consider an uncertainty unsourced? If Nature gives the size of a crated on Mars in Kilometers, what uncertainty should we assume,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Mike_Peel
Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1657039, @daniel wrote: > In https://phabricator.wikimedia.org/T105623#1656985, @Mike_Peel wrote: > > > > If we did not plan to support unit conversion, I would be ready to go > > > along with your argument. We would simply

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Mike_Peel
Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1657997, @daniel wrote: > @Jc3s5h what, then, would be an example for a reliable/acceptable source > giving us a number with no hint at the uncertainty? When should we consider > an uncertainty unsourced? If Nature gives

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread daniel
daniel added a comment. @Mike_Peel "show", of course! It's amazing how blind I am when I already "know" what I am reading... TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc:

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Mike_Peel
Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1660601, @daniel wrote: > @Mike_Peel Thanks for the links! Especially M3003 looks like a very useful > reference. > > In https://phabricator.wikimedia.org/T105623#1660493, @Mike_Peel wrote: > > > In

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1657039, @daniel wrote, in part: > > We can of course discuss if, when and how the explicit +/-X is shown to the > user. I'm completely open to that. One sensible suggestion was to hide it if > the actual uncertainty is

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread daniel
daniel added a comment. @Mike_Peel Thanks for the links! Especially M3003 looks like a very useful reference. In https://phabricator.wikimedia.org/T105623#1660493, @Mike_Peel wrote: > In https://phabricator.wikimedia.org/T105623#1660386, @daniel wrote: > > > - it's nearly always wrong to

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1660251, @Mike_Peel wrote, in part: > > ...The standard approach in astronomy (which is the part of the scientific > literature that I'm most familiar with, as a scientist working in that field) > is to quote a number

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread daniel
daniel added a comment. It seems like are are approaching an agreement on a few points: - it's wrong to assume absolute precision (+/-0) per default - it's important to apply rounding based on uncertainty (resp significant digits) when //converting//, to avoid the introduction of false

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-21 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1657997, @daniel wrote in part: > @Jc3s5h what, then, would be an example for a reliable/acceptable source > giving us a number with no hint at the uncertainty? When should we consider > an uncertainty unsourced? If Nature

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-20 Thread daniel
daniel added a comment. In https://phabricator.wikimedia.org/T105623#1656985, @Mike_Peel wrote: > > 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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-20 Thread daniel
daniel added a comment. 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 +-

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-20 Thread Mike_Peel
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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-19 Thread Mike_Peel
Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1645307, @Jc3s5h wrote: > I must take issue with thiemowmde's argument: > > - "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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-19 Thread Mike_Peel
Mike_Peel added a subscriber: Mike_Peel. Mike_Peel added a comment. In https://phabricator.wikimedia.org/T105623#1644152, @thiemowmde wrote: > 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 >

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-16 Thread thiemowmde
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

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-16 Thread Jc3s5h
Jc3s5h added a comment. I must take issue with thiemowmde's argument: - "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." Suppose we do as thiemowmde suggests; when the user

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-16 Thread kaldari
kaldari added a comment. I agree with Jc3s5h. Yes, using +/-1 is basically wrong, but we shouldn't throw out the idea of significant digits entirely. We should just implement them correctly. Otherwise, our converted values will have false certainty in most cases. TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-14 Thread daniel
daniel added a comment. @Jc3s5h Hm... it doesn't seem to be that clear cut. A quick search brought up a somewhat inconclusive picture: Frontiers of Science: Scientific Habits of Mind (Columbia University) seems to

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread daniel
daniel added a comment. In https://phabricator.wikimedia.org/T105623#1630587, @Jc3s5h wrote: > On further reflection, I would do what I described above, unless there was > only one significant digit. In that case I would set the precision to 1 times > ten to the n. Examples: 7000 ± 1000; 1920

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread daniel
daniel added a comment. In https://phabricator.wikimedia.org/T105623#1601779, @thiemowmde wrote: > - This ticket is about the precision auto-detection in the parser. Typically, > when a user just enters "5", the parser auto-detects the ~~before/after~~ > lower/upper fields as "+4/+6" and the

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread daniel
daniel added a comment. *bump* because of units TASK DETAIL https://phabricator.wikimedia.org/T105623 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Jc3s5h, thiemowmde, kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre,

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread Jc3s5h
Jc3s5h added a comment. > We cannot assume that trailing zeros are insignificant. The default > uncertainty for 7000 should be the same as the default uncertainty of > (currently +/-1, possibly to be +/-0.5 in the future). "seven thousand" can > be written as 7e3 to indicate that only

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-11 Thread Jc3s5h
Jc3s5h added a comment. In https://phabricator.wikimedia.org/T105623#1623500, @Jc3s5h wrote: > If the least significant digit is m time ten to the nth power, I would set > the default uncertainty to 5 times ten to the nth power, which is the > greatest uncertainty that might apply in that

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-09 Thread Jc3s5h
Jc3s5h added a comment. If the least significant digit is m time ten to the nth power, I would set the default uncertainty to 5 times ten to the nth power, which is the greatest uncertainty that might apply in that situation. If the uncertainty were any worse, the person who wrote the value

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-09-09 Thread kaldari
kaldari added a comment. I agree with Daniel that the magnitude of the uncertainly interval should match the magnitude of the least significant digit. In other words, the default precision (if none is specified) should be +/-0.5, not +/-1. The whole point of significant digits is that you can

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

2015-08-31 Thread Jc3s5h
Jc3s5h added a comment. The discussion of this in //Land Surveyor Reference Manual// 2nd ed., Andrew L. Harbin, Belmont CA: Professional Publications, pp. 1-8 through 1-10 agrees with my own experience. My experience includes creating voltage and current test specifications for mainframe