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 special-case 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 HTML fragment (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. Arlo Barnes (talk) 12:03, 6 May 2024 (UTC)[reply]
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)[reply]

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)[reply]

Suggesting to have the positive key to be named sign, and to be of type Sign instead of type Boolean. The type Sign is an enumeration with the values positive, negative, and neutral.

Comments

Support As proposer --DannyS712 (talk) 05:26, 8 March 2024 (UTC)[reply]
👍 · ^מקףHyphen_෴ · 14:40, 8 March 2024 (UTC)[reply]
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)[reply]
support in general, but I am wondering if, instead of the sign being a Boolean, we should have an enum type for signs, which is positive, negative, and neutral (for 0). For some edge cases, this seems to be more natural than using Boolean. What do people think? --Denny (talk) 17:00, 23 May 2024 (UTC)[reply]
I prefer this approach to the Boolean “sign”. In effect, “integer” is a supertype with subtypes positive integer, negative integer and zero. When we come to define Rational numbers, we shall want to exclude zero from the denominator and we may also want to exclude negatives. The simplest approach there would be to have integer for the numerator and positive integer (or non-zero integer) for the denominator. (I wouldn’t consider defining Rationals (or division) to be an edge case and I suppose we might want to define both signed and unsigned Rationals, although I haven’t thought of any reason to have both.) GrounderUK (talk) 09:52, 24 May 2024 (UTC)[reply]

I can imagine the sign type being useful for chemistry/physics too, even when it is unconnected to a specific value. --99of9 (talk) 01:17, 25 May 2024 (UTC)[reply]