Стандарт языка Си С99 TC (1113411), страница 79
Текст из файла (страница 79)
They do not raise the ‘‘inexact’’ floating-point exception if the result differs invalue from the argument.— nearbyint(±0) returns ±0 (for all rounding directions).— nearbyint(±∞) returns ±∞ (for all rounding directions).F.9.6.4 The rint functions1The rint functions differ from the nearbyint functions only in that they do raise the‘‘inexact’’ floating-point exception if the result differs in value from the argument.F.9.6.5 The lrint and llrint functions1The lrint and llrint functions provide floating-to-integer conversion as prescribedby IEC 60559.
They round according to the current rounding direction. If the roundedvalue is outside the range of the return type, the numeric result is unspecified and the‘‘invalid’’ floating-point exception is raised. When they raise no other floating-pointexception and the result differs from the argument, they raise the ‘‘inexact’’ floating-pointexception.§F.9.6.5IEC 60559 floating-point arithmetic463ISO/IEC 9899:TC3Committee Draft — Septermber 7, 2007WG14/N1256F.9.6.6 The round functions1— round(±0) returns ±0.— round(±∞) returns ±∞.2The double version of round behaves as though implemented by#include <math.h>#include <fenv.h>#pragma STDC FENV_ACCESS ONdouble round(double x){double result;fenv_t save_env;feholdexcept(&save_env);result = rint(x);if (fetestexcept(FE_INEXACT)) {fesetround(FE_TOWARDZERO);result = rint(copysign(0.5 + fabs(x), x));}feupdateenv(&save_env);return result;}The round functions may, but are not required to, raise the ‘‘inexact’’ floating-pointexception for non-integer numeric arguments, as this implementation does.F.9.6.7 The lround and llround functions1The lround and llround functions differ from the lrint and llrint functionswith the default rounding direction just in that the lround and llround functionsround halfway cases away from zero and need not raise the ‘‘inexact’’ floating-pointexception for non-integer arguments that round to within the range of the return type.F.9.6.8 The trunc functions1The trunc functions use IEC 60559 rounding toward zero (regardless of the currentrounding direction).— trunc(±0) returns ±0.— trunc(±∞) returns ±∞.464IEC 60559 floating-point arithmetic§F.9.6.8WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC3F.9.7 Remainder functionsF.9.7.1 The fmod functions1— fmod(±0, y) returns ±0 for y not zero.— fmod(x, y) returns a NaN and raises the ‘‘invalid’’ floating-point exception for xinfinite or y zero.— fmod(x, ±∞) returns x for x not infinite.2The double version of fmod behaves as though implemented by#include <math.h>#include <fenv.h>#pragma STDC FENV_ACCESS ONdouble fmod(double x, double y){double result;result = remainder(fabs(x), (y = fabs(y)));if (signbit(result)) result += y;return copysign(result, x);}F.9.7.2 The remainder functions1The remainder functions are fully specified as a basic arithmetic operation inIEC 60559.F.9.7.3 The remquo functions1The remquo functions follow the specifications for the remainder functions.
Theyhave no further specifications special to IEC 60559 implementations.F.9.8 Manipulation functionsF.9.8.1 The copysign functions1copysign is specified in the Appendix to IEC 60559.F.9.8.2 The nan functions1All IEC 60559 implementations support quiet NaNs, in all floating formats.§F.9.8.2IEC 60559 floating-point arithmetic465ISO/IEC 9899:TC3Committee Draft — Septermber 7, 2007WG14/N1256F.9.8.3 The nextafter functions1— nextafter(x, y) raises the ‘‘overflow’’ and ‘‘inexact’’ floating-point exceptionsfor x finite and the function value infinite.— nextafter(x, y) raises the ‘‘underflow’’ and ‘‘inexact’’ floating-pointexceptions for the function value subnormal or zero and x ≠ y.F.9.8.4 The nexttoward functions1No additional requirements beyond those on nextafter.F.9.9 Maximum, minimum, and positive difference functionsF.9.9.1 The fdim functions1No additional requirements.F.9.9.2 The fmax functions1If just one argument is a NaN, the fmax functions return the other argument (if botharguments are NaNs, the functions return a NaN).2The body of the fmax function might be323){ return (isgreaterequal(x, y) ||isnan(y)) ? x : y; }F.9.9.3 The fmin functions1The fmin functions are analogous to the fmax functions (see F.9.9.2).F.9.10 Floating multiply-addF.9.10.1 The fma functions1— fma(x, y, z) computes xy + z, correctly rounded once.— fma(x, y, z) returns a NaN and optionally raises the ‘‘invalid’’ floating-pointexception if one of x and y is infinite, the other is zero, and z is a NaN.— fma(x, y, z) returns a NaN and raises the ‘‘invalid’’ floating-point exception ifone of x and y is infinite, the other is zero, and z is not a NaN.— fma(x, y, z) returns a NaN and raises the ‘‘invalid’’ floating-point exception if xtimes y is an exact infinity and z is also an infinity but with the opposite sign.323) Ideally, fmax would be sensitive to the sign of zero, for example fmax(−0.
0,return +0; however, implementation in software might be impractical.466IEC 60559 floating-point arithmetic+0. 0) would§F.9.10.1WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC3Annex G(informative)IEC 60559-compatible complex arithmeticG.1 Introduction1This annex supplements annex F to specify complex arithmetic for compatibility withIEC 60559 real floating-point arithmetic. Although these specifications have beencarefully designed, there is little existing practice to validate the design decisions.Therefore, these specifications are not normative, but should be viewed more asrecommendedpractice.Animplementationthatdefines_ _STDC_IEC_559_COMPLEX_ _ should conform to the specifications in this annex.G.2 Types1There is a new keyword _Imaginary, which is used to specify imaginary types. It isused as a type specifier within declaration specifiers in the same way as _Complex is(thus, _Imaginary float is a valid type name).2There are three imaginary types, designated as float _Imaginary, double_Imaginary, and long double _Imaginary.
The imaginary types (along withthe real floating and complex types) are floating types.3For imaginary types, the corresponding real type is given by deleting the keyword_Imaginary from the type name.4Each imaginary type has the same representation and alignment requirements as thecorresponding real type. The value of an object of imaginary type is the value of the realrepresentation times the imaginary unit.5The imaginary type domain comprises the imaginary types.G.3 Conventions1A complex or imaginary value with at least one infinite part is regarded as an infinity(even if its other part is a NaN).
A complex or imaginary value is a finite number if eachof its parts is a finite number (neither infinite nor NaN). A complex or imaginary value isa zero if each of its parts is a zero.§G.3IEC 60559-compatible complex arithmetic467ISO/IEC 9899:TC3Committee Draft — Septermber 7, 2007WG14/N1256G.4 ConversionsG.4.1 Imaginary types1Conversions among imaginary types follow rules analogous to those for real floatingtypes.G.4.2 Real and imaginary1When a value of imaginary type is converted to a real type other than _Bool,324) theresult is a positive zero.2When a value of real type is converted to an imaginary type, the result is a positiveimaginary zero.G.4.3 Imaginary and complex1When a value of imaginary type is converted to a complex type, the real part of thecomplex result value is a positive zero and the imaginary part of the complex result valueis determined by the conversion rules for the corresponding real types.2When a value of complex type is converted to an imaginary type, the real part of thecomplex value is discarded and the value of the imaginary part is converted according tothe conversion rules for the corresponding real types.G.5 Binary operators1The following subclauses supplement 6.5 in order to specify the type of the result for anoperation with an imaginary operand.2For most operand types, the value of the result of a binary operator with an imaginary orcomplex operand is completely determined, with reference to real arithmetic, by the usualmathematical formula.
For some operand types, the usual mathematical formula isproblematic because of its treatment of infinities and because of undue overflow orunderflow; in these cases the result satisfies certain properties (specified in G.5.1), but isnot completely determined.324) See 6.3.1.2.468IEC 60559-compatible complex arithmetic§G.5WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC3G.5.1 Multiplicative operatorsSemantics1If one operand has real type and the other operand has imaginary type, then the result hasimaginary type. If both operands have imaginary type, then the result has real type. (Ifeither operand has complex type, then the result has complex type.)2If the operands are not both complex, then the result and floating-point exceptionbehavior of the * operator is defined by the usual mathematical formula:*uivu + ivxxui(xv)(xu) + i(xv)iyi(yu)−yv(−yv) + i(yu)(xu) + i(yu)(−yv) + i(xv)x + iy3If the second operand is not complex, then the result and floating-point exceptionbehavior of the / operator is defined by the usual mathematical formula:/uivxx/ui(−x/v)iyi(y/u)y/v(x/u) + i(y/u)(y/v) + i(−x/v)x + iy4The * and / operators satisfy the following infinity properties for all real, imaginary, andcomplex operands:325)— if one operand is an infinity and the other operand is a nonzero finite number or aninfinity, then the result of the * operator is an infinity;— if the first operand is an infinity and the second operand is a finite number, then theresult of the / operator is an infinity;— if the first operand is a finite number and the second operand is an infinity, then theresult of the / operator is a zero;325) These properties are already implied for those cases covered in the tables, but are required for all cases(at least where the state for CX_LIMITED_RANGE is ‘‘off’’).§G.5.1IEC 60559-compatible complex arithmetic469ISO/IEC 9899:TC3Committee Draft — Septermber 7, 2007WG14/N1256— if the first operand is a nonzero finite number or an infinity and the second operand isa zero, then the result of the / operator is an infinity.5If both operands of the * operator are complex or if the second operand of the / operatoris complex, the operator raises floating-point exceptions if appropriate for the calculationof the parts of the result, and may raise spurious floating-point exceptions.6EXAMPLE 1 Multiplication of double _Complex operands could be implemented as follows.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
