Issue 1068: Fixed point constants issue (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Page 3-20 of CORBA 2.2: A fixed-point literal has the apparent number of total and fractional digits, except that leading an trailing zeros are factored out, including non-significant zeros before the decimal point. For example, 0123.450d is considered to be fixed<5,2> and 3000.00 is fixed<1,-3>. Apart from the fact that 3000.00 is not a fixed point constant literal, I"m confused about something else... If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>. These rules result in 3000.00d being fixed<1,-3> BUT 3000.01d being fixed<6,2> This doesn"t seem to make sense. If I bother to write the trailing zeros, surely I have a reason, namely, that I mean to use that scale. In other words, I think that 3000.00d should be fixed<6,2> and 3000.0000d should be fixed<8,4> Why are fractional trailing zeros thrown away but fractional trailing non-zeros retained? Resolution: Revised Text: Actions taken: March 18, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 18 Mar 1998 16:10:59 +1000 (EST) From: Michi Henning To: issues@omg.org Subject: More on fixed point constants Hi, Page 3-20 of CORBA 2.2: A fixed-point literal has the apparent number of total and fractional digits, except that leading an trailing zeros are factored out, including non-significant zeros before the decimal point. For example, 0123.450d is considered to be fixed<5,2> and 3000.00 is fixed<1,-3>. Apart from the fact that 3000.00 is not a fixed point constant literal, I'm confused about something else... If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>. These rules result in 3000.00d being fixed<1,-3> BUT 3000.01d being fixed<6,2> This doesn't seem to make sense. If I bother to write the trailing zeros, surely I have a reason, namely, that I mean to use that scale. In other words, I think that 3000.00d should be fixed<6,2> and 3000.0000d should be fixed<8,4> Why are fractional trailing zeros thrown away but fractional trailing non-zeros retained? Another question: What is the type of the following constants? .3d is it fixed<1,1> or is it fixed<2,1>? 3.d is it fixed<1,0> or is it fixed<1,1>? 3000.d is it fixed<4,0> or is it fixed<5,1>? .3000d is it fixed<4,4> or is it fixed<5,4>? I assume the intent was the first type listed for each case above, that is, 3.d is fixed<1,0>. However, an example wouldn't go astray... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Sun, 12 Jul 1998 14:45:04 -0700 From: jon@floorboard.com (Jon Biggar) To: orb_revision@omg.org Subject: Fixed point type overhall proposal Since I only got comments from Michi (and a lot of comments at that), I've gone ahead and written up a proposal for consideration. [This proposal covers issues #754, #1066, #1068, #1071.] Proposal for overhauling the IDL Fixed Point Type Definition: Part 1: Fix the grammar to prohibit anonymous fixed point parameter declarations [Resolves 754] Change Production 80 to remove as a valid parameter type: ::= | | | | Also add the missing production on page 3-19: ::= "fixed" Rational: Leaving this in causes problems with the C++ binding in the same way that the grammar from CORBA 1.1 and earlier had problems with sequences and arrays as parameters. This is also likely to cause problems with the Ada binding, since each fixed point declaration is mapped to a distinct Ada type. Part 2: Fix the grammar for fixed point constants [Resolves #1066] Change the first paragraph of section 3.7.2 to read: The in the production must be a previously defined name of an , , , , , , or constant. Also, change the "3000.00" in the example of fixed point digits and scale to "3000.00D". Rational: Fixed point constants are defined using the syntax "fixed", not "fixed", while fixed point types are defined using the later syntax. So there is no way for a to refer to a . Part 3: Modify the paragraph at the top of 3-21 to read: A quotient may have an arbitrary number of decimal places, denoted by a scale of s inf . The computation proceeds pairwise, with the usual rules for left-to-right association, operator precedence, and parentheses. All intermediate computations should be performed using double precision (i.e. 62 digit) arithmetic. If an individual computation between a pair of fixed-point literals actually generates more than 31 significant digits, then a 31-digit result is retained as follows: Rational: This change is to make sure that all IDL compilers calculate the results of fixed-point constants the same way, so as not to break interoperability. Part 4: Reword the description of Fixed Type in section 3.8.3 to be: The fixed data type represents a fixed-point decimal number of up to 31 significant digits. The scale factor is a non-negative integer less than or equal to the total number of digits (note that constants with effectively negative scale, such as 10000, are always permitted). The fixed data type will be mapped to the native fixed point capability of a programming language, if available. If there is not a native fixed point type, then the IDL mapping for that language will a fixed point data type. Applications that use the IDL fixed point type across multiple programming languages must take in to account differences between the languages in handling rounding, overflow, and arithmetic precision. Rational: If these values of scale are not universally supported by language bindings, then they are not portable, and so should not be supported by IDL. The Smalltalk, Ada, Cobol and Java languages already contain a native fixed point facility. To define a separate IDL fixed point capability for these languages would be redundant and interfere with integrating legacy code. Part 5: Close Issue 1068 and 1071 without change Rational: The text is quite clear about the mechanism for assigning digits and scale to fixed point constants. This part of the text only addresses how the IDL compiler evaluates arithmetic expressions involving fixed point literals at compile time and is not intended to define how fixed point arithmetic works in various programming languages at run time.