ࡱ; IJ  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHKLMNOPQRSTUVWXYZ[\]^_`abR FzR!CompObj^WordDocument͹ObjectPoolrR!rR!  FMicrosoft Word 6.0 (dokument)NB6WWord.Document.6;  Oh+'0  & 2>F NZw &PowerMac:Microsoft Word:Mallar:Normalpage 1:Inst fr DatavetenskapInst fr Datavetenskap'@lN @v@ nR!@ܥhQe͹βββββȳȳȳȳȳس vȳ=XX"zzzzzzɸ˸˸˸˸˸˸&.XGβ EFzz ββzX βzβzɸV8ββββzɸ  Page-by-page comments on LIA-2, ISO/IEC WD 10967-2, (SC22/WG11 N424) page 1: first para: "real elementary" -> "floating point elementary" para 5: "are integer" -> "are values in integer" para 6: Lisp: refer to ANSI Common Lisp, as well as ISO ISLisp. page 2: first para: refer to (some) format standards? (in a note) (ISO 6093:1985?) second para of clause 2: delete first "OP"; replace second "OP" with "the value of the operation when applied to arguments" point "a": "operation" -> "value" point "b": "OP conform" -> "the operation conforms" section 2.1 should still be deleted entirely! I see no way of reasonably interpreting it in the context of computer arithmetic. page 3: display at bottom of page: "implication" -> "implication and equivalence"; "on R" -> "on reals" (twice) (cmp. the corresponding text in LIA-1.) page 4: top display: natural exponentiation and to-the-power-of functions are missing... (there is some overlap with the previous display, ok?, join?, or what?) para 4, etc.: I still prefer having indices on the letter F when several different floating point type/value-set meta-variables are needed at once. middle of page, etc.: rename arg_too_big to angle_too_big. "note 1": delete and instead put quotes around negative zero etc.: '0', '(', '+('. At some places the mathematical sense of infinity is referred to, and should not be confused with the IEC 559 "infinities". Likewise for negative zero. "The data type Sequence...": should not be needed, delete. page 5: top line: add "and i /= 0" (otherwise 0|0 is true, which I think is a bad idea, since 0 is not a divisor of anything, not even 0). the definitions following that: PLEASE DO NOT USE CONVENTIONAL NOTATION IN AN UNCONVENTIONAL SENSE! E.g. do not use the floor and ceiling brackets as you have doen here. Use names like "down_F", "up_F" instead (and "nearest_F" should be exactly the same as the "nearest_F" that appears in LIA-1). These definitions are, again, ill defined (max and min are not defined on empty sets). Using notifications for these definitions would also be inappropriate. Define them instead, after renaming, to be functions from R to F* (F* as defined in LIA-1). The floor and ceiling brackets should only be used in their conventional sense. If you absolutely must write out the definitions of the floor and ceiling brackets (they have the same status as +, etc. which are not explicitly defined): Copy the text from LIA-1 for the floor brackets! Make another copy and do suitable (obvious) modifications for the ceiling brackets. Add "round" (from R to Z), which rounds to nearest, ties rounded to even. And for the floating point results case: down_F is a helper rounding function from R to F* satisfying the round towards negative infinity property. up_F is a helper rounding function from R to F* satisfying the round towards positive infinity property. nearest_F is a helper rounding function from R to F* satisfying the round to nearest property. (as in LIA-1, sect 5.3, ties are rounded in a sign symmetric way, but is otherwise and as yet undetermined; cmp. LIA-1). middle of page, "Predicates...": delete that sentence since it is false. sect. 4.2: delete all the numbers in front of the words defined. continiation value: "exception" -> "notification" monotonic...: these definitions need to be reworked and simplified. page 8: last para of "signature": "input range" -> "domain"; "output range" -> range" "ulp": (used in LIA-1 too, but does not occur in its 4.2...); "e" may be confused with the Napierian (natural) logarithm/exponentiation base, use another variable name, like "d". 5.2, first para: untrue, *all* the "components" (in the current spec. style) *together* defines the operation, not that "component" only. The meanings of the words "definition" and "axiom" are so distorted in LIA-2 that it is not acceptable; at least follow LIA-1! "the operation OP" -> "an operation" lots of places: "op" -> "f"; "OP" -> "op". page 8: item b ---------------------------on maximum error requirements---------------------- First, let's rewrite your specification for max error parameters so it looks more like the way in which the corresponding requirement is written in LIA-1: |f(x,...) - op(x,...)| <= max_err_"op" * (r^(exponent_F(op(x,...))-p)) Let's compare this with the LIA-1 requirement: |x - rnd_F(x)| <= rnd_error * (r^(e_F(rnd_F(x))-p)) Firstly, I had expected the use of e_F (a helper function in LIA-1) also in the LIA-2 requirement rather than exponent_F: |f(x,...) op_F(x,...)| <= max_err_op_F * (r^(e_F(op(x,...))-p)) This formulation handles subnormal results properly, which the current LIA-2 formulation does not. But in LIA-1 the rounding function that occurs in that formula is also required to be just that, a rounding function. Except for certain boundaries, this requirement would then be equivalent to: |x rnd_F(x)| <= rnd_error * (r^(e_F(x)-p)) And indeed, as far as I can see, this is what actually was intended for LIA-1. Currently in LIA-1, an rnd_error of 0.5 does not imply round-to-nearest. (I am disregarding the rnd_style parameter for this argument.) Currently in LIA-1, an rnd_error of 0.5 allows values just a bit closer to zero than an exponent boundary to be protracted (rounded away from zero), even if that is not the nearest representable value. What a strange thing to allow... (An rnd_style of "nearest" disallows it; I would be very surprised if there has been in actual practice any floating point system which has an rnd_error of 0.5, but which does not round to nearest!) But using the last version above, an rnd_error of 0.5 (together with the requirement that elements of F are not altered by the rounding, as above too) does imply round-to-nearest (but is still unspec. at ties). LIA-1 has requirements that are not carried over to LIA-2, e.g. that elements of F are unaffected by the rounding. (Those requirements *should* be carried over to the non-transcendental floating point operations of LIA-2; but they should probably *not* be carried over to the transcendental operations of LIA-2.) Since those requirements are not carried over to LIA-2 (for transcendental operations) it is all the more important that the maximum error conditions are correctly formulated. So, secondly, I think LIA-2 should use an error bound requirement corresponding to the *corrected* LIA-1 requirement. So this is the corrected LIA-2 error bound requirement, using "f" instead of "op" in the argument to e_F: |f(x,...) op_F(x,...)| <= max_err_op_F * (r^(e_F(f(x,...))-p)) This change affects the error bound requirements at the "exponent boundaries", But I think this last version is what is actually expected. I have no idea how difficult or easy it is to implement operations that fulfill such an altered accuracy requirement... (Note: "f" refers to a mathematical function, "op" refers to an operation that computes approximations to the results of f.) Thirdly, the accuracy requirement cannot refer to the operations, which may underflow or overflow, but must refer to the rounding of the approximating helper function: |f(x,...) rnd_F(f*_F(x,...))| <= max_err_op_F * r^(e_F(f(x,...)-p)) where f*_F is the approximation helper function to f, and op_F is the corresponding numerical operation. (E.g. f could be tan, f*_F could be tan*_F, and op_F could be tan^r_F.) [fix rnd_F to nearest_F...] page 9: point c-d: specify each parameter explicitly instead (later on): E.g., for exp_F: "max_err_exp_F mem [0.5, 1.5*rnd_err_F]". Just define the concept of a maximum error parameter so far. (This renders "error_limit_op" stuff superfluous.) 5.3: second para: principal ranges should be spec. in section 4 instead. 5.3: third para: "An axiom shall hold...........": How does that affect "axioms" like "ln(fminN) <= ...... <= ln(fmax)", where ln(fminN), etc., are not in F? (This paragraph makes explicit one of the greatest weaknesses of the current draft even for the cases indicated in the note.) 5.3: Last para: "Axioms shall ......": Please ALWAYS use side conditions to indicate when "axioms", "definitions", etc. apply! page 10: 5.6, last para: "of integer" -> "of an integer" 6: third para: x^2 never overflows, but mul_F(x,x) may overflow. The exact result of sqrt(x^2+y^2) may not be representable in F, so it cannot always be calculated as a value in F. (One may, however, calculate an *approximation* in F.) The entire paragraph needs to be slightly reformulated to avoid these technical mistakes. fourth para: "+-", expand. second last para: "+-", expand; "fmin" -> "fminN" page 11: last para: the continuation value on an "angle_too_big" should not be a NaN. page 12: point e: there should be only one "max_angle" parameter, or at most two: one for radians and one for "unit args". I see no point whatsoever in having lots of such parameters, and certainly not parametrise them. page 13, etc.: So now we have THREE specification styles: the LIA-1 style, the LIA-2 modified original style (now with if-then-else) and the LIA-2 table style. I am not at all fond of this proliferation of specification styles! You have (for no reason at all) started to use a different style in LIA-2 than in LIA-1, and now you add if-then-else and tables. And this is done despite the fact that the LIA-1 style is both clearer, more stringent, has much fewer weaknesses, and is fully adequate for all of the LIA-2 operations! And it is easier to get the specifications correct in the LIA-1 style. All individual operation headings: the names of the operations are in italics, not bold, including the subscript. 8.1, 8.2: The "axiom" parts are superfluous (if you need to say that the mathematical sqrt function has a positive principal value, then say that in section 4). Side conditions are missing in many places. (E.g., square root of any argument is "undefined"!) power_F: isn't power_F(0,y) a pole when y < 0? Why is not, simply, power_F(x,y) = undefined when x < 0 (or x = '-(')? '-0' is missing in the table ("0" -> "'-0',0") power_I: the "axioms" are superfluous, delete them. ln_F (etc.): Does the first "axiom" apply at all? (Which is unclear.) If it does, it may disallow round-to-nearest for certain arguments. So this "axiom" discourages round-to-nearest! There are several such discouraging "axioms", but I have seen **no** *encouragement* of round-to-nearest in the LIA-2 document. "ln(fminN)" -> "ln(fmin)" Cmp. the other logarithm operations. Those "axioms" should be deleted, or at least be made into notes about *approximate* range. ln1p_F: "ln1p_F(1+x) = x if ....." -> "ln1p_F(x) = x if ....." various logar. ops.: e.g., ln_F('+(') is '+(' without any notification, since lim_(x->() (ln(x)) = (. Similarly for the related ops. [Please note the distinction between '+(' and (, without quotes, here!!] 10.3 The operation in current 10.3 is still incompletely and incorrectly specified. An accompaning document has a much more correct version (This comment holds for many operations.) page 19, etc., section 11 intro: second para: "1.0" -> "1" (etc.); Arc minutes (21 600 per revolution) and arc seconds (1 296 000 per revolution) are also common angular units. They should be in T too. third para. (below middle): There are still possible technical problems for very small units, so u has to be a little bit bigger to avoid those: u >= r^(emin+p1). fourth para: this para. does NOT give an accurate account for why the big angle parameter and angle_too_big notification are (still) there. They are there since for large angular values the neighborhood of floating point values gets sparse. Both the normative text and the rationale should reflect that motivation. Rename "arg_too_big" to "angle_too_big" (since it only refers to angles) throughout the document. Rename the "max_arg" parameter(s) to "big_angle" (since it is not maximal, and it refers only to angles) throughout the document. There should be only one (or at most two) "big_angle" parameter(s). The value of the big_angle parameter(s) should be defined by LIA-2. angle_too_big notifications should be handled via recording of indicators, unless there is an explicit request to do otherwise. fifth para: I think it is overkill to make (some of) the big_angle parameters into functions. It suffices to divide the arg. with the unit. page 20, etc., section 11 ops: Top of unit arg. trig. op. spec. spec. says "...u mem F", further down it says "If n nonmem F...". u can't both be in F and not in F (the "top line" decl. covers the "extensions" too). So, all of the "extensions" parts/components are also incomplete for the unit arg. trig. ops. You need to have at least *two* maximum error parameters referring to each of the unit arg. trig.: one error parameter for units in T and another for units that are not in T. On the other hand the first one of these two parameters should be the same parameter as for the corresponding radians operation. current sect. 11.1, second "axiom": try to find a wider interval within which the argument is also the most accurate representable result. (cmp. sect. 9.2) [The same goes for current sect. 11.5 (and remove spurious end paren.). Similarly for 11.3 (missing) and 11.9 (make wider): try to find a (wider) interval in which 1 is the most accurate representable result. Similarly for 11.4 (make wider) and 11.10 (make wider). (Compare accompaning document on suggested LIA-2 sections, where the asked for requirements are included.) 11.3, 11.5, 11.9: see comment for 11.1 above. 11.6: ... == ... (mod ...): this notation is not used elsewhere in the current LIA-2 document. Either define it and use it for all of the periodic ops., or for none of them. current 11.13: The signatures for the degree operations are missing. Please use the an equality to specify them. page 26, etc., section 12: The principle value ranges should be given in section 4 (for math. functions). "Principal value" for the *numerical* functions does not make sense. The mathematical inverse of certain elementary mathematical functions (trig. functions in particular) are relations but not functions. So a principal value (result) is chosen for these relations so as to make them functions. These functions can then be approximated numerically. But, alluding to some "principal value" for an approximate numerical function is incorrect. Say that since the operations are approximate, the results of the inverse operations need not be (and *cannot* be required to be) such that these operations are the inverses of the corresponding "forward" operations. Such requirements are in general in principle impossible for floating point approximations of these functions. The requirement for the unit u here should conside with the requirements for the unit in the "forwards" trig. ops.: u >= r^(emin+p1). Interval-of-results requirements (e.g. -u/4 <= ... <= u/4, -pi/2 <= ... <= pi/2): These do not allow rounding results to nearest representable value (and thus discourage round-to-nearest). Rounding to nearest must be allowed and encouraged! unit argument inverse trig. ops.: Top of spec. says "...u mem F", further down it says "If u nonmem F...". u can't both be in F and not in F. (The top line decl. covers the "extentions" too.) All of the "extensions" parts/components/... are incomplete for these and many other operations. You need to have at least *two* maximum error parameters referring to each of the unit arg. inv. trig.: one error parameter for units in T and another for units that are not in T. On the other hand the first one of these two parameters should be the same parameter as for the corresponding radians operation. current sect. 12.1, second "axiom": try to find a wider interval within which the argument is also the most accurate representable result. (cmp. sect. 9.2 and 11.1, etc.) The same goes for current sect. 12.5. the arc/angle/phase operations: 1. join the "arctan2" and "arccot2" operations, 2. rename them to the "arc" operations [calling them the "angle" operations would be fine too]. 3. These operations should have their own section (between "trigonometric operations" and "inverse trigonometric operations"). the arctan^?_F and arccot^?_F operations: 1. the arccot^?_F operations now (again) has a jump at zero. Since some wants the non-jump version (like Ada) and some wants the "jump" version (like Abramowitz and Stegun), I think it is best for LIA-2 not to take a stand on that issue but specify *both* of them. 2. These operations may underflow, a possibility which the current spec. incorrectly do not mention. 12.1,12.5,12.9: radian operations that may underflow, but which you have missed. 12.2,12.4,12.6,12.10,12.14,12.16: unit arg. operations that definitely may underflow, but which you have missed. 12.7: 1. Please define the mathematical angle/arc function like this (which does not involve sign_F (an operation), which is not defined for all of R; and it is a much more elegant definition): angle : R x R -> R angle(x,y) = arccos(x/sqrt(x^2+y^2)) if y >=0 = -arccos(x/sqrt(x^2+y^2)) if y < 0 2. the results in the table are not in F and are thus not required at all (not even approximately)! (cmp. sect. 5.3.) 3. Your underflow criterion is incorrect (x must be positive for underflow to occur, but the sign of y does not matter for this); 4. As I have said before, I do not like this proliferation of specifications styles, the LIA-1 style is fully adequate, even here 12.8: 1. the results in the table might not be in F and are then not required at all! (not even approximately, cmp. sect. 5.3.); 2. Your underflow criterion is incorrect (x must be pos., but sign of y does not matter). 4. The spec. is incomplete. 12.17: The signatures for the degree operations are missing. Please use the an equality to specify them: arcsin360_F(x) = arcsin^u_F(360,x). All of trig./inv.trig. ops: please break out the angle/arc ops to their own (sub) section trig. ops. arc/angle ops. inv. trig. ops. please do NOT interleave the radians and the unit arg. ops: first: the radians ops. second: the unit arg. ops. third: the degree ops. I find the way they are interleaved now to be VERY confusing, and I often look at the wrong variant for a while! page 33, etc., section 13: current 13.1,13.3,14.1,14.3: these operations may underflow (for subnormal, non-zero input). For these operations one should specify interval(s) (around zero) for which the input is also the most accurate output (cmp. some trig. ops.). (That is, for arguments in the spec. interval the argument value must be returned as result.) current 13.2,13.5: For these operations one should specify intervals (around zero) for which 1 is the most accurate output (cmp some other trig. ops.). current 13.3,13.4: For these operations one should specify intervals ("far" away from zero) for which 1 is the most accurate output. (The sign req. takes care of the negative case.) current 13.4: This operation, coth_F, may overflow (for subnormal, non-zero input) current 13.6: csch_F('-inf') = '-0' current 14.1: the sign requirement is missing The <= ln(2*fmax) requirement may disallow round to nearest for some arguments, and thus discourages round-to-nearest, which should be allowed and encouraged. current 14.2: the smallest result for arccosh_F is 0 (not 1) arccosh_F is undefined for all input less than 1 (no abs) the <= ln(2*fmax) requirement may disallow round to nearest for some arguments, and thus discourages round-to-nearest, which should be allowed and encouraged current 14.4: this operation may underflow current 14.5: arcsech_F('-0') = pole('+inf') (not undefined, cmp sqrt op. and note 2 on p. 4) current 14.6: arccsch_F may underflow also for negative arguments. arccsch_F('-inf') = '-0' section 15,16 (page 37 ff): current 15.1,15.2,15.3: these operations are not undefined for any argument in F, so undefined should not be in the signatures for these operations. current 15.4: This operation has no computational raison d'tre, and should be deleted. current 15.5,15.6,15.7: these operations are not conversions (only one data type involved), so they should not be classified as conversions! current 15.8: This operation has no computational raison d'tre, and should be deleted. current 15.9-15.11: 1. For arguments in F their specification is more properly done like in LIA-1 (examplified with the operation currently in 15.9): cvt^down_F_a->F_b(x) = result_F_b(x, down_F_b) 2. Note that all of these operations *may* result in underflow (depending on which two floating point types are involved and the value of the argument). So the proper signatures are like this (examplified with the operation currently in 15.9): cvt^down_F_a->F_b : F_a -> F_b union {underflow, floating_overflow} The current specification is in error and is incomplete in this regard, and it cannot be made correct using the current specification style. (The semantics given above precisely describe when underflow occurs.) 3. The special values '0', '+(', '(' need not be in the type corresponding to F_b (the target type) even if they are in the type corresponding to F_a. In such cases the current "extensions" "component"s do not properly specify the semantics of the conversion of such arguments. current 15.11: The continuation values for overflow here are inconsistent with IEC559 requirements for rounding to nearest conversion (infinities cont. values). Overflow cond. on ties may be inconsistent with IEC559 requirements. current 15.12: This operation has no computational raison d'tre, and should be deleted. current section parts intro.-16,16.1,16.2: these section parts should be tightly joined with the operations in current section 15. There is no reason for such a strong separation of these operations from the ones in current section 15. (Details of this suggestion are in the accompaning document on suggested LIA-2 sections.) section 17 (page 44 ff): 17.1--17.4: The max and min operations on sequences: for some obscure reason the sequence versions of the max and min operations have been included, but no other operations on sequences. This is far too arbitrary to be acceptable. Either exclude all operations on sequences or include "all" primitive binary arithmetic operations generalised to sequences. *If* you include "all" primitive binary arithmetic operations generalised to sequences, then they should be correctly specified, of course. The current specifications for the max and min operations on sequences are however both very incorrect and very incomplete. 17.5--17.8: The "axioms" are superfluous and should be deleted. section 18 (page 46 ff): title, intro: These operations are useful also for implementing "more than doubled" precision. The error limits for the sub_lo_F and add_lo_F operations are strange: If rounding is to nearest, then the result for the sub_lo_F and add_lo_F operations can be exact, and no error should be allowed. This should be a stated requirement! As it is stated now, inexact results are allowed even if rounding is to nearest (for add_F and sub_F). (The note is not normative, so it is insufficient.) The current specifications are incomplete. Better specifications for add_lo and sub_lo are found the the accompaning document on suggested LIA-2 sections. page 48: mul_lo_F: This operation will usually not return an exact result when the result is subnormal (the current "exceptions" portion says that it is). The "extensions" portion is incomplete. rem_div_F: The "extensions" portion is incomplete, and incorrect (the first one does not exclude zero divisors). I don't think this operation usually returns an exact result when the result is subnormal. rem_sqrt_F: This operation can underflow for certain arguments. "sumhi" and "sumlo" are strange operations and must be replaced entirely (with add3_F and add3_mid_F). "dprod_F->G" (better named mul_F->F'): It would be easier to allow this operation to be defined for *any* two (different; but provided) floating point types (even though only a few combinations will actually be provided). For some operands '+(' (etc.) is returned. But even if those values are in the source type, they might not be in the target type. The "extensions" portion is incomplete. mul_add_F: The overflow and underflow conditions are not what result_F would give. (The limits are different and if iec_559 is true, mul_add_F(fminN_F, 1, -fminD_F), e.g., should not underflow, only return an exact subnormal result.) The "extensions" portion is incomplete and does not always handle IEC 559 values in a way that would be consistent with IEC 559 multiplication and addition. hypot_F: This operations may underflow for certain (subnormal) arguments. The "extensions" portion is incomplete. dim_F: The subnormal/underflow part might not always be what using result_F would have given. This complicates implementations, since "if x=1" is superfluous, please delete. The "," should be an explicit "and". The side condition "if x/=0 or y/=0" should be written out explicitly. lcm_I: The ","s should be an explicit "and"s. I don't think a continuation value should be spec. for overflow here. page 53, ff, Rationale: First paragraph: "Many...." That sentence is not true (yet). A.1 (Scope): "his": please replace with "their", or even better, reformulate to remove the pronouns entirely. "standardization" -> standardisation". A.2-A.4 It looks a bit strange not having any text under some headings. A.4.1, first para: The "sequence" types are only used by operations that should be deleted from LIA-2. second para: the conversion operation referred to is no longer in LIA-2. A.5.1, second para: Bad idea, please delete both paragraph and idea. A.5.2, first para: nobody has ever (as far as I know) asked for any such specifications. The example is not even well formed, since y*log_F(x) need not be in F even if x and y are in F. second para: this "error formula" does not cover subnormal results properly, nor do I think it is the correct one otherwise, cmp. LIA-1, correct and adapt that. See above. A.5.3: "may exist" -> "are" A.5.6.2: "+-inf" -> "'+inf' or '-inf'" page 58 top, item b and item c: these are not properly formulated, mathematical infinities and IEC559 infinities have been confused, and '-0' is treated inappropriately. last sentence of A.5.6.4: italic font for "x". add: ", unless the function is undefined via that approach, in which case the result for '0' is the same as for 0". A.5.7: Exact mathematical expressions (2^x and 10^x) are confused with approximate operations. exp_F(x*ln(2)) is not a properly formulated specification: x*ln(2) is rarely in F even if x is in F. A.8, second para: "I" has no "p" parameter. The reasoning given is appropriate for sqrt_F though. A slightly different reasoning must be used for sqrt_I. A.8.3, only sentence: Really?? In any significant way? Or is that not even always the case? A.9, second para: Exact mathematical expressions (x^y and 0^0; where the latter has no conventional definition) are confused with approximate operations. A.9.1: "+-inf" -> "'+inf' or '-inf'" A.9.3: An exact mathematical expression (x^y) is confused with an approximate operation. power_F('-inf',y) should be invalid, and power_F('-0',y) = power_F(0,y). A.9.3, fourth para: italic font on "k". The statement in that paragraph is true, but sensible values can still be selected for the corresponding operation given IEC559 infinity inputs. E.g., keeping x constant and finding lim(y->inf) x^y will give inf for x > 1, 1 for x=1 and 0 for 0<=x<1. I think that for multi-argument operations the results for IEC559 infinities should be as by limiting one argument at the time, keeping the others constant (e.g. the path y=k/ln(x) is not considered). For the two-arg. operations where both of the arguments can be infinite, one should consider the double limit, if unique. E.g., lim(x->inf),(y->inf) (x^y). (This is apparently done, but not explicitly said in the rationale.) A.9.3, fifth para: "The identity" power_F(x,y) = r^(y*log_r(x)) is NOT a true identity. You mean the identity x^y = r^(y*log_r(x)). Is r supposedly arbitrary or do you really mean the radix parameter r? Change the name if "r" is supposedly arbitrary here. A.9.5: Delete the last sentence! Heeding it would loose accuracy and is not acceptable. A11, second para: "size" -> "magnitude". Delete "a quarter or" (would not be accurate enough in the radians case; but depends upon exactly what is meant: quadrants or offset from axis). "For a large argument..." to end of paragraph: delete since it is false (cmp IEC559 rem: always exact). third para: "some implementations use an approximate value of pi"? I would guess that *very few* implementations use an *exact* value for pi! fourth para: Make a clearer distinction between the radians case (necessarily approximate argument reduction) and the unit argument case (always exact argument reduction). fifth para: "sin" -> "sec" sixth para: "two" -> "unit" seventh para: "SIN" (etc.)? The radians versions or the unit argument versions or both? eight para ("For a..."): 1. True, but that does not mean that the result is exact (except for x=0),so "underflow" is still appropriate, even if the inexactness is very tiny. 2. One should try to find wider limits, expressed in terms of p and r, for which this holds. nineth para, last sentence ("However, ...): That *may* be so, but don't say it anyway. If you have to say anything like that, formulate it with the *opposite emphasis*: "The angular units in T appear to be particularly important, and have therefore been given a tighter error bound requirement. An implementation can of course have the same (tighter) error bound for all angular units." A.11.6: italic font on u (twice). A.11.7: "are +-inf" -> "is '+inf' and '-inf' (respectively)" "arguments of +-0, respectively" -> "an argument of 0 or '-0'" A.11.9: sec(x), italic font "they" -> "such arguments" A.11.11: "are +-inf" -> "is '+inf' and '-inf' (respectively)" "+-0, respetively" -> "0 or '-0'" A.11.13: "Both accuracy and": No, LIA-2 should NOT allow different results for the degree variant and the unit arg. variant given the unit 360. A.12: "The undefined notification is the only one..." -> "The undefined and underflow notifications are the only notifications..." A.12.7, second para: "the value 1" -> "the value 0" "arctan2(y,x)": arctan2? No such mathematical function has been defined in LIA-2. "by the point (x,y) as it approaches" -> "to approach" "of +-inf" -> "'+inf' and '-inf' table: the results listed in the table cannot be returned by the operation that you call "ARCTAN2", since those values are not in F. "b": italic font. "+-pi/4", "+-3pi/4": expand "+-", insert "*" after the "3"; those values cannot be returned by an operation since they are not in F. A.13.1: add "or greater" to the end of the first sentence. second sentence: not supported by the current normative text. A.14.3, A.14.4: expand "+-". A.15: "a floating point datatype" -> "a single value of a floating point datatype" "integer types and floating point types" -> "another integer type and to a floating point type" A.15.1-A.15.4, A.15.5-A.15.8: Very repetitive and boring. A.15.9-A.15.12: Very repetitive and boring. They are also false, since they try to argue for continuation values that are not the ones in the LIA-2 normative text, nor in IEC559 for the corresponding operations. page 69: There are no such operations as "addhi", "mulhi" and "divhi" (anymore). page 70,71: sumhi, sumlo: (these operations should be replaced...) Rationale contains old spec. for these operations, which is not an adequate storage place. A.20.1: "It can never produce an underflow." False! For most |x|, |y| < fminN it shall underflow. Annex B: Needs updating: some operations have been deleted, and some new ones have been introduced in the normative part but not here. (Annex B should be expanded to an example bindings annex.) Annex C: "International Documents" -> "International Standards Documents" "National and Other Documents" -> "National Standards Documents" "Books and Articles" -> "Books, Articles and Other Documents" [6]: refer to Ada95 instead. [14]: 1994... [24]: "Goldberg" -> "Goldberg,"; "arithmetic" -> "Arithmetic" [25]: "W." -> "W" [26]: "W." -> "W"; "microsystems" -> "Microsystems"? SIDA  SIDA 14  ࡱ; SummaryInformation(Microsoft Word 6.0.115ࡱ; F"# |~y{  j+k+N.O.W.X.........XXXXze{euP uDPXUX^^VJU^c 9FGHIQ YZ34 ,UV^O&f x#x#@x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-  Z D  Z  V A W JQ45ijx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-[PQ&'/#$mnUVVMNx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-Hp9qrgKhiRS4 q, - u !I!!x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-!!!!E"F"""+#e#f#### $!$i$$$0%w%x%%%%%& &r&&'''a''''/(r(s(((<)m)n))x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-)))9******"+#+^+o+r+++++<,,,---.-q----!.".z..//W/////0F0000091x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-91:1112^222222.3p3q3333@444455455546R6S666>77778S8w8x88 9M99999x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-99I:::::::#;$;?;;; <T<<<$=Y=Z===8>>>>>3?4???@*@+@S@@@@@=AYAZAAAJBx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-JBBBB'CoCpCCCCD.D/DbDDDDD&EdEEEFF?FmFnFFF$G@GAGGGH#HYHHHHHHJIIIIx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-I JJeJJJJJJKK]K^KKKKK LL,L?L@L~LLLLMGMHMcMdMMMM NYNNNNNOZO[OtOO Px#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#- PPPuPvPPPPPQbQ|Q}QQQQQARRRRRRRBSCSSSSSSS!TeTfTTT)U[U\UUUU'V_V`Vx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-`VVVV:WWWWWWEXXXX"YvYYYYWZZZZI[J[K[[[B\\\\\\\]c]]^*^+^y^^_8_9_x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-9_{_|______A`B```=aaaa*b+bbbbbbcIclcmccccddad{d|ddd4ecedeeeeffgfx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-gfff g gQgggggg(h)hnhhhGiiiii j>jjjjjjj kTkUkmkkkkllHlIllllllCmLmx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-LmMmmmmnVnWnnnoo,o-oUoVooppp4p|ppppqqVqyqzqqrrwrxrrss:s;sssss t tx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#- t^ttt uOuuu;vvvvv%wuwww"x#xLxMxxxx+yMyNyyyy;zzzzzzzz={E{F{f{{{|Q|x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#-Q|k|l|||}c}}}~~)~*~i~j~~~~~~~)*PQRjk12VW߁x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#->|}klσЃ 78Ȅ56Յօ);<ņL͇·:Mx#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#,x# $%h`%K@Normalac&A@&Standardstycketeckensnitt @ Sidfot p#)@ Sidnummer"@"Sidhuvud p#!!!!!!!!! ! ! ! ! !'1<F}NKXcbVkLu}I.INCX     E !)919JBI P`V9_gfLm tQ|FGHIJKLMNOPQRSTUVWX !!dhmms;0x#-+'"`, ,RKFRF KOMMENTARSKAPADATREDTIDDOKNAMN FILSTORLEK NYCKELORD SENSPARATAVANTALTKNANTALSIDANTALORD UTSKRIFTSDATPRIVATRDVERSIONSPARADATMNEINHODOKMALLTITELXOALFAARABINITVERS GRUNDTEXT TECKENFORM VALUTATEXT FRSTVERSHEXGEMEN KOPPLAFORMORDTALORDTEXTROMANVERSALABSAVRUNDADEFHELTALOCHFALSKTMAXMINRESTMEDELANTALICKEELLERPRODUKTOMTECKENSUMMASANTInst fr Datavetenskap/PowerMac:Anvndare:kentk:Nya nydefs:30nov95.comInst fr Datavetenskap/PowerMac:Anvndare:kentk:Nya nydefs:30nov95.comInst fr Datavetenskap/PowerMac:Anvndare:kentk:Nya nydefs:30nov95.comInst fr Datavetenskap/PowerMac:Anvndare:kentk:Nya nydefs:30nov95.comInst fr Datavetenskap-PowerMac:Temporary Items:Word arbetsfil A 206Inst fr Datavetenskap-PowerMac:Temporary Items:Word arbetsfil A 206Inst fr Datavetenskap-PowerMac:Temporary Items:Word arbetsfil A 206Inst fr Datavetenskap-PowerMac:Temporary Items:Word arbetsfil A 206Inst fr Datavetenskap-PowerMac:Temporary Items:Word arbetsfil A 206Inst fr Datavetenskap/PowerMac:Anvndare:kentk:Nya nydefs:30nov95.com@K=MTimes New Roman Symbol MArial MTimes"1FfGpage 1:Inst fr DatavetenskapInst fr Datavetenskapࡱ;