# Numeric Types​

It’s possible to explicitly `cast` between all numeric types. All numeric types can also be cast to and from `str` and `json`.

type
int16

A 16-bit signed integer.

An integer value in range from `-32768` to `+32767` (inclusive).

type
int32

A 32-bit signed integer.

An integer value in range from `-2147483648` to `+2147483647` (inclusive).

type
int64

A 64-bit signed integer.

An integer value in range from `-9223372036854775808` to `+9223372036854775807` (inclusive).

type
float32

A variable precision, inexact number.

Minimal guaranteed precision is at least 6 decimal digits. The approximate range of a `float32` is `-3.4e+38` to `+3.4e+38`.

type
float64

A variable precision, inexact number.

Minimal guaranteed precision is at least 15 decimal digits. The approximate range of a `float64` is `-1.7e+308` to `+1.7e+308`.

type
bigint

Arbitrary precision integer.

The EdgeDB philosophy is that using bigint type should be an explicit opt-in, but once used, the values should not be accidentally cast into a numeric type with less precision.

In accordance with this the mathematical functions are designed to keep the separation between bigint values and the rest of the numeric types.

All of the following types can be explicitly cast into bigint: `str`, `json`, `int16`, `int32`, `int64`, `float32`, `float64`, and `decimal`.

A bigint literal is an integer literal followed by ‘n’:

Copy
`db> `
`SELECT 42n IS bigint;`
`{true}`

To represent really big integers it is possible to use the exponent notation (e.g. `1e20n` instead of `100000000000000000000n`) as long as the exponent is positive and there is no dot anywhere.

Copy
`db> `
`SELECT 1e+100n IS bigint;`
`{true}`

When a float literal is followed by ‘n’ it produces a `decimal` instead:

Copy
`db> `
`SELECT 1.23n IS decimal;`
```{true}
```
Copy
`db> `
`SELECT 1.0e+100n IS decimal;`
`{true}`

Caution is advised when casting `bigint` values into `json`. The JSON specification does not have a limit on significant digits, so a `bigint` number can be losslessly represented in JSON. However, JSON decoders in many languages will read all such numbers as some kind of 32- or 64-bit number type, which may result in errors or precision loss. If such loss is unacceptable, then consider casting the value into `str` and decoding it on the client side into a more appropriate type.

type
decimal

Any number of arbitrary precision.

The EdgeDB philosophy is that using a decimal type should be an explicit opt-in, but once used, the values should not be accidentally cast into a numeric type with less precision.

In accordance with this the mathematical functions are designed to keep the separation between decimal values and the rest of the numeric types.

All of the following types can be explicitly cast into decimal: `str`, `json`, `int16`, `int32`, `int64`, `float32`, `float64`, and `bigint`.

A decimal literal is a float literal followed by ‘n’:

Copy
`db> `
`SELECT 1.23n IS decimal;`
```{true}
```
Copy
`db> `
`SELECT 1.0e+100n IS decimal;`
`{true}`

Note that an integer literal (without a dot or exponent) followed by ‘n’ produces a `bigint`. A literal without a dot and with a positive exponent makes a `bigint`, too:

Copy
`db> `
`SELECT 42n IS bigint;`
```{true}
```
Copy
`db> `
`SELECT 12e+34n IS bigint;`
`{true}`

Caution is advised when casting `decimal` values into `json`. The JSON specification does not have a limit on significant digits, so a `decimal` number can be losslessly represented in JSON. However, JSON decoders in many languages will read all such numbers as some kind of floating point values, which may result in precision loss. If such loss is unacceptable, then consider casting the value into `str` and decoding it on the client side into a more appropriate type.

type
sequence

Auto-incrementing sequence of `int64`.

This type can be used to create auto-incrementing properties.

Copy
```scalar type TicketNo extending sequence;

type Ticket {
property number -> TicketNo {
constraint exclusive;
}
}```

The sequence is bound to the scalar type, not to the property, so if multiple properties use the same `sequence` type they will share the same counter. For each distinct counter, a separate scalar type that is extending `sequence` should be used.