|
* PCAN
* Phix
edit SideBar
|
Index | Library Routines | Predefined Types | integer
| Definition:
| integer identifier
-- or --
bool res = integer(object x)
| | Description:
| This serves to define the integer type.
You can also call it like an ordinary function to determine whether an object is an integer.
| | Comments:
| When invoked as a function, returns 1 (true) if x is an integer, otherwise returns 0 (false).
On 32-bit, integers are whole numbers in the range -1,073,741,824 to +1,073,741,823 (-#40000000 to #3FFFFFFF, technically 31-bit)
On 64-bit, integers are whole numbers in the range -4,611,686,018,427,387,904 to +4,611,686,018,427,387,903 (-#4000000000000000 to #3FFFFFFFFFFFFFFF, technically 63-bit)
| | Supplemental:
| In psym.e (part of the compiler), bool is a simple alias of integer, which does not validate that the value is true(1) or false(0) only - instead, 0 is false, and any other value is deemed true. However there is a more rigorous version, boolean, defined in builtins/ptypes.e - not an autoinclude but used/included by both pGUI? and mpfr, so using either makes it available.
Obviously there is no harm whatsoever in storing a boolean in a bool or integer, and only rarely is there any advantage to using the former.
The builtin constants true and false can and should be used for variables and parameters declared as type bool[ean], or, if you prefer, TRUE, True, FALSE, and False, are identical/aliases - mainly for compatibility with legacy code, but ultimately also one less thing (upper/lower case) that you have to remember, or fix.
| | Example 1:
|
| | Example 2:
|
if integer(y/x) then
puts(1, "y is an exact multiple of x")
end if
| | Implementation:
| There are generic versions of the integer function implemented as :%opInt in builtins\VM\pType.e and :%opInt0 in builtins\VM\pJcc.e that the compiler only invokes as a last resort, preferring instead to inline that functionality if the argument is known to be assigned or the result variable, if any, is known to be an integer, ie does not require decref/dealloc. The compiler may also completely omit the test and/or any related code, if type inference/propagation determines that the result will always be true or always false.
As already mentioned, builtins/ptypes.e is where the supplemental types are defined.
| | See Also:
| atom, sequence, string, object, floor?, puts?, Core Language
| | Technicalia
| A value such as '123456.0000000001' could appear as '123456' in trace, ex.err, and other diagnostic output, because the standard default is to display a maximum of six decimal places. A trailing ".0" is now added by print() and sprint() [see builtins\VM\psprintN.e] when a non-integer atom value is rounded in such a manner by sprintf(), to avoid that potential source of confusion. (To reiterate what I just said: sprintf() may chop off a trailing ".0"; sprint() [without the f] may stick it back on.)
Phix does not have an unsigned integer type - since the downsides (unexpected and ludicrous math results) far outweigh any possible benefits.
The most significant loss here would be that a C-style (unsigned)idx <; s.len must be replaced with idx>;=1 and idx<;=length(s), plus a couple of abs?() calls if you also want to allow negative subscripts.
The sq_int() routine can be used to apply an integer() test to all top-level elements of a sequence, eg sq_int({1,1.5,"string",{1,1.5,"string",{}}) ==>; {true,false,false,false}. That routine returns a single true/false if passed an atom or string, otherwise a "flat" sequence of true/false of the same length as the input argument. Note there are no known valid uses of the sq_int() routine, as yet.
|
< atom | Index | sequence >
|
