The default data type for numeric arrays in MATLAB is
double is a floating point representation of numbers, and this format takes 8 bytes (or 64 bits) per value. In some cases, where e.g. dealing only with integers or when numerical instability is not an imminent issue, such high bit depth may not be required. For this reason, it is advised to consider the benefits of
single precision (or other appropriate types):
doublefails due to an out-of-memory error; more compact when storing as files.
Converting a variable from any supported data type to
single is done using:
sing_var = single(var);
As of July 2016, there exists no documented way to change the default MATLAB data type from
In MATLAB, new variables usually mimic the data types of variables used when creating them. To illustrate this, consider the following example:
A = magic(3); B = diag(A); C = 20*B; >> whos C Name Size Bytes Class Attributes C 3x1 24 double
A = single(magic(3)); % A is converted to "single" B = diag(A); C = B*double(20); % The stricter type, which in this case is "single", prevails D = single(size(C)); % It is generally advised to cast to the desired type explicitly. >> whos C Name Size Bytes Class Attributes C 3x1 12 single
Thus, it may seem sufficient to cast/convert several initial variables to have the change permeate throughout the code - however this is discouraged (see Caveats & Pitfalls below).
Repeated conversions are discouraged due to the introduction of numeric noise (when casting from
double) or loss of information (when casting from
single, or between certain integer types), e.g. :
double(single(1.2)) == double(1.2) ans = 0
Relying solely on implicit data-typing (i.e. what MATLAB guesses the type of the output of a computation should be) is discouraged due to several undesired effects that might arise:
Loss of information: when a
double result is expected, but a careless combination of
double operands yields
Unexpectedly high memory consumption: when a
single result is expected but a careless computation results in a
Unnecessary overhead when working with GPUs: when mixing
gpuArray types (i.e. variables stored in VRAM) with non-
gpuArray variables (i.e. those usually stored in RAM) the data will have to be transferred one way or the other before the computation can be performed. This operation takes time, and can be very noticeable in repetative computations.
Errors when mixing floating-point types with integer types: functions like
*) are not defined for mixed inputs of integer and floating point types - and will error. Functions like
.*) are not defined at all for integer-type inputs - and will again error.
>> ones(3,3,'int32')*ones(3,3,'int32') Error using * MTIMES is not fully supported for integer classes. At least one input must be scalar. >> ones(3,3,'int32').*ones(3,3,'double') Error using .* Integers can only be combined with integers of the same class, or scalar doubles.
For better code readability and reduced risk of unwanted types, a defensive approach is advised, where variables are explicitly cast to the desired type.