Is there any documentation of the number format used by the quantity type? Bumped into this and had to implement the BCmath extension to handle the number. The reason why I did it (except it was fun) is to handle some weird unit conversions. By inspection I found there were numbers at Wikidata that clearly could not be implemented as doubles, and testing a little I found that this had to be implemented as some kind of big numbers. Lua does not have big numbers, and using the numbers from quantity as a plain number type is a coming disaster.
So, is there any documentation for the quantity format anywhere? I have not found anything. I posted a task about it, and please add info there if you know where some info can be found. I suspect the format just happen to be the same as BC, and nobody really checked if the format was compatible, or…?
The BCmath extension can be found at - https://www.mediawiki.org/wiki/Extension:BCmath - https://github.com/jeblad/BCmath
There is a Vagrant role if anyone likes to test it out.
Hi,
The offical documentation is https://www.wikidata.org/wiki/Help:Data_type#quantity but indeed there is no indication of the limit.
From what I tested, apparently you can enter any number which is less than
127 characters long (https://www.wikidata.org/wiki/Q4115189#P1104).
Cheers, ~nicolas
Le lun. 7 oct. 2019 à 08:58, John Erling Blad jeblad@gmail.com a écrit :
Is there any documentation of the number format used by the quantity type? Bumped into this and had to implement the BCmath extension to handle the number. The reason why I did it (except it was fun) is to handle some weird unit conversions. By inspection I found there were numbers at Wikidata that clearly could not be implemented as doubles, and testing a little I found that this had to be implemented as some kind of big numbers. Lua does not have big numbers, and using the numbers from quantity as a plain number type is a coming disaster.
So, is there any documentation for the quantity format anywhere? I have not found anything. I posted a task about it, and please add info there if you know where some info can be found. I suspect the format just happen to be the same as BC, and nobody really checked if the format was compatible, or…?
The BCmath extension can be found at
There is a Vagrant role if anyone likes to test it out. _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
I'm not sure, I have not tried to figure out why, but some places it seems like the limit hits around 95 chars.
On Mon, Oct 7, 2019 at 9:17 AM Nicolas VIGNERON vigneron.nicolas@gmail.com wrote:
Hi,
The offical documentation is https://www.wikidata.org/wiki/Help:Data_type#quantity but indeed there is no indication of the limit.
From what I tested, apparently you can enter any number which is less than 127 characters long (https://www.wikidata.org/wiki/Q4115189#P1104).
Cheers, ~nicolas
Le lun. 7 oct. 2019 à 08:58, John Erling Blad jeblad@gmail.com a écrit :
Is there any documentation of the number format used by the quantity type? Bumped into this and had to implement the BCmath extension to handle the number. The reason why I did it (except it was fun) is to handle some weird unit conversions. By inspection I found there were numbers at Wikidata that clearly could not be implemented as doubles, and testing a little I found that this had to be implemented as some kind of big numbers. Lua does not have big numbers, and using the numbers from quantity as a plain number type is a coming disaster.
So, is there any documentation for the quantity format anywhere? I have not found anything. I posted a task about it, and please add info there if you know where some info can be found. I suspect the format just happen to be the same as BC, and nobody really checked if the format was compatible, or…?
The BCmath extension can be found at
There is a Vagrant role if anyone likes to test it out. _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hey John,
I'm not aware of any documentation, though there probably is some somewhere. What I can point you to is the code dealing with numbers: https://github.com/wmde/Number
Cheers
-- Jeroen De Dauw | www.EntropyWins.wtf https://EntropyWins.wtf | www.Professional.Wiki https://Professional.Wiki Entrepreneur | Software Crafter | Speaker | Open Souce and Wikimedia contributor ~=[,,_,,]:3
Found a few references to bcmath, but some weirdness made me wonder if it really was bcmath after all. I wonder if the weirdness is the juggling with double when bcmath is missing.
On Mon, Oct 7, 2019 at 9:18 AM Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey John,
I'm not aware of any documentation, though there probably is some somewhere. What I can point you to is the code dealing with numbers: https://github.com/wmde/Number
Cheers
-- Jeroen De Dauw | www.EntropyWins.wtf https://EntropyWins.wtf | www.Professional.Wiki https://Professional.Wiki Entrepreneur | Software Crafter | Speaker | Open Souce and Wikimedia contributor ~=[,,_,,]:3
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 07.10.19 um 09:50 schrieb John Erling Blad:
Found a few references to bcmath, but some weirdness made me wonder if it really was bcmath after all. I wonder if the weirdness is the juggling with double when bcmath is missing.
I haven't looked at the code in five years or so, but when I wrote it, Number was indeed bcmath with fallback to float. The limit of 127 characters sounds right, though I'm not sure without looking at the code.
Quantity is based on Number, with quite a bit of added complexity for converting between units while considering the value's precision. e.g. "3 meters" should not turn into "118,11 inch", but "118 inch" or even "120 inch", if it's the default +/- 0.5 meter = 19,685 inch, which means the last digit is insignificant. Had lots of fun and confusion with that. I also implemented rounding on decimal strings for that. And initially screwed up some edge cases, which I only realized when helping my daughter with her homework ;)
In the DecimalMath class you escalate scaling on length of fractional part during multiply. That is what they do in school, but it leads to false precision. It can be argued that this is both wrong and right. Is there any particular reason (use case) why you do that? I don't escalate scaling in the Lua lib.
<rant>I see you have bumped into the problem whether precision is a last digit resolution or a count of significant digits. There are a couple of (several!) different definitions, and I'm not sure which one is right. 3 ± 0.5 meter is comparable to 120 ±10 inches, but interpretation of "3 meter" as having a default precision of ±0.5 meter is problematic. It is easier to see the problem if you compare with a prefix. What is the precision of 3000 meter vs 3 km? And when do you count significant digits? Is zero (0) a significant digit?</rant>
Otherwise I find this extremely amusing. When I first mentioned this we got into a fierce discussion, and the conclusion was that we should definitely not use big numbers. Now we do. :D
On Mon, Oct 7, 2019 at 10:44 AM Daniel Kinzler dkinzler@wikimedia.org wrote:
Am 07.10.19 um 09:50 schrieb John Erling Blad:
Found a few references to bcmath, but some weirdness made me wonder if
it really
was bcmath after all. I wonder if the weirdness is the juggling with
double when
bcmath is missing.
I haven't looked at the code in five years or so, but when I wrote it, Number was indeed bcmath with fallback to float. The limit of 127 characters sounds right, though I'm not sure without looking at the code.
Quantity is based on Number, with quite a bit of added complexity for converting between units while considering the value's precision. e.g. "3 meters" should not turn into "118,11 inch", but "118 inch" or even "120 inch", if it's the default +/- 0.5 meter = 19,685 inch, which means the last digit is insignificant. Had lots of fun and confusion with that. I also implemented rounding on decimal strings for that. And initially screwed up some edge cases, which I only realized when helping my daughter with her homework ;)
-- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation