Wikifunctions:Type proposals/Integer
Summary
Now that we have natural numbers (0 or positive), we should also support negative numbers. See en:integers.
Uses
For math (and others, you can add your own use cases below).
 Subtraction of natural numbers without a floor.
Structure
Integers are stored in two parts  magnitude (as a natural number) and whether the number is positive (as a boolean). A zero is always marked as positive for consistency.
Integers are objects with 2 additional keys. The first key is for a Natural number (Z13518)/Natural number with the magnitude, and the second key is for a Boolean (Z40)/Boolean saying if the number is positive. The magnitude is in decimal notation (see validator).
Example values
Value 0
{
"type": "integer",
"magnitude": {
"type": "natural number",
"value": "0"
},
"positive": {
"type": "boolean",
"identity": "true"
}
}

{
"Z1K1": "Zxyz",
"ZxyzK1": {
"Z1K1": "Z13518",
"Z13518K1": "0"
},
"ZxyzK2": {
"Z1K1": "Z40",
"Z40K1": "Z41"
}
}

Value 7
{
"type": "integer",
"magnitude": {
"type": "natural number",
"value": "7"
},
"positive": {
"type": "boolean",
"identity": "true"
}
}

{
"Z1K1": "Zxyz",
"ZxyzK1": {
"Z1K1": "Z13518",
"Z13518K1": "7"
},
"ZxyzK2": {
"Z1K1": "Z40",
"Z40K1": "Z41"
}
}

Value 1234
{
"type": "integer",
"magnitude": {
"type": "natural number",
"value": "1234"
},
"positive": {
"type": "boolean",
"identity": "false"
}
}

{
"Z1K1": "Zxyz",
"ZxyzK1": {
"Z1K1": "Z13518",
"Z13518K1": "1234"
},
"ZxyzK2": {
"Z1K1": "Z40",
"Z40K1": "Z42"
}
}

Persistent objects
A few negative and positive numbers might be worth storing, but this is up to the community.
Validator
The validator ensures that:
 The "magnitude" is a valid natural number
 The "positive" is a valid boolean
 If the "magnitude" is 0, the "positive" must be true
Identity
Two natural numbers are the same if they have the same magnitude and positive values  since 0 is always marked as positive we don't need to specialcase it.
Converting to code
Python
The native number type in Python 3 allows for arbitrarily large integers, and so the converter from an integer type to native code would look like:
magnitude = int( n['ZxyzK1']['Z13518K1']['Z6K1'] )
return magnitude if n['ZxyzK2']['Z40K1'] == 'Z41' else magnitude
And the converter from native code to the integer type would look like:
return {
"Z1K1": "Zxyz",
"ZxyzK1": {
"Z1K1": "Z13518",
"Z13518K1": str(abs(n))
},
"ZxyzK2": {
"Z1K1": "Z40",
"Z40K1": "Z41" if n >= 0 else "Z42"
}
}
JavaScript
Since ES11 (EcmaScript 2020), JavaScript has a native BigInt type, which supports both positive and negative values. We use BigInt to represent numbers in native JavaScript code; the converted from an integer type to native code would like:
const magnitude = BigInt( n.ZxyzK1.Z13518K1.Z6K1 );
return ( n.ZxyzK2.Z40K1 === 'Z41' ? magnitude : magnitude );
And the converter from native code to the integer type would look like:
return {
"Z1K1": "Zxyz",
"ZxyzK1": {
"Z1K1": "Z13518",
"Z13518K1": ( n < 0n ? n : n ).toString()
},
"ZxyzK2": {
"Z1K1": "Z40",
"Z40K1": ( n < 0n ? "Z42" : "Z41" )
}
}
Renderer
It is expected that the renderers for integers 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
It is expected that the parsers for integers 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
 Are there advantages/disadvantages of putting the sign in the single string as a "" (or even a "+")?
 I'd think if a + is always kept with positive numbers, then Wikifunctions:Type proposals/Signed integer might be a better name.
 I (DannyS712) didn't have this stored as a string since then there could be confusion about if positive numbers should have the + or not, and if 0, +0, 0 were the same, etc.  and I figured it might be helpful to build the type based on existing types (natural numbers and booleans) DannyS712 (talk) 16:53, 8 March 2024 (UTC)
 Well, they are the same, and canonically unsigned. (So, yeah, maybe “unsigned integer” is another good alias for Natural number.) I think handling and explaining the Boolean is liable to be more trouble than it’s worth. Logically, the Boolean (as proposed) applies to the predicate “not negative”, so I’m already confused (no, not really, but you see my point? Truly, this is not a negative comment.) GrounderUK (talk) 20:01, 10 March 2024 (UTC)
Comments
 Support As proposer DannyS712 (talk) 05:26, 8 March 2024 (UTC)
 👍 · ^{מקף }Hyphen_{ ෴} · 14:40, 8 March 2024 (UTC)
 Integers should be a priority. I’m not convinced that the sign should be Boolean, however. Given that Natural numbers are unsigned integers implemented in code as integers, I suspect that aligning the two types as closely as is feasible will be achieved more easily, more quickly and (for the general user) more naturally. We can have both types, I suppose. But if we already had either, I’m not sure the other would be a priority. So how about we pursue both at the same time?GrounderUK (talk) 08:26, 13 March 2024 (UTC)