cast operation is necessary for explicitly rounding values
without performing other numerical operations. Precision annotations specified
! never cause any numerical operations to occur; they only
change the rounding context.
For example, the expression
will not round the value of the variable
x. This expression is the
same as simply specifying
regardless of the rounding context. To round
x, it is necessary
cast it in a context with the desired precision. The expression
binary32 precision (here the outer
binary64 precision is redundant, as it will be overwritten by the
inner one), while the expression
x twice, first to
binary32 precision, and then from
Because numerical operations already round their outputs, it should not be necessary
cast in most cases, unless double rounding is specifically intended.
For example, in an expression such as
the value stored in x will already be rounded to
as the addition is done in a context with that precision. Inserting an explicit
cast around either the addition or the use of
cause double rounding, and while in the case of
this is a no-op, for other rounding contexts it could lead to undesirable behavior.
Inheriting properties in rounding contexts
All properties not explicitly specified in a
! precision annotation
are inherited from the parent context. For the top level expression in an
FPCore benchmark, the parent context includes all the overall properties of the benchmark.
For example, in the following benchmark
sin operation will take place in a context with
spec 0, and
binary64 precision. Even properties that are seemingly unrelated to
rounding, such as the name of the benchmark, are inherited. The FPCore standard does
not prohibit tools from implementing rounding functions that depend on these properties,
or other tool-specific properties, although having a rounding function that depends on
name is not advised.
Properties in the rounding context might come from multiple different annotations. For example, in the expression
the addition will take place as expected in a context with
toZero rounding direction, and the
gnu-libm-2.34 math library. This
can be useful if some, but not all, of the properties are shared by multiple subexpressions.
For example, in the expression
all of the operations will take place in a context with
binary64 precision, but the additions
will use different rounding directions.
N-dimensional arrays, or tensors,
are useful for working with any kind of structured data,
from simple 3D points to complex, multidimensional arrays.
Tensors can be constructed in FPCore expressions either as literal arrays
or by dynamically tabulating over a set of indices with
Here are two ways of constructing a 2x2 identity matrix:
Tensors can be nested,
and different ways of constructing them can be nested with each other.
For example, and
n by 3 matrix of zeros (perhaps of 3D points)
could be constructed like this:
Tensors can also be received as inputs to an FPCore.
Each tensor input must be annotated with the sizes of its dimensions;
these can either be fixed integers, or symbols that will be bound
to the appropriate size when the FPCore is executed.
For example, the input array
A in the following FPCore
n by 3. The FPCore returns the first
As purely functional data structures,
tensors cannot be modified in any way after they are created.
However, they can be copied by another
as alluded to in the previous example.
FPCore does not provide any numerical operations on tensors,
only the data structure operations
By specifying an identifier
to allow an FPCore to be called as an operationin other FPCores,
specific tensor operations can be defined,
such as matrix multiplication:
For algorithms with more complicated data dependencies,
tensor* expression can be used
to statefully loop over a tensor,
for example to compute a partial sum: