Wikifunctions:Type proposals/Natural number

Summary

Natural numbers are the integers starting at 0 and going to an arbitrary size (set of non-negative integers (Q28777634)). There is no official largest number the system accepts, but it tries to deal with any natural number without limit. See English Wikipedia on en:natural numbers.

Suggested ZID

Z10

Uses

Natural numbers are good for counting things, e.g. how many elements there are in a list, or how many code points in a string. This is important for example to validate whether a lexeme has sufficient forms.

The community has already started to use functions with natural numbers, expressed as strings, as can be seen in the catalogue.

Natural numbers are also an inherently interesting type that is expected to lead to a large number of new functions, e.g. for mathematical functions such as addition and multiplication.

Natural numbers are also the foundation for many other types, be it geocoordinates, dates, integers, floating point numbers, fractions, measurements, etc.

Structure

Natural numbers are objects with one additional key. The object’s type is “Z10”. The key is of type string representing the value of the number. The string represents the number in decimal notation (see validator).

Example values

Value 0

{ "type": "natural number", "value": "0" }	{ "Z1K1": "Z10", "Z10K1": "0" }

Value 7

{ "type": "natural number", "value": "7" }	{ "Z1K1": "Z10", "Z10K1": "7" }

Value 2024 (the number, not the year)

{ "type": "natural number", "value": "2024" }	{ "Z1K1": "Z10", "Z10K1": "2024" }

A large value

{ "type": "natural number", "value": "170141183460469231731687303715884105727" }	{ "Z1K1": "Z10", "Z10K1": "170141183460469231731687303715884105727" }

Persistent objects

It is expected that a small number of natural numbers will be stored as persistent objects, particularly zero and one, possibly all numbers until ten, and maybe a few large numbers that have some importance. This is up to the community.

Validator

The validator ensures that:

The value only consists of valid Arabic digits (0 to 9)
There are no leading zeros unless for the number 0, which is simply the number 0
The string is not empty

See is decimal natural number string of Arabic numerals (Z13489) for a function checking the string

Identity

Two natural numbers are the same if the value strings in their objects (their Z10K1 values) are the same. Otherwise they are different. For string identity, string equality (Z866) can be used.

Converting to code

Python

The native number type in Python 3 allows for arbitrarily large integers.

The converter from the type to native code would look as follows:

return int( n['Z10K1']['Z6K1'] )

The converter from native code to the type would look as follows:

return {
  "Z1K1": "Z10",
  "Z10K1": str(n)
}

JavaScript

Since ES11 (EcmaScript 2020), JavaScript has a native BigInt type. We use BigInt to represent numbers in native JavaScript code.

The converter from the type to native code would look as follows:

return BigInt( n.Z10K1.Z6K1 )

The converter from native code to the type would look as follows:

return {
  "Z1K1": "Z10",
  "Z10K1": n.toString()
}

Renderer

Renderers are the responsibility of the community.

It is expected that the renderers for natural numbers will use the digits most common for a given language (e.g. ١٥ for 15 in Arabic), and may add the appropriate separators at the appropriate places (e.g. commas to mark groups of three digits in English: format large natural number strings by adding commas (Z13473)), to make the displayed numbers as readable as possible.

They output either a String (Z6) (string) or [later] a Z89 (balanced HTML Fragment).

Parsers

Parsers are the responsibility of the community.

It is expected that the parsers for natural numbers will be able to understand the output of the renderers, but in addition to that be lenient about separators, and maybe even be liberal in the input digits.

Alternatives

There are many possible alternatives.

Instead of decimal digits in the internal representation, we could use strings with a binary, hexadecimal, base 56, base 256, or some other base. We argue for decimal because it makes debugging potentially easier.
Instead of a string, we could use a list of booleans, representing the binary number. We argue that this would be a very inefficient encoding.
We could have all integers, both positive and negative. We argue making that a complex type. There are plenty of use cases for positive numbers (especially for counting) to have this as the primitive type. It also makes the validator and the parsing simpler.
Instead of integers, we could go for floating point numbers. We argue that this could be a complex type.
We could restrict the number to have a maximal number of a certain value, usually of (a power of 256)-1. The advantage of this would be that many programming languages restrict their integers in such a way. We argue that since both JavaScript and Python do not, we can ignore that, and go for the most natural number representation, which is without a restriction. Also, expressing restricted numbers is easier once we have unrestricted ones.

Comments

