IMPLICIT
The IMPLICIT statement confirms or changes the default type of names.
IMPLICIT type ( a [, a ]) [, type ( a [, a ])]
CHARACTER* n (where n must be greater than 0 )
COMPLEX*32 u ( SPARC only )
DOUBLE COMPLEX u
REAL*16 u ( SPARC only )
Either a single letter or a range of single letters in alphabetical order. A range of letters can be specified by the first and last letters of the range, separated by a minus sign.
Description
The different uses for implicit typing and no implicit typing are described here.
Implicit Typing
The IMPLICIT statement can also indicate that no implicit typing rules apply in a program unit.
An IMPLICIT statement specifies a type and size for all user-defined names that begin with any letter, either a single letter or in a range of letters, appearing in the specification.
An IMPLICIT statement does not change the type of the intrinsic functions.
An IMPLICIT statement applies only to the program unit that contains it.
A program unit can contain more than one IMPLICIT statement.
IMPLICIT types for particular user names are overridden by a type statement.
Compiling with any of the options -dbl , -i2 , — r8 , or -xtypemap can alter the assumed size of names typed with an IMPLICIT statement that does not specify a size: IMPLICIT REAL (A-Z) . See Chapter 2 and the Fortran User’s Guide for details.
No Implicit Typing
The second form of IMPLICIT specifies that no implicit typing should be done for user-defined names, and all user-defined names shall have their types declared explicitly.
If either IMPLICIT NONE or IMPLICIT UNDEFINED (A-Z) is specified, there cannot be any other IMPLICIT statement in the program unit.
Restrictions
IMPLICIT statements must precede all other specification statements.
The same letter can appear more than once as a single letter, or in a range of letters in all IMPLICIT statements of a program unit. @
The FORTRAN 77 Standard restricts this usage to only once. For f77 , if a letter is used twice, each usage is declared in order. See Example 4.
Examples
Example 1: IMPLICIT : everything is integer:
Example 2: Complex if it starts with U , V , or W ; character if it starts with C or S :
Example 3: All items must be declared:
In the above example, once IMPLICIT NONE is specified in the beginning. All the variables must be declared explicitly.
Example 4: A letter used twice: @
In the above example, D through Z implies INTEGER , and A through C implies REAL .
Implicit none and carry on
Fortran has an interesting historic feature called implicit typing: Undeclared variables whose name begins with letters i, j, k, l, m, or n are implied to be integers, and real otherwise. For example, this is a valid Fortran program that prints a square of first five positive integers:
While there aren’t any variable declarations here, both i and x have a well defined type. The output?
This “feature” originated in the early days before FORTRAN 66 introduced the way to explicitly declare variables and their data type. FORTRAN 77 introduced the IMPLICIT statement to modify the implicit typing rules, although this wasn’t enough to prevent this joke from coming into existence:
In Fortran, GOD is REAL (unless declared INTEGER).
Implicit typing does add mental burden to the programmer, and can lead to surprising and unexpected behavior, especially in numerical code that relies on type coercion (mixed-mode arithmetic). Fortran 90 brought us the now ubiquitous implicit none , which enforces explicit declaration of all variables. Its adoption was so widespread that today you have to dig deep (and know where to look) to find legacy Fortran code without this statement. Typing implicit none at the start of any program is one of the first things a novice Fortran programmer learns today.
There has been discontent expressed recently on comp.lang.fortran about implicit typing, and requests to change the default behavior in the Fortran Standard — the reference specification of the language — to enforce explicit typing by default. In general, such requests aren’t well received by neither the Standard Committee members, nor by compiler developers. My opinion was unambiguous, if a bit blunt:
I’m fine with typing implicit none for the next 50 years, and perhaps longer. I prefer compiler developers focusing on more productive tasks.
The only benefit of such change would mean typing 13 characters less. It’s been argued that needing to type implicit none deters newcomers to the language and hinders its wider adoption. To date I haven’t seen evidence of this.
Don’t get me wrong — I wholeheartedly agree that implicit typing is an anti-pattern and I never ever recommend it. However, I disagree that changing the language to enforce explicit typing by default is a useful solution, not in the Fortran 202x era. Especially considering that compilers already have a flag to enforce this behavior. For example with gfortran and the program above:
With Intel Fortran compiler, the flag is -implicitnone . Easy, if that’s your cup of tea. I never use these myself. If you want it, you got it.
The downside to such change in the Standard is that it would break backwards compatibility, one of Fortran’s key strengths. If the default behavior changed, all of a sudden, with a single compiler update, a whole population of previously standard conforming code would stop building. Maintainers of such legacy systems would need to either update their code — by explicitly declaring all previously implicitly typed variables — or use a compiler option to allow it as an exception. In practice, the change would happen on both application and compiler ends, incurring development and maintenance costs.
Remember that Fortran is a mature language. The goal is not to move fast and break things. It’s to change the language as little as possible while incrementally improving it.
How about new code? If you always use implicit none in your Fortran code, as I do, you only need to type it in programs and modules. As long as you organize your functions and subroutines in modules (or, in programs under the contains statement), you’re really only typing implicit none every time you write a new program or a new module.
Is this such a big deal? Let’s see: It takes me about 2 seconds to type implicit none , new lines including. I only type it in new programs and modules. If you define procedures in modules exclusively, they inherit the explicit typing behavior. I write a new module or a program once every week, two at most. Let’s be generous and say that I type implicit none 100 times per year. Over the next 50 years, I will have typed it about 5000 times, spending a total of about 3 hours. There’s no cognitive burden here, it’s all muscle memory.
If you still think typing implicit none is a nuissance, a shift in perspective may help. Typing it can be a beautiful and meditative ritual. Like when you wake up in the morning and make that first stretch. Type implicit none to set the intention. The intention to write simple and correct code. Code that is fun to write, a joy to read, and most important, code that works. Take a slow, deep breath in…
3.3. Правила умолчания о типах данных
В Фортране допускается не объявлять объекты данных целого и вещественного типов. При этом тип данных объекта будет установлен в соответствии с существующими правилами умолчания: объекты данных, имена которых начинаются с букв i, j, k, l, m и n или с букв I, J, K, L, M и N , имеют по умолчанию стандартный целый тип (INTEGER); все остальные объекты имеют по умолчанию стандартный вещественный тип (REAL). Заметим, что на часть встроенных функций это правило не распространяется. Задаваемую по умолчанию разновидность типа данных можно изменить, задав для целого типа при компиляции опцию /4I2 или директиву $INTEGER:2 и для вещественного типа — опцию компилятора
/4R8 или директиву $REAL:8 [1].
! y — переменная типа REAL
риложение 3. Организация данных
3.4. Изменение правил умолчания
Изменение правил умолчания о типах объектов данных выполняется оператором IMPLICIT, который задает для объявленного пользователем имени принимаемый по умолчанию тип.
Синтаксис оператора: IMPLICIT NONE
IMPLICIT type(letters ) [, type(letters ), . ]
type — один из встроенных или производных типов данных.
letters — список одинарных букв или диапазонов букв. Диапазон букв задается первой и последней буквой диапазона, разделенными знаком тире, например c — f . Буквы и диапазоны букв в списке разделяются запятыми, например:
implicit integer(4) (a, c — f), character(10) (n)
После такого задания все объекты данных, имена которых начинаются с букв a и A и с букв из диапазона c — f и C — F , будут по умолчанию иметь тип INTEGER(4), а объекты, имена которых начинаются с букв n и N , по умолчанию будут иметь тип CHARACTER(10).
Задание одной и той же буквы в операторе (непосредственно или через диапазон) недопустимо. Диапазон букв должен быть задан в алфавитном порядке. Знак доллара ($), который может использоваться в качестве первой буквы имени, следует в алфавите за буквой Z .
Оператор не меняет типа встроенных функций.
Явное задание типа имеет более высокий приоритет, чем тип, указываемый оператором IMPLICIT. Задание
означает, что все используемые в программе имена должны быть введены явно (через операторы объявления типов данных). Невведенные имена приводят к возникновению ошибки на этапе компиляции. Никакие другие операторы IMPLICIT не могут указываться в программной единице, содержащей оператор IMPLICIT NONE. Ясно, что задание IMPLICIT NONE позволяет полностью контролировать типы всех объектов данных.
Types and kinds#
These intrinsics allow for explicitly casting one type of variable to another or can be used to conditionally execute code blocks based on variable types when working with polymorphic variables.
Fortran Data Types#
Fortran provides five basic intrinsic data types:
The integer types can hold only whole number values.
Stores floating point numbers, such as 2.0, 3.1415, -100.876, etc.
A complex number has two parts, the real part and the imaginary part. Two consecutive floating point storage units store the two parts.
There are only two logical values: .true. and .false.
The character type stores strings. The length of the string can be specified by the len specifier. If no length is specified, it is 1.
These “types” can be of many “kinds”. Often different numeric kinds take up different storage sizes and therefore can represent different ranges; but a different kind can have other meanings. A character variable might represent ASCII characters or UTF-8 or Unicode characters, for example.
You can derive your own data types from these fundamental types as well.
Implicit Typing#
Fortran allows a feature called implicit typing, i.e., you do not have to declare some variables before use. By default if a variable is not declared, then the first letter of its name will determine its type:
Variable names starting with i-n (the first two letters of “integer”) specify integer variables.
All other variable names default to real.
However, in most circles it is considered good programming practice to declare all the variables. For that to be enforced, you start your variable declaration section with a statement that turns off implicit typing: the statement
For more information refer to the implicit statement.
aimag#
Name#
aimag(3) — [TYPE:NUMERIC] Imaginary part of complex number
Synopsis#
Characteristics#
The type of the argument z shall be complex and any supported complex kind
The return value is of type real with the kind type parameter of the argument.
Description#
aimag(3) yields the imaginary part of the complex argument z.
This is similar to the modern complex-part-designator %IM which also designates the imaginary part of a value, accept a designator can appear on the left-hand side of an assignment as well, as in val%im=10.0.
Options#
- z
The complex value to extract the imaginary component of.
Result#
The return value is a real value with the magnitude and sign of the imaginary component of the argument z.
That is, If z has the value (x,y), the result has the value y.
Examples#
Standard#
See Also#
conjg(3) — Complex conjugate function
Fortran has strong support for complex values, including many intrinsics that take or produce complex values in addition to algebraic and logical expressions:
abs(3) , acosh(3) , acos(3) , asinh(3) , asin(3) , atan2(3) , atanh(3) , atan(3) , cosh(3) , cos(3) , co_sum(3) , dble(3) , dot_product(3) , exp(3) , int(3) , is_contiguous(3) , kind(3) , log(3) , matmul(3) , precision(3) , product(3) , range(3) , rank(3) , sinh(3) , sin(3) , sqrt(3) , storage_size(3) , sum(3) , tanh(3) , tan(3) , unpack(3) ,
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
cmplx#
Name#
cmplx(3) — [TYPE:NUMERIC] Conversion to a complex type
Synopsis#
Characteristics#
x may be integer, real, or complex.
y may be integer or real. y is allowed only if x is not complex.
KIND is a constant integer initialization expression indicating the kind parameter of the result.
The type of the arguments does not affect the kind of the result except for a complex x value.
if kind is not present and x is complex the result is of the kind of x.
if kind is not present and x is not complex the result if of default complex kind.
NOTE: a kind designated as ** may be any supported kind for the type
Description#
The cmplx(3) function converts numeric values to a complex value.
Even though constants can be used to define a complex variable using syntax like
this will not work for variables. So you cannot enter
so to construct a complex value using non-complex values you must use the cmplx(3) function:
or assign values separately to the imaginary and real components using the %IM and %RE designators:
If x is complex y is not allowed and cmplx essentially returns the input value except for an optional change of kind, which can be useful when passing a value to a procedure that requires the arguments to have a different kind (and does not return an altered value):
would pass a copy of a value with kind=real64 even if z had a different kind
but otherwise is equivalent to a simple assign. So if z1 and z2 were complex:
If x is not complex x is only used to define the real component of the result but y is still optional – the imaginary part of the result will just be assigned a value of zero.
If y is present it is converted to the imaginary component.
cmplx(3) and double precision#
Primarily in order to maintain upward compatibility you need to be careful when working with complex values of higher precision that the default.
It was necessary for Fortran to continue to specify that cmplx(3) always return a result of the default kind if the kind option is absent, since that is the behavior mandated by FORTRAN 77.
It might have been preferable to use the highest precision of the arguments for determining the return kind, but that is not the case. So with arguments with greater precision than default values you are required to use the kind argument or the greater precision values will be reduced to default precision.
This means cmplx(d1,d2), where d1 and d2 are doubleprecision, is treated as:
which looses precision.
So Fortran 90 extends the cmplx(3) intrinsic by adding an extra argument used to specify the desired kind of the complex result.
A more recent alternative to using cmplx(3) is “F2018 component syntax” where real and imaginary parts of a complex entity can be accessed independently:
Where the designator value is of course of complex type.
The type of a complex-part-designator is real, and its kind and shape are those of the designator. That is, you retain the precision of the complex value by default, unlike with cmplx.
The following are examples of complex part designators:
NOTE for I/O#
Note that if format statements are specified a complex value is treated as two real values.
For list-directed I/O (ie. using an asterisk for a format) and NAMELIST output the values are expected to be delimited by “(” and “)” and of the form “(realpart,imaginary_part)”. For NAMELIST input parenthesized values or lists of multiple _real values are acceptable.
Options#
- x
The value assigned to the real component of the result when x is not complex.
If x is complex, the result is the same as if the real part of the input was passed as x and the imaginary part as y.
That is, a complex x value is copied to the result value with a possible change of kind.
y is only allowed if x is not complex. Its value is assigned to the imaginary component of the result and defaults to a value of zero if absent.
An integer initialization expression indicating the kind parameter of the result.
Result#
The return value is of complex type, with magnitudes determined by the values x and y.
The common case when x is not complex is that the real component of the result is assigned the value of x and the imaginary part is zero or the value of y if y is present.
When x is complex y is not allowed and the result is the same value as x with a possible change of kind. That is, the real part is real(x, kind) and the imaginary part is real(y, kind).
Examples#
Standard#
FORTRAN 77, KIND added in Fortran 90.
See Also#
aimag(3) — Imaginary part of complex number
conjg(3) — Complex conjugate function
Fortran has strong support for complex values, including many intrinsics that take or produce complex values in addition to algebraic and logical expressions:
abs(3) , acosh(3) , acos(3) , asinh(3) , asin(3) , atan2(3) , atanh(3) , atan(3) , cosh(3) , cos(3) , co_sum(3) , dble(3) , dot_product(3) , exp(3) , int(3) , is_contiguous(3) , kind(3) , log(3) , matmul(3) , precision(3) , product(3) , range(3) , rank(3) , sinh(3) , sin(3) , sqrt(3) , storage_size(3) , sum(3) , tanh(3) , tan(3) , unpack(3) ,
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
Name#
int(3) — [TYPE:NUMERIC] Truncate towards zero and convert to integer
Synopsis#
Characteristics#
a kind designated as ** may be any supported kind for the type
a shall be of type integer, real, or complex, or a boz-literal-constant.
KIND shall be a scalar integer constant expression.
Description#
int(3) truncates towards zero and return an integer.
Options#
- a
is the value to truncate towards zero
indicates the kind parameter of the result. If not present the returned type is that of default integer type.
Result#
returns an integer variable applying the following rules:
Case:
If a is of type integer, int(a) = a
If a is of type real and |a| < 1, int(a) equals 0. If |a| >= 1, then int(a) equals the integer whose magnitude does not exceed a and whose sign is the same as the sign of a.
If a is of type complex, rule 2 is applied to the real part of a.
If a is a boz-literal constant, it is treated as an integer with the kind specified.
The interpretation of a bit sequence whose most significant bit is 1 is processor dependent.
The result is undefined if it cannot be represented in the specified integer type.
Examples#
Standard#
See Also#
aint(3) , anint(3) , nint(3) , selected_int_kind(3) , ceiling(3) , floor(3)
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
Name#
nint(3) — [TYPE:NUMERIC] Nearest whole number
Synopsis#
Characteristics#
a kind designated as ** may be any supported kind for the type
a is type real of any kind
KIND is a scalar integer constant expression
The result is default integer kind or the value of kind if kind is present.
Description#
nint(3) rounds its argument to the nearest whole number with its sign preserved.
The user must ensure the value is a valid value for the range of the kind returned. If the processor cannot represent the result in the kind specified, the result is undefined.
If a is greater than zero, nint(a) has the value int(a+0.5).
If a is less than or equal to zero, nint(a) has the value int(a-0.5).
Options#
- a
The value to round to the nearest whole number
can specify the kind of the output value. If not present, the output is the default type of integer.
Result#
The result is the integer nearest a, or if there are two integers equally near a, the result is whichever such integer has the greater magnitude.
The result is undefined if it cannot be represented in the specified integer type.
Examples#
Standard#
FORTRAN 77 , with KIND argument — Fortran 90
See Also#
aint(3) , anint(3) , int(3) , selected_int_kind(3) , ceiling(3) , floor(3)
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
Name#
real(3) — [TYPE:NUMERIC] Convert to real type
Synopsis#
Characteristics#
the type of x may be integer, real, or complex; or a BOZ-literal-constant.
kind is a integer initialization expression (a constant expression)
If kind is present it defines the kind of the real result
if kind is not present
when x is complex the result is a real of the same kind as x.
when x is real or integer the result is a real of default kind
a kind designated as ** may be any supported kind for the type
Description#
real(3) converts its argument x to a real type.
The real part of a complex value is returned. For complex values this is similar to the modern complex-part-designator %RE which also designates the real part of a complex value.
Options#
- x
An integer, real, or complex value to convert to real.
When present the value of kind defines the kind of the result.
Result#
real(x) converts x to a default real type if x is an integer or real variable.
real(x) converts a complex value to a real type with the magnitude of the real component of the input with kind type parameter the same as x.
real(x, kind) is converted to a real type with kind type parameter kind if x is a complex, integer, or real variable.
Examples#
Standard#
See Also#
aimag(3) — Imaginary part of complex number
conjg(3) — Complex conjugate function
Fortran has strong support for complex values, including many intrinsics that take or produce complex values in addition to algebraic and logical expressions:
abs(3) , acosh(3) , acos(3) , asinh(3) , asin(3) , atan2(3) , atanh(3) , atan(3) , cosh(3) , cos(3) , co_sum(3) , dble(3) , dot_product(3) , exp(3) , int(3) , is_contiguous(3) , kind(3) , log(3) , matmul(3) , precision(3) , product(3) , range(3) , rank(3) , sinh(3) , sin(3) , sqrt(3) , storage_size(3) , sum(3) , tanh(3) , tan(3) , unpack(3) ,
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
Name#
dble(3) — [TYPE:NUMERIC] Converstion to double precision real
Synopsis#
Characteristics#
a my be integer, real, complex, or a BOZ-literal-constant
the result is a doubleprecision real.
Description#
dble(3) Converts a to double precision real type.
Options#
- a
a value to convert to a doubleprecision real.
Result#
The return value is of type doubleprecision. For complex input, the returned value has the magnitude and sign of the real component of the input value.
Examples#
Standard#
See also#
aimag(3) — Imaginary part of complex number
cmplx(3) — Convert values to a complex type
int(3) — Truncate towards zero and convert to integer
out_of_range(3) — Whether a value cannot be converted safely.
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
transfer#
Name#
transfer(3) — [TYPE:MOLD] Transfer bit patterns
Synopsis#
Characteristics#
source shall be a scalar or an array of any type.
mold shall be a scalar or an array of any type.
size shall be a scalar of type integer.
result has the same type as mold
Description#
transfer(3) copies the bitwise representation of source in memory into a variable or array of the same type and type parameters as mold.
This is approximately equivalent to the C concept of “casting” one type to another.
Options#
- source
Holds the bit pattern to be copied
the type of mold is used to define the type of the returned value. In addition, if it is an array the returned value is a one-dimensional array. If it is a scalar the returned value is a scalar.
If size is present, the result is a one-dimensional array of length size.
If size is absent but mold is an array (of any size or shape), the result is a one-dimensional array of the minimum length needed to contain the entirety of the bitwise representation of source.
If size is absent and mold is a scalar, the result is a scalar.
Result#
The result has the bit level representation of source.
If the bitwise representation of the result is longer than that of source, then the leading bits of the result correspond to those of source but any trailing bits are filled arbitrarily.
When the resulting bit representation does not correspond to a valid representation of a variable of the same type as mold, the results are undefined, and subsequent operations on the result cannot be guaranteed to produce sensible behavior. For example, it is possible to create logical variables for which var and .not. var both appear to be true.
Examples#
Comments#
Joe Krahn: Fortran uses molding rather than casting.
Casting, as in C, is an in-place reinterpretation. A cast is a device that is built around an object to change its shape.
Fortran transfer(3) reinterprets data out-of-place. It can be considered molding rather than casting. A mold is a device that confers a shape onto an object placed into it.
The advantage of molding is that data is always valid in the context of the variable that holds it. For many cases, a decent compiler should optimize transfer(3) into a simple assignment.
There are disadvantages of this approach. It is problematic to define a union of data types because you must know the largest data object, which can vary by compiler or compile options. In many cases, an EQUIVALENCE would be far more effective, but Fortran Standards committees seem oblivious to the benefits of EQUIVALENCE when used sparingly.
Standard#
See also#
fortran-lang intrinsic descriptions
logical#
Name#
logical(3) — [TYPE:LOGICAL] Conversion between kinds of logical values
Synopsis#
Characteristics#
a kind designated as ** may be any supported kind for the type
l is of type logical
KIND shall be a scalar integer constant expression. If KIND is present, the kind type parameter of the result is that specified by the value of KIND; otherwise, the kind type parameter is that of default logical.
Description#
logical(3) converts one kind of logical variable to another.
Options#
- l
The logical value to produce a copy of with kind kind
indicates the kind parameter of the result. If not present, the default kind is returned.
Result#
The return value is a logical value equal to l, with a kind corresponding to kind, or of the default logical kind if kind is not given.
Examples#
Standard#
Fortran 95 , related ISO_FORTRAN_ENV module — fortran 2009
See Also#
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
Name#
kind(3) — [KIND:INQUIRY] Query kind of an entity
Synopsis#
Characteristics#
x may be of any intrinsic type. It may be a scalar or an array.
the result is a default integer scalar
Description#
kind(x)(3) returns the kind value of the entity x.
Options#
- x
Value to query the kind of.
Result#
The return value indicates the kind of the argument x.
Note that kinds are processor-dependent.
Examples#
Standard#
See also#
allocated(3) — Status of an allocatable entity
is_contiguous(3) — test if object is contiguous
lbound(3) — Lower dimension bounds of an array
rank(3) — Rank of a data object
shape(3) — Determine the shape of an array
size(3) — Determine the size of an array
ubound(3) — Upper dimension bounds of an array
bit_size(3) — Bit size inquiry function
storage_size(3) — Storage size in bits
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
out_of_range#
Name#
out_of_range(3) — [TYPE:NUMERIC] Whether a value cannot be converted safely.
Synopsis#
Characteristics#
x is of type integer or real.
mold is an integer or real scalar.
round is a logical scalar.
the result is a default logical.
Description#
out_of_range(3) determines whether a value x can be converted safely to a real or integer variable the same type and kind as mold.
For example, if int8 is the kind value for an 8-bit binary integer type, out_of_range(-128.5, 0_int8) will have the value false and out_of_range(-128.5, 0_int8, .true.) will have the value .true. because the value will be truncated when converted to an integer and -128 is a representable value on a two’s complement machine in eight bits even though +128 is not.
Options#
- x
a scalar to be tested for whether it can be stored in a variable of the type and kind of mold
mold and kind are queried to determine the characteristics of what needs to be fit into.
flag whether to round the value of xx before validating it as an integer value like mold.
round can only be present if x is of type real and mold is of type integer.
Result#
From the standard:
Case (i): If mold is of type integer, and round is absent or present with the value false, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer with largest magnitude that lies between zero and X inclusive is not representable by objects with the type and kind of mold.
Case (ii): If mold is of type integer, and round is present with the value true, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer nearest X, or the integer of greater magnitude if two integers are equally near to X, is not representable by objects with the type and kind of mold.
Case (iii): Otherwise, the result is true if and only if the value of X is an IEEE infinity or NaN that is not supported by objects of the type and kind of mold, or if X is a finite number and the result of rounding the value of X (according to the IEEE rounding mode if appropriate) to the extended model for the kind of mold has magnitude larger than that of the largest finite number with the same sign as X that is representable by objects with the type and kind of mold.
mold is required to be a scalar because the only information taken from it is its type and kind. Allowing an array mold would require that it be conformable with x. round is scalar because allowing an array rounding mode would have severe performance difficulties on many processors.