Atoms and Integers

Atoms can have any integer or floating point value.

On a 32-bit architecture atoms can hold approximately ±1e+308, with ±1e-324 being the closest you can get to 0 without actually being 0, to a maximum of about 15 decimal digits of accuracy.
On a 64-bit architecture atoms can hold approximately ±1e+4932, with ±1e-4951 being the closest you can get to 0 without actually being 0, to a maximum of about 19 decimal digits of accuracy.

Integers in phix are limited to the subset that begin with 0b00 or 0b11: on a 32-bit architecture they can contain a single value in the range -1,073,741,824 to +1,073,741,823 (-#40000000 to #3FFFFFFF), with no fractional part, hence technically speaking phix integers are 31-bit, straddling the "middle half" of the actual hardware range (-2GB..+2GB-1).
On a 64-bit architecture the range is -4,611,686,018,427,387,904 to +4,611,686,018,427,387,903 (-#4000000000000000 to #3FFFFFFFFFFFFFFF), which technically speaking makes them 63-bit.
Should you need to hold full 32 (or 64) bit "integers", simply use an atom (trust me, it works).

Phix does not entertain the idea of unsigned integers: zero less one is -1, not suddenly +4GB (which is what happens in C-based languages).
Likewise storing (1GB-1)+1 in an integer is a clear no-nonsense type check error, in that file on that line, not quietly -1GB.

While you can store any integer value in a variable declared as an atom, the reverse is not true.

Here are some phix integers and atoms:
    0       -- (integer)
    1000    -- (integer)
    98.6    -- (atom)
    -1e60   -- (atom)
Phix stores integer-valued atoms as machine integers (4 or 8 bytes) to save space and improve execution speed. When fractional results occur or numbers get too big, conversion to floating-point happens automatically. As we shall soon see, should that conversion be the wrong thing to do, you are immediately notified in a clear and no-nonsense, human-readable manner.

See also: Number Bases