Support I support the choices you've suggested, and look forward to this type being available. --99of9 (talk) 23:50, 29 February 2024 (UTC)[reply]
Support Looking forward to chipping away at a d:wikidata:property proposal/plural forms-equivalent. ― Arlo Barnes (talk) 07:51, 1 March 2024 (UTC)[reply]
Support Of course needed and useful, but will we only support numbers in ES2020+ runtimes? I'd like to clarify that case as we apparently have definitions of ECMAScript from JavaScript ES5 (Z601), so it's going to be counterintuitive for most users that these older ones don't support numbers at all. Maybe a fallback to treat Z10 as an ordinary Number type in ES2019 and lower would be nice to have for sake of basic compatibility? Msz2001 (talk) 12:18, 1 March 2024 (UTC)[reply]
In practice we don't actually support different versions of JS (or Python) yet. Once we do, and if we ever end up supporting ES5–ES2019 (which is doubtful), we'd have to write different deserialisers using Number or similar (and so different implementations), yes. Jdforrester (WMF) (talk) 14:28, 1 March 2024 (UTC)[reply]
Comment: Is the label supposed to be permanent, or can it be edited by the community in the future (similar to language-specific labels on Wikidata)? "Natural number" is regrettably ambiguous between zero- and one-based natural numbers (i.e. non-negative whole numbers vs. positive whole numbers). Also, Wikifunctions will likely be used to host abstract content in the formal mathematical domain for which one will want to rely on notions of "natural number" that don't explicitly involve a radix-ten representation. (Typically, such content will instead invoke "natural number" as something closer to an abstract interface, where no commitment is made to any specific representation. Of course, the theory of such abstract or "existential" types is not entirely trivial and Wikifunctions has yet to support them, but many existing programming language formalizations do account for them and it would make sense to support them here.) The most appropriate label for Z10 will then become something more like "non-negative whole number as decimal representation". --Hupaleju (talk) 19:23, 1 March 2024 (UTC)[reply]
I'd argue about the "representation" part. The Z10 type is number and not string representation of a number. Just like C's int is represented binarily but it doesn't prevent you from perceiving that as decimal. And for Wikifunctions it'll be alike. The internal representation of the value is going to be base-10, indeed, but number is a number and 0x10 === 16 === 0b10000.

The only point where the internal representation's important is the Converting to code section which is not about how the type is going to be interfaced to users but rather how it's going to be supplied to particular runtimes to fit into their type systems. Msz2001 (talk) 19:41, 1 March 2024 (UTC)[reply]

Is the label supposed to be permanent, or can it be edited by the community in the future (similar to language-specific labels on Wikidata)?

The labels of types, like with all other concepts, are all editable and translatable, yes. The community will presumably want to have a process to get broad consensus before changing labels of important types and other objects like this.

"Natural number" is regrettably ambiguous between zero- and one-based natural numbers (i.e. non-negative whole numbers vs. positive whole numbers).

We're using "Natural number" explicitly to include zero, unlike "Positive integer" / "Positive whole number" which does not.

Also, Wikifunctions will likely be used to host abstract content in the formal mathematical domain for which one will want to rely on notions of "natural number" that don't explicitly involve a radix-ten representation. (Typically, such content will instead invoke "natural number" as something closer to an abstract interface, where no commitment is made to any specific representation. Of course, the theory of such abstract or "existential" types is not entirely trivial and Wikifunctions has yet to support them, but many existing programming language formalizations do account for them and it would make sense to support them here.) The most appropriate label for Z10 will then become something more like "non-negative whole number as decimal representation".

As @Msz2001 says, a number is still a number regardless of its base or representation. FF₁₆ is a rendering of 256₁₀, which is conventionally written as just "256", but we could certainly provide renderers with different, explicit bases in different "languages" (en-x-mathematics, perhaps?) if the Wikifunctions community so wanted. Jdforrester (WMF) (talk) 14:36, 4 March 2024 (UTC)[reply]
We're using "Natural number" explicitly to include zero. Alas, this does not always explicitly include zero. As the en-wiki page discusses and many dictionaries define otherwise. If we need to be super clear, we should call them non-negative integers. --99of9 (talk) 03:39, 5 March 2024 (UTC)[reply]
@99of9: I'd suggest that it's far more important to be understood by normal people than to be overly specific. We want the system to be as welcoming as possible. Jdforrester (WMF) (talk) 14:09, 5 March 2024 (UTC)[reply]
Support Looking forward to finally having numbers --DannyS712 (talk) 21:44, 1 March 2024 (UTC)[reply]
Support Not done thinking yet. I see nothing to object to in this proposal and I agree it is a priority. It just occurred to me, working through Wikifunctions:Type proposals/Typed string, that we might jump straight to Typed integers, but with the single Reference to Q28777634 (initially). That is, natural numbers (including zero) as a subtype of integers. It would mean a second additional key for the reference, so it’s probably better to wait until the next number type comes up, rather than delaying progress on this type, but I thought I should mention it at the earliest opportunity.--GrounderUK (talk) 21:56, 1 March 2024 (UTC)[reply]
Support we may need more type for numbers but it's good to start by the "simple" natural numbers (especially for natural language processing). Cheers, VIGNERON (talk) 16:41, 4 March 2024 (UTC)[reply]
Support A really useful type. --Ameisenigel (talk) 17:42, 4 March 2024 (UTC)[reply]