Changes in doc/user/user.tex [c45170a:08061589]
- File:
-
- 1 edited
-
doc/user/user.tex (modified) (37 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
rc45170a r08061589 10 10 %% Author : Peter A. Buhr 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 %% Last Modified By : Peter A. Buhr13 %% Last Modified On : Mon Aug 1 08:43:49201614 %% Update Count : 12 7012 %% Last Modified By : 13 %% Last Modified On : Sun Jul 31 07:27:55 2016 14 %% Update Count : 1254 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 211 211 however, it largely extended the language, and did not address many existing problems.\footnote{% 212 212 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.} 213 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features ( \egobjects, concurrency) are added and problems fixed within the framework of the existing language.213 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language. 214 214 \Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent. 215 215 These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection. … … 265 265 \section[Compiling CFA Program]{Compiling \CFA Program} 266 266 267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, e.g.: 268 268 \begin{lstlisting} 269 269 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ] … … 350 350 \section{Underscores in Constants} 351 351 352 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:352 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.: 353 353 \begin{lstlisting} 354 354 2®_®147®_®483®_®648; §\C{// decimal constant}§ … … 366 366 \begin{enumerate} 367 367 \item 368 A sequence of underscores is disallowed, \eg©12__34© is invalid.368 A sequence of underscores is disallowed, e.g., ©12__34© is invalid. 369 369 \item 370 370 Underscores may only appear within a sequence of digits (regardless of the digit radix). 371 In other words, an underscore cannot start or end a sequence of digits, \eg©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).371 In other words, an underscore cannot start or end a sequence of digits, e.g., ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names). 372 372 \item 373 373 A numeric prefix may end with an underscore; … … 498 498 \end{quote2} 499 499 500 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:500 All type qualifiers, e.g., ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, e.g.: 501 501 \begin{quote2} 502 502 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} … … 518 518 \end{tabular} 519 519 \end{quote2} 520 All declaration qualifiers, \eg©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}521 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:520 All declaration qualifiers, e.g., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier} 521 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.: 522 522 \begin{quote2} 523 523 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} … … 542 542 Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{ 543 543 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}} 544 \eg:544 e.g.: 545 545 \begin{lstlisting} 546 546 x; §\C{// int x}§ … … 612 612 A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime. 613 613 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.) 614 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:614 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.: 615 615 \begin{quote2} 616 616 \begin{tabular}{@{}ll@{}} … … 669 669 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. 670 670 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 671 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:671 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.: 672 672 \begin{lstlisting} 673 673 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); … … 677 677 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); 678 678 \end{lstlisting} 679 When a reference operation appears beside a dereference operation, \eg©&*©, they cancel out.\footnote{679 When a reference operation appears beside a dereference operation, e.g., ©&*©, they cancel out.\footnote{ 680 680 The unary ©&© operator yields the address of its operand. 681 681 If the operand has type ``type'', the result has type ``pointer to type''. … … 721 721 ®&®crc = &cx; §\C{// error, cannot change crc}§ 722 722 \end{lstlisting} 723 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:723 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, e.g.: 724 724 \begin{lstlisting} 725 725 int & const r = *0; §\C{// where 0 is the int * zero}§ 726 726 \end{lstlisting} 727 727 Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented. 728 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.729 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;730 \CFA-style declarations attempt to address this issue:731 \begin{quote2}732 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}733 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\734 \begin{lstlisting}735 ®const® * ®const® * const int ccp;736 ®const® & ®const® & const int ccr;737 \end{lstlisting}738 &739 \begin{lstlisting}740 const int * ®const® * ®const® ccp;741 742 \end{lstlisting}743 \end{tabular}744 \end{quote2}745 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).746 728 747 729 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object. … … 803 785 \section{Type Operators} 804 786 805 The new declaration syntax can be used in other contexts where types are required, \egcasts and the pseudo-routine ©sizeof©:787 The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©: 806 788 \begin{quote2} 807 789 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 823 805 824 806 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax. 825 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:807 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, e.g.: 826 808 \begin{lstlisting} 827 809 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) { … … 835 817 \Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.} 836 818 The value of each local return variable is automatically returned at routine termination. 837 Declaration qualifiers can only appear at the start of a routine definition, \eg:819 Declaration qualifiers can only appear at the start of a routine definition, e.g.: 838 820 \begin{lstlisting} 839 821 ®extern® [ int x ] g( int y ) {§\,§} … … 867 849 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts. 868 850 869 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:851 C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.: 870 852 \begin{lstlisting} 871 853 [ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§ … … 916 898 917 899 The syntax of the new routine prototype declaration follows directly from the new routine definition syntax; 918 as well, parameter names are optional, \eg:900 as well, parameter names are optional, e.g.: 919 901 \begin{lstlisting} 920 902 [ int x ] f (); §\C{// returning int with no parameters}§ … … 924 906 \end{lstlisting} 925 907 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). 926 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:908 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), e.g.: 927 909 \begin{quote2} 928 910 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 937 919 \end{tabular} 938 920 \end{quote2} 939 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:921 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} e.g.: 940 922 \begin{lstlisting} 941 923 extern [ int ] f (int); … … 946 928 \section{Routine Pointers} 947 929 948 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:930 The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.: 949 931 \begin{lstlisting} 950 932 * [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§ … … 1064 1046 p( /* positional */, /* named */, . . . ); 1065 1047 \end{lstlisting} 1066 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:1048 While it is possible to implement both approaches, the first possibly is more complex than the second, e.g.: 1067 1049 \begin{lstlisting} 1068 1050 p( int x, int y, int z, . . . ); … … 1074 1056 In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call. 1075 1057 1076 The problem is exacerbated with default arguments, \eg:1058 The problem is exacerbated with default arguments, e.g.: 1077 1059 \begin{lstlisting} 1078 1060 void p( int x, int y = 2, int z = 3. . . ); … … 1282 1264 1283 1265 As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call. 1284 In unambiguous situations, the tuple brackets may be omitted, \ega tuple that appears as an argument may have its1266 In unambiguous situations, the tuple brackets may be omitted, e.g., a tuple that appears as an argument may have its 1285 1267 square brackets omitted for convenience; therefore, the following routine invocations are equivalent: 1286 1268 \begin{lstlisting} … … 1321 1303 1322 1304 Type qualifiers, i.e., const and volatile, may modify a tuple type. 1323 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:1305 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, e.g.: 1324 1306 \begin{lstlisting} 1325 1307 const volatile [ int, float, const int ] x; … … 1329 1311 [ const volatile int, const volatile float, const volatile int ] x; 1330 1312 \end{lstlisting} 1331 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:1313 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, e.g.: 1332 1314 \begin{lstlisting} 1333 1315 extern [ int, int ] w1; … … 1337 1319 Unfortunately, C's syntax for subscripts precluded treating them as tuples. 1338 1320 The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©. 1339 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg©f[g()]© always means a single subscript value because there is only one set of brackets.1321 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., ©f[g()]© always means a single subscript value because there is only one set of brackets. 1340 1322 Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression. 1341 1323 \end{rationale} … … 1398 1380 Clearly, the types of the entities being assigned must be type compatible with the value of the expression. 1399 1381 1400 Mass assignment has parallel semantics, \egthe statement:1382 Mass assignment has parallel semantics, e.g., the statement: 1401 1383 \begin{lstlisting} 1402 1384 [ x, y, z ] = 1.5; … … 1487 1469 \section{Unnamed Structure Fields} 1488 1470 1489 C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:1471 C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.: 1490 1472 \begin{lstlisting} 1491 1473 struct { 1492 int f1; §\C{// named field}§1493 int f2 : 4; §\C{// named field with bit field size}§1494 int : 3; §\C{// unnamed field for basic type with bit field size}§1495 int ; §\C{// disallowed, unnamed field}§1496 int *; §\C{// disallowed, unnamed field}§1497 int (*)(int); §\C{// disallowed, unnamed field}§1474 int f1; // named field 1475 int f2 : 4; // named field with bit field size 1476 int : 3; // unnamed field for basic type with bit field size 1477 int ; // disallowed, unnamed field 1478 int *; // disallowed, unnamed field 1479 int (*)(int); // disallowed, unnamed field 1498 1480 }; 1499 1481 \end{lstlisting} 1500 1482 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. 1501 1483 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. 1502 A list of unnamed fields is also supported, \eg:1484 A list of unnamed fields is also supported, e.g.: 1503 1485 \begin{lstlisting} 1504 1486 struct { 1505 int , , ; §\C{// 3 unnamed fields}§1487 int , , ; // 3 unnamed fields 1506 1488 } 1507 1489 \end{lstlisting} … … 1516 1498 §\emph{expr}§ -> [ §\emph{fieldlist}§ ] 1517 1499 \end{lstlisting} 1518 \emph{expr} is any expression yielding a value of type record, \eg©struct©, ©union©.1500 \emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©. 1519 1501 Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}. 1520 1502 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is … … 1778 1760 } 1779 1761 \end{lstlisting} 1780 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. 1781 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic. 1782 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1783 The key observation is that the ©switch© statement branches into control structure, i.e., there are multiple entry points into its statement body. 1762 While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. 1763 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©. 1764 As mentioned, transfer into control structures should be forbidden; 1765 transfers from within the ©switch© body using a ©goto© are equally unpalatable. 1766 As well, the declaration of ©z© is cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1784 1767 \end{enumerate} 1785 1768 … … 1795 1778 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound. 1796 1779 \end{itemize} 1797 These observations help to put the suggestedchanges to the ©switch© into perspective.1780 These observations help to put the \CFA changes to the ©switch© into perspective. 1798 1781 \begin{enumerate} 1799 1782 \item 1800 1783 Eliminating default fall-through has the greatest potential for affecting existing code. 1801 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg:1802 1784 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.: 1785 \begin{lstlisting} 1803 1786 case 1: case 2: case 3: ... 1804 1787 \end{lstlisting} 1805 1788 still work. 1806 1789 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments. 1807 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthr u©, \eg:1790 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.: 1808 1791 \begin{lstlisting} 1809 1792 ®choose® ( i ) { … … 1832 1815 Therefore, no change is made for this issue. 1833 1816 \item 1834 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause \footnote{1835 Essentially, these declarations are hoisted before the ©switch©/©choose©statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.1836 Further declaration s at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.1817 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause.\footnote{ 1818 Essentially, these declarations are hoisted before the statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause. 1819 Further declaration in the statement body are disallowed. 1837 1820 \begin{lstlisting} 1838 1821 switch ( x ) { 1839 ®int i = 0;® §\C{// allowed only at start}§1822 ®int i = 0;® §\C{// allowed}§ 1840 1823 case 0: 1841 1824 ... 1842 ®int j= 0;® §\C{// disallowed}§1825 ®int i = 0;® §\C{// disallowed}§ 1843 1826 case 1: 1844 1827 { 1845 ®int k = 0;® §\C{// allowed at different nesting levels}§1828 ®int i = 0;® §\C{// allowed in any compound statement}§ 1846 1829 ... 1847 1830 } … … 2724 2707 Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser. 2725 2708 2726 There are several ambiguous cases with operator identifiers, \eg©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.2727 Since it is common practise to put a unary operator juxtaposed to an identifier, \eg©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.2709 There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©. 2710 Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers. 2728 2711 Even with this special hack, there are 5 general cases that cannot be handled. 2729 2712 The first case is for the function-call identifier ©?()©: … … 2790 2773 This means that a function requiring mutual exclusion could block if the lock is already held by another thread. 2791 2774 Blocking on a monitor lock does not block the kernel thread, it simply blocks the user thread, which yields its kernel thread while waiting to obtain the lock. 2792 If multiple mutex parameters are specified, they will be locked in parameter order ( \iefirst parameter is locked first) and unlocked in the2775 If multiple mutex parameters are specified, they will be locked in parameter order (i.e. first parameter is locked first) and unlocked in the 2793 2776 reverse order. 2794 2777 \begin{lstlisting} … … 4359 4342 4360 4343 4344 \section{New Keywowrds} 4345 4346 ©catch©, ©catchResume©, ©choose©, \quad ©disable©, ©dtype©, \quad ©enable©, \quad ©fallthrough©, ©fallthru©, ©finally©, ©forall©, ©ftype©, \quad ©lvalue©, \quad ©otype©, \quad ©throw©, ©throwResume©, ©trait©, ©try© 4347 4348 4361 4349 \section{Incompatible} 4362 4350 … … 4488 4476 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4489 4477 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4490 Given that nested types in C are equivalent to not using them, \iethey are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.4478 Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility. 4491 4479 \end{description} 4492 4480 … … 5179 5167 \label{s:RationalNumbers} 5180 5168 5181 Rational numbers are numbers written as a ratio, \ieas a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.5169 Rational numbers are numbers written as a ratio, i.e., as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers. 5182 5170 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible. 5183 5171
Note:
See TracChangeset
for help on using the changeset viewer.
