Issue 1071: Type of fixed point quotients (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Significant Summary: Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as: fixed<(d1-s1+s2) + Sinf, Sinf> I"m having a problem with this: The type of the result cannot be known at compile-time because it depends on the actual values. This differs from the add, subtract, and multiplication operators, where the result type can be determined statically. There is a C++ mapping problem too. The C++ mapping uses a template type for fixed point, where the digits and the scale are template parameters (i.e. must be compile-time constants). Resolution: Revised Text: Actions taken: March 19, 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: Thu, 19 Mar 1998 10:23:21 +1000 (EST) From: Michi Henning To: issues@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Type of fixed point quotients Hi, the 2.2 spec on page 3-20 defines the type of a fixed point division as: fixed<(d1-s1+s2) + Sinf, Sinf> I'm having a problem with this: The type of the result cannot be known at compile-time because it depends on the actual values. This differs from the add, subtract, and multiplication operators, where the result type can be determined statically. There is a C++ mapping problem too. The C++ mapping uses a template type for fixed point, where the digits and the scale are template parameters (i.e. must be compile-time constants). The C++ mapping defines an operator/(): Fixed operator/(const Fixed &v1, const Fixed &v2); What is the result type of this operator? Looks like it is unknowable... The only other interpretation I can find is to always have the result type of a division as Fixed<31, S>, where S == 31 - min(31, max(1, (d1-s1+s2))) If that is the intent, the spec should make it clear. I'm beginning to suspect though that using a template type for fixed point can't be made to work. Would it be better to use a single Fixed class (not templated) which works out the digits and scale at run-time (for example, using constructor arguments)? It certainly would be easier to use. Right now, the mapping is too strictly typed in my opinion. In particular, I can't easily assign the result of a fixed point computation to a fixed point value, unless I go through an intermediate conversion via LongDouble (which lots of ORBs don't support yet, and for which we don't have a proper C++ mapping if native support isn't available). If Fixed would use run-time knowledge of the digits and scale, I could freely assign different Fixed values to each other... Comments anyone? 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: Wed, 18 Mar 1998 18:07:51 PST Sender: Bill Janssen From: Bill Janssen To: issues@omg.org, cxx_revision@omg.org, orb_revision@omg.org, Michi Henning Subject: Re: Type of fixed point quotients References: Michi, This is a fascinating set of issues you are raising. The semantics of fixed seem almost completely unspecified in the description of the type system, so individual mappings have to invent them. The best description we have is the partial treatment we have in the section on how to interpret expressions involving fixed constants, but that leaves out lots of questions. For instance, what's the result of multiplying a "long" value by a "fixed" value? Is it even allowed? How about the assignment of fixed values? Suppose in my application program I had two values of the type typedef fixed<5,2> f5dot2; I multiply them (producing a value of type fixed<10,4>), and them assign them to a value of type f5dot2. What's the algorithm for losing significance? Do we really want 0.17 * 0.17 to be 0.02 instead of 0.03, which is the answer implied by the constant arithmetic rules? Since the type was added at the behest of the business community, I'd imagine that standard accounting practices might inform the answer. Should language mappings even allow casting of a fixed value into a different fixed `shape'? I'm eager to understand the answers here! Bill Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 19 Mar 1998 12:13:00 +1000 (EST) From: Michi Henning To: Bill Janssen cc: issues@omg.org, cxx_revision@omg.org, orb_revision@omg.org Subject: Re: Type of fixed point quotients On Wed, 18 Mar 1998, Bill Janssen wrote: > I'm eager to understand the answers here! Join the club... :-( I'm beginning to suspect that the fixed type as specified is unimplementable with semantics that are even half-way guaranteed to yield the same results across different implementations. Considering that the intent of the fixed type was to support mainly things like monetary computations, this doesn't bode well. I just hope that my bank won't switch to using IDL fixed in the near future... Looks like this will need a lot more work. 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: Wed, 18 Mar 1998 18:31:31 PST Sender: Bill Janssen From: Bill Janssen To: Michi Henning Subject: Re: Type of fixed point quotients CC: orb_revision@omg.org References: Excerpts from direct: 18-Mar-98 Re: Type of fixed point quo.. Michi Henning@dstc.edu.a (797*) > I'm beginning to suspect that the fixed type as specified is unimplementable > with semantics that are even half-way guaranteed to yield the same results > across different implementations. Ditto. > Considering that the intent of the fixed type was to support mainly things > like monetary computations, this doesn't bode well. I just hope that > my bank won't switch to using IDL fixed in the near future... No, that's what gives me hope. There must be well-defined semantics for things like this (BCD types) already in existence; we only need to find them and add them to chapter 3. We're implementing arbitrary fixed-point types, sort of rational types with a fixed denominator that doesn't have to be a power of 10, so you can handle dozens or thirds, and optionally bounded by max and min numerator values, instead of `digits'. CORBA fixed is a subset of this space, of course. As are all the other CORBA integer types, along with bignums. In fact, I've been playing with the idea of dropping the other pre-defined integer types (`octet', `short', `long', etc.) and just providing fixed-point and floating-point types. Of course, might as well get rid of the handful of pre-defined floating-point types, as well, since any floating-point type can be defined as a constructor with seven parameters. That would allow specification of and use of odd floating-point formats like VAX and Cray formats. More interestingly, we could directly support the various variants of IEEE extended precision FP that have sprung up. Bill Return-Path: Sender: jon@floorboard.com Date: Wed, 18 Mar 1998 22:55:39 -0800 From: Jonathan Biggar To: Bill Janssen CC: Michi Henning , orb_revision@omg.org Subject: Re: Type of fixed point quotients References: <0p48C3kB0KGW02wjAj@holmes.parc.xerox.com> Bill Janssen wrote: > > Excerpts from direct: 18-Mar-98 Re: Type of fixed point quo.. Michi > Henning@dstc.edu.a (797*) > > > I'm beginning to suspect that the fixed type as specified is > unimplementable > > with semantics that are even half-way guaranteed to yield the same > results > > across different implementations. > > Ditto. > > > Considering that the intent of the fixed type was to support > mainly things > > like monetary computations, this doesn't bode well. I just hope > that > > my bank won't switch to using IDL fixed in the near future... > > No, that's what gives me hope. There must be well-defined semantics > for > things like this (BCD types) already in existence; we only need to > find > them and add them to chapter 3. > > We're implementing arbitrary fixed-point types, sort of rational > types > with a fixed denominator that doesn't have to be a power of 10, so > you > can handle dozens or thirds, and optionally bounded by max and min > numerator values, instead of `digits'. CORBA fixed is a subset of > this > space, of course. As are all the other CORBA integer types, along > with > bignums. In fact, I've been playing with the idea of dropping the > other > pre-defined integer types (`octet', `short', `long', etc.) and just > providing fixed-point and floating-point types. Of course, might as > well get rid of the handful of pre-defined floating-point types, as > well, since any floating-point type can be defined as a constructor > with > seven parameters. That would allow specification of and use of odd > floating-point formats like VAX and Cray formats. More > interestingly, > we could directly support the various variants of IEEE extended > precision FP that have sprung up. I feel leary about trying to solve this problem within OMG, since it is likely that we don't have many (or any) fixed point arithmetic experts, and the subject is likely to include several subtleties. As far as the ORB core goes, there isn't really an issue, since all the ORB core cares about is transmitting values from one place to another in a language independant way, and what is there now certainly does the job. This is really a language binding issue. Certainly languages like COBOL or Ada, which already have well defined fixed point facilities, there isn't a problem. Also, Java has BigDecimal and Smalltalk has scaledDecimal. So, for the OMG standard language bindings, this leaves C & C++. So the question of the day is, is ISO working on fixed point arithmetic standard libraries/classes for C or C++? My guess is probably, but I'm not plugged in to the C or C++ standards effort. The C/C++ RTF can take one of three approaches to this problem: 1. Leave it broken, hope it gets better? 2. Remove the math, since it is broken, and just make it easy for programmers to convert between CORBA::Fixed and whatever proprietary class they use. 3. Identify and reference a standard from somewhere else. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org 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.