аЯрЁБс;ўџ ўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ§џџџ,ўџџџ-  !"#$%&'()*+.ўџџџўџџџ/0123456789:;<=>ўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџRџџџџџџџџ РF€\”ž?!Л@CompObjџџџџџџџџџџџџ^WordDocumentџџџџџџџџzpObjectPoolџџџџЦћ?!ЛЦћ?!Лўџџџ ўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџўџџџџџ РFMicrosoft Word 6.0 (dokument)ўџџџNB6WWord.Document.6;џў ўџ ђŸ…рOљhЋ‘+'Гй0„˜ЦЮч   $08 @Li q|џџџџџџџџџџџџџџџџџџџџџџџџ&PowerMac:Microsoft Word:Mallar:NormalSummary: The current LIA-2 draft must be rejected even to become a CD. There are too many errors in the specifications. There arмЅhQРeHzpvE`H`HHeHeHeHeHeТeЄТefififivi’iТeƒnfЎiЎi"аiаiаiаiаiаi[n]n]n]n]n]n]n&щnXAo9ƒnHeak(,аiаiakakƒnakHeHeаiЎiakakakakHeаiHeаi[n\e&‚e@HeHeHeHeаi‘[nakњakResponse to the CD registration ballot on LIA-2 (ISO/IEC WD 10967-2). (submitted to SIS/ITS, 1996а04а03) Summary: The current LIA-2 draft must be rejected even to become a CD. There are too many errors in the specifications. There are also issues concerning the way in which the specifications are currently made. Page-by-page remarks on some of the дsmallerе problems (including many errors) are found in an accompanying document. A completely new set of specifications, where most of the problems have been resolved, is found in another accompanying document (in three parts). Some of the problem issues are discussed below. Symbol and name issues. Mathematical symbols: Conventional mathematical symbols must be used strictly in their conventional mathematical sense. It is important for the readers of the document that it does not to try to use conventional notation for something, even slightly, unconventional. In order not to confuse readers, please observe the following: а0 is the mathematical negation of 0 which is identically 0 (no matter what any side remark might say). Even saying that the notation а0 is used for the IEC 559 negative zero, makes it unclear what аx means when x is 0. Are you really redefining the mathematical negation? Floor and ceiling brackets must be used only in their conventional meaning (two functions from R to Z), not in any extended meaning. The extended meaning attempted in the current LIA-2 text is very unconventional. Nor does the current extension work well (syntactically) with the proper and correct way of specifying the operations which currently are using the extended floor and ceiling brackets. The (unquoted) infinity symbol should be used only for the mathematical infinities. IEC 559 special values: These must be clearly distinguished from conventional mathematical values, for the benefit of the readers of the document. The current side remark is completely insufficient and inaccurate. Use quotes to distinguish them: да0е, д+(е, да(е. "max_arg" ( "big_angle"; "arg_too_big" ( "angle_too_big" The names "big_angle" and "angle_too_big" are better names; the entities so named are about angles, not just any argument. It has been argued that the name "arg_too_big" is used just to avoid a proliferation of notification names. E.g. "arg_too_big" could be used for set operations when attempting too create a too big set. Firstly this is completely unrelated to arithmetic. Secondly it would be much more urgent to join integer_overflow and floating_overflow, than to join angle_too_big with something wildly unrelated. Names of operations: Please use lower case names (as in LIA-1). Definitely abolish the very strange notation of repeating the "F" index; instead write each type of the signature just once in the name of the operation (as in LIA-1); use, e.g., superscripts to distinguish variants of "sin" operations etc. For a complete list of suggested names, see the accompanying documents on suggested LIA-2 sections. I think it is better for the readers of LIA-2 to use the same operation naming scheme as in LIA-1, since the set of readers of LIA-2 will largely coincide with (or be a subset of) the set of readers of LIA-1. I see no reason to change operation naming scheme between the parts. (In the unlikely event that the set of readers do not largely coinside, what would be the harm of using the LIA-1 naming style? None!) Some of the operations must be renamed, since their current names are misleading. See point 5.c below. "G": Please do not use "G" as a meta-variable for a floating point type. LIA uses "F", and indexed varieties of "F" as meta-variables for floating point types. Document structure issues. Heading structure: For the benefit of the readers, which will also be reading the LIA-1 document, keep the structure of the LIA-2 document close to the structure of the LIA-1 document. I see no reason for having a radically different document structure in LIA-2 compared to LIA-1. (In the unlikely event that the set of readers do not largely coincide, what would be the harm of using the LIA-1 structure? None!) The operations should be detailed in subsections of section 5 (compare LIA-1 numbering) "Elementary numerical functions". The subsections of section 5 then add operations to the corresponding section of LIA-1, even if the numbering of the subsections cannot (in a good way) be exactly aligned. There must be no "miscellaneous" subsection (its presence indicates that there is something wrong with the current structure). For a detailed proposal of i-iv, see the accompanying documents on suggested LIA-2 sections. Collect all pure integer operations (sqrtI, oddI, dimI, etc.) to one section (sect. 5.1). It is very disruptive to have them spread out like they are now. Collect all conversion operations, including the "external" conversions to one section (sect. 5.4). Collect all non-transcendental floating point operations (except conversions) to one section (sect. 5.2). It is very disruptive to have them spread out like they are now. Let all operations for transcendental operations get a collective heading (sect. 5.3), essentially with the same subgrouping as they have already. But: let the inverse hyperbolic operations get their own heading (just like the inverse trig. operations); let the arc/angle/phase operations (currently referred to as "arctan2" and "arccot2") get their own heading; add a subsection for angle normalisation and conversion operations, which should be covered by LIA-2, I think users may justifiably want to be able to reliably convert between different angle units as well as explicitly normalise angles. For the trigonometric and inverse trigonometric operations: keep the radian operations together, and the "unit argument" operations together, please do not interleave them as they are now. I think it is easier for the reader to concentrate on the radians and "unit argument" varieties separately. The "notification" section should be placed as in LIA-1 (section 6 in LIA-1). There should be a section on relationship with language standards; section 7 (compare LIA-1). The "documentation requirements" section should be placed as in LIA-1 (section 8 in LIA-1). Semantic style and notational style issues. "Assembly instruction manual page" style vs. "LIA-1 definitions" style: I think it is much better for the readers of LIA-2 to use the same notational style as in LIA-1, especially for operations might as well have been in LIA-1. So, I think that the LIA-1 notation for specifications must be used for the following groups of operations. integer operations, conversions, and non-transcendental floating point operations. The same notation can be used also for the transcendental operations. The LIA-1 notation is less complex and clearer than the current notation, as well as less error prone and sometimes shorter (it is never longer, except where cases are missing in the current specifications). It is possible to apply the monotonicity and accuracy requirements prior to overflow and underflow detection when using the LIA-1 notation and LIA-1 semantic style, which is not possible using the current LIA-2 notational/semantic style. The underflow/overflow detection is done on the гcomputed resultг, not on (an inverse of) the mathematical result. Using the LIA-1 notational/semantic style it is possible to collect common semantics in helper functions, reducing repetition, enhancing a uniform policy for the semantics of the operations. Underflow and overflow checks: These should be exactly as in LIA-1, except that a simplification is warranted for the transcendetal operations. There is no reason to do this very differently in LIA-2, and I think that any very different policy might be difficult to actually implement. For the non-transcendental operations this is best handled by using resultF from LIA-1. For the transcendental operations, a simplified version, trans_resultF should be used. Continuation value for underflow: The continuation value on underflow should be a sufficiently accurate subnormal (= denormal or zero) value, when denormal values are available (denormF=true), which they should be. This is currently completely unspecified in LIA-2. For the non-transcendental operations this is best handled by using resultF from LIA-1. For the transcendental operations, a simplified version, trans_resultF should be used. Missing cases in the specifications: There are still many cases missing in the current specifications for IEC 559 special values for many operations with two or three f.p. arguments. Complete specifications are found in documents accompanying this one. Argument order: One should use an argument order that is consistent with conventional mathematical notation, or what would be such notation. That is, for logarithm operations which have an explicit base argument, the base argument should come first; for trigonometric operations with unit argument, the unit argument should be first. (No matter what order any particular programming language uses. Most programming languages have/would have such arguments in the order I suggest anyway.) Accuracy issues. Rounding of ties: Rounding operations that round to nearest and explicitly return an integer value must round ties to an even integer. The current sloppiness makes the currently specified rounding operations too unreliable. Arguments for which higher accuracy should be required: I think there are more arguments for which exact (or at worst rounded with nearestF) results are expected. Currently LIA-2 relinquishes all requirements on results like u/4, when u/4 is not exactly representable in F. Ada still has such higher accuracy requirements, even when the result (e.g. u/4) is not in F. Ada says the following (in section 11 of 11430:1994): "when a prescribed result is not a safe number of FLOAT_TYPE (like ( or CYCLE/4.0 for certain values of CYCLE), an implementation may deliver any value in the surrounding safe interval". I assume that this principle also should apply to arguments that are not exactly representable in F. I have tried to express such requirements (both concerning arguments and results) in a more precise manner in the accompanying document on suggested LIA-2 section 5.3. Requirements such as "sinu*F(u, u/12) = 1/2" puts requirements on representable values close to u/12 even if u/12 is not in F. Via the monotonicity requirement, we then have that for u > 0, sinuF(u,upF(u/12)) ( 1/2, and sinuF(u,downF(u/12)) ( 1/2, something which all users of trigonometric operations will expect, but is not currently required by LIA-2 (nor by Ada, as yet), but should be. Operation set issues. Operations to remove: max and min with more than two args: It is unclear what is actually referred to: list arguments, array arguments, or a syntactic sugar variety (variable number of arguments). We have not included list summation operations, for instance, in LIA, why should the list max/min operations be included? (The Fortran max/min is alredy covered by the two arg. ops.) ALL explicit truncation operations. These operations have no computational purpose, and should under no circumstances be perpetuated. The implicit truncation allowed via rndF should be kept only as long as LIA-1 allows rndF to do truncation. Operations to replace: sumhi and sumlo: These operations have strange conditions for use. add3I and add3_midI are intended to replace the strange operations sumhi and sumlo. Those operations have strange conditions for use, and incomplete specifications. add3I and add3_midI are intended to clean that up. (For semantics: see the accompanying document on suggested LIA-2 section 5.2.) Some operations to rename (apart from subscript repetitions and upper case to lower case letters): mul_wrapI and mul_ovI are called mulloI and mulhiI respectively in the current LIA-2 text, but those names are confusing since these operations are not sufficiently closely related to the floating point operations of the same names. The arc/angle/phase operations are sometimes referred to as "arccot2" or "arctan2" (with the co-ordinate arguments swapped). Since the mathematical definition is in terms arccos, names that refer to the tangent seem inappropriate. I prefer the name arc. Conversion operations should be called something with "cvt" or гconvertг. Compare with the names of conversions in LIA-1. (For a complete proposal see the messages on suggested LIA-2 sections.) In order not to confuse "remainder after integer division" with the "remainders" after square root and floating point division, I suggest calling the latter "rests" rather than "remainders". So "rem_div_F" should be called "div_restF" or "rest_divF", and similarly: "sqrt_restF" (or "rest_sqrtF"). Some operations to add: Variations of integer div and rem (see the accompanying suggested section 5.1 for details): The integer division and remainder operations using a to nearest or a towards plus infinity rounding are provided by Common Lisp (as two results of the two-argument versions of "round" and "ceiling"). The round to nearest integer division provides the common integer division with unbiased rounding. The round towards positive infinity integer division provides for conventional grouping into equal sized groups (except for the last one). idiv and irem (see the accompanying suggested section 5.2 for details): The idiv and irem operations are provided by Common Lisp as the floating point versions of the two-argument/two-result versions of floor/round/ceiling. These provide the floating point versions of the integer division and remainder operations. They are useful for cyclic functions. E.g., exact angle reduction (to within a cycle close to zero) for (f.p.) unit angles (i.e. angle units that can be expressed exactly as a f.p. number). The "revolution number" is obtained as the idiv result, as long as that integer number is in F (otherwise a "rounded" result is obtained). Wrapping add and subtract (see the accompanying suggested section 5.1 for details): Due to pressure to include "wrapping" arithmetic operation in LIA-1, LIA-1 adopted a "modulo" parameter. However, that seems to be a bad idea. Ordinary add (etc.) should overflow when the true result cannot be represented as a value in the integer type. In order to cater for the demand for "wrapping" integer operations, I suggest instead to add special operations to do that even in well-designed languages, where "moduloI" is required to be false. I see no point in including any "wrapping" integer division operations, since integer division hardly ever overflows (only occasion: minint divided by а1 when minint=аmaxintа1). Modulo argument add subtract and multiply (see the accompanying suggested section 5.1 for details): One should also consider addition, subtraction and multiplication modulo a given argument. Equal and negate modulo argument: The operations equal and negate on "modulo(x)" (see LID section 10.1.2) should also be easily available (if they are important enough for LID, they should be important enough for LIA). Divides predicate operation: A divides predicate is used in mathematics when divisibility is to be easily expressed. C/C++ has this one already. Angle normalisation and conversion operations (see the accompanying suggested section 5.3 for details): These operations should be provided for accurate angle normalisation and conversion that the users may wish to do. (Except for one, they are not intended to be helper functions, but operations that programmers may use.) Primitive arithmetic operations that support interval arithmetic to the same extent as IEC 559 does, but as separate operations rather than гmodesг. Primitive arithmetic operations that support an extended f.p. range. Parameters issues. Accuracy parameters: Mention each one of them explicitly. Trigonometric normalisation parameters ("max_arg", or better "big_angle"): There should be just one such parameter, or at most two. I see no reason at all for having one for each trig. operation. Conversion operations issues. External forms conversions: Treat all conversions in the same manner, whether both types involved in the conversion conform to LIA-1 or not; whether both types are visible to the programmer or not. That makes it easier for the reader, it is more consistent than the current approach. Truncating operations: Just to emphasise, I repeat: These operations have no computational purpose, and should under no circumstances be perpetuated. Please delete all of them from LIA-2. The implicit truncation allowed via rndF should be kept only as long as LIA-1 allows rndF to do truncation. Conformity clause (section 2). There is no reason for having a conformity clause that differs more than absolutely necessary from the one used in LIA-1: Take paragraph 1 from clause 2 of LIA-1, deleting "abstract data types and". Take paragraph 2 from clause 2 of LIA-1 verbatim. Take paragraph 3 from clause 2 of LIA-1, replacing "data types" with "operations" (two occ.). Take note 1 from clause 2 of LIA-1 verbatim. Take paragraph 4 from clause 2 of LIA-1, replacing "arithmetic types"/"types" with "operations" (two occ.). Take paragraph 5 from clause 2 of LIA-1 verbatim. And nothing else. Current section 2.1 (Conformity to the whole) is malplaced in a language independent standard that is not very well delineated (and LIA is not). I cannot see how to reasonably apply 2.1 in practice, given that "computer arithmetic" is not a sharply delineated area. I can see how a 2.1-like requirement could be applied to, say, operations for a very rigorously defined protocol. But for "computer arithmetic", the delineation is much too fuzzy. SIDA  SIDA 6 ™ Єg.Ѕ AІŠЇŠЈŠЉŠъ HH28џєџѓ>FG{рHH dџ'hv@ copyџџ@дfeedџџ@vfpanџџ@тnmapџџ@$pmapџџ@8qualџџ@rangџџ@|smapџџ@*sortџџ@мtmapџџ@0BestNormalDraft!!: US Letter@ї™ЈџюџюRsyptPtTџџџD А""ќНЮА"ќ­  A4 Letter0 џяџь0 џяџьA4@baseџџ@creaџџ@ flagџџ@unitџџ@SWIIЎР@dirmџџ@ layoџџ@scalџџ@$ dd A4 Letter0 џяџь0 џяџьA4@baseџџ@creaџџ@ flagџџ@unitџџ@SWII­Р@dirmџџ@ layoџџ@scalџџ@ф ddrastSWIIStyleWriter GXrastSWIIStyleWriter GXStyleWriter GXаЯрЁБс;џў џџџўџџџџџџџџџџџџџџџџџџџџџFjqаЯрЁБс;џў џџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџаЯрЁБс;џў џџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџSummaryInformation(џџџџџџџџџџџџДџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџe also issues concerning the way in which the specifications are currently made. Page-by-page remarks on some of the дsmalleGšran SchumacherInst fšr Datavetenskap'@фЗю— Л@ОLn?!Л@’?!Л@Microsoft Word 6.0.114џў џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџFjq“›В5z’ЈHKPQUVY\    А Д ж ю ж з м н р ъ ы    ( = ЧЬƒ–KOPRUVX[\ШЫиj ‰ Э!г!д!"'"("9"["ы"ё"ђ"ѓ"ї"ˆ#Ž##ж#т#у#є#$њіёіщіфіфіттптптптптптптптпттктктззттттпгтпгтпгтптттпгтпгттпгтатпгтпгтUa Va hJЎJЅa Va a ^a cUVZ^a cUa ca c U^a c R$ѓ$%я&'D'K'R'V'а'(S(Z([(Б(В(Л(М(п(р(/)0)>)?)Л)М)•*–*W+[+\+]+^+_+a+b+Ё+Ђ+Ў+Џ+Н+О+љ+њ+,,,,,,, , , , ,,,,!,",#,$,%,&,*,+,,,-,3,4,п,ѕ,ј,§,-У.г. / / /:/=/>/Q/h/m/r/w/Ќ/А/Б/§§§њ§њ§§њі§њ§њ§њ§њ§њ§ё§њ§њ§і§њ§њ§њ§њ§њ§њ§њэі§њ§њі§њ§ш§њэі§њ§њі§њ§у§њ§њ§њ§њі§њі§њ§њ§њіJЃa JГa Va hJpa Va hVa a ZБ/Ж/О/П/я/є/љ/ў/T0X0Y0^0f0g0з0:1B1C1H1N1O1[1`1a1f1k1l1!3$3Ь4д4е4л4у4ф4ї4555555.5C7G7L7P77“7˜7œ7Ч;Э;Ю;т;ч;‹<‘<“<™<џ@A9A„A™AœAB8B9CPCЎCОCDDDKDNDODG#GvHwH}H~HHH‚HˆH‰HŠH‹HŒHHH§њі§њ§њ§њі§њі§њі§њі§њі§њі§њ§њі§њі§њі§њі§§њ§њ§њ§њ§њі§ѓ§њ§њ§§§њ§§§њ§њі§њі§њ§эыэыэыэыэы§P uDPUa Va hVa a ]HNўuFijyz’Јоё‚ ж ю р  ( = П_ЧЬhƒ–#JЩ&Т'гmдB0ZњP#hѕP#ѕP#ё P#ёP#яP#эP#№ыP#мщP#мщP#мщP#мэP#№ыџP# эP#ыP#мэP#№ыP#мчP#мчP#мэP#№ыP#мяP#эP#№ыP#мчP#мчP#мчP#мщP#мщP#мщP#мщP#мЦP#мЦP#мЦP#мЦP#м 3хў 4џЗŒЊ#ZЉdиuсѕ4zJ8Ћj ‰ ‰!9"["D#є#$ѓ$%о&я&'а'(s(x)3*˜*Щ,п,ѕ,ўP#мўP#мўP#мќP#њP#№јP#міP#мўP#мўP#мўP#мјP#меP#меP#меP#меP#мњP#№јP#міP#мњP#№јP#міP#мњP#№јP#мњP#№јP#мќP#њP#№јP#мњP#№вP#міP#мЫџP# јP#міџP#ЄќP#њP#№УŠЦџ Ухў 4џЗ$ѕ,].Q/h/з0:1%2&3ъ35.5S6З6C7Э9ž<]=9>Ь>@Ї@ь@џ@A9A„AўAB8B9CPCmCіCbDDћDўP#мўP#мќP#№ўP#мќP#№ўP#мўP#мўP#мўP#мќP#№ўP#млP#млP#мў P#мў P#мўP#мўP#мўP#мўP#мўP#мўP#мйP#ќP#№зP#мќP#№зP#мйP#ќP#№зP#мќP#№зP#меP#меP#мйP#зP#м Ѕхў 4џЗ#ћDHEzEиEFqFЃFЕFvHH€HHŒHHŽHHHпP#мпP#мпP#мпP#мпP#мпP#мпP#мнP#мжвнжвнннP#мh`јџ% Ухў 4џЗK(@ёџ(Normal Јx]aj@jRubrik 1H Х;§№( 4€Ф. U]ckj@jRubrik 2E Š;§№ 4€Ф. UV]a cf@fRubrik 3H L<§№< 4€Ф.U]ch@hRubrik 4H  <§№< 4€Ф) UV]cb@bRubrik 5F д <§№< 4€Ф()]cd@dRubrik 6F ˜<§№< 4€Ф()V]c`@`Rubrik 7F \<§№< 4€Ф()]b@bRubrik 8F  <§№< 4€Ф()V]d @dRubrik 9F ф<§№< 4€Ф()V]c&A@ђџЁ&Standardstycketeckensnitt @ђ Sidfot Иp#\;@\ Nummerlista 3@ Qхў 4џџ.\=@\ Nummerlista 5@ ‡хў 4€."@""Normalt indragЈ)@Ђ1 Sidnummer"@B"Sidhuvud Иp#EHІH!џџ џџ џџ џџ џџ џџх Zѓ!з-Љ<EкOыciFijyz’Јоё‚жюр( = П _ Ч Ь hƒ–#JЩ&Т'гmдB0ZЉdиuсѕ4zJ8Ћj‰‰9[D є !ѓ!"о#я#$а$%s%x&3'˜'Щ)п)ѕ)]+Q,h,з-:.%/&0ъ02.2S3З3C4Э6ž9]:9;Ь;=Ї=ь=џ=>9>„>ў>?8?9@P@m@і@bAAћAHBzBиBCqCЃCЕCvEwEEœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœ $Б/HN()*+Zѕ,ћDH,-./ !•!џ•€‘dŒhmmsС;0x#-+'"е`, ,RKF…RF KOMMENTARSKAPADATREDTIDDOKNAMN FILSTORLEK NYCKELORD SENSPARATAVANTALTKNANTALSIDANTALORD UTSKRIFTSDATPRIVATRDVERSIONSPARADAT€MNEINHODOKMALLTITELXOALFAARABINITVERS GRUNDTEXT TECKENFORM VALUTATEXT F…RSTVERSHEXGEMEN KOPPLAFORMORDTALORDTEXTROMANVERSALABSAVRUNDADEFHELTALOCHFALSKTMAXMINRESTMEDELANTALICKEELLERPRODUKTOMTECKENSUMMASANTњInst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap+PowerMac:Temporary Items:Word arbetsfil A 5Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95Inst fšr Datavetenskap5PowerMac:AnvŠndare:kentk:Nya nydefs:comm.points.nov95џ@€dd ddWьfMTimes New Roman Symbol MArial MTimesMNew Century SchlbkMHelvetica"0аhZFZfYfTƒБ9џSummary: The current LIA-2 draft must be rejected even to become a CD. There are too many errors in the specifications. There are also issues concerning the way in which the specifications are currently made. Page-by-page remarks on some of the дsmalleGšran SchumacherInst fšr DatavetenskapаЯрЁБс;џў џџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