Issue 1668:  DynFixed interface isn"t usefu (port-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: The interface for DynFixed requires me to deal with a fixed-point type
 as an octet sequence. The contents of the octet sequence are simply
 the bytes that would be generated by the CDR marshaling rules for a
 fixed-point value.
 
 Fine, that allows me to get the values in and out, but it is pragmatically
 useless. Do we really expect every application dealing with DynFixed to
 re-implement the marshaling rules? Moreover, at run time, getting the
 value in and out is very complex. Either I use decadic logarithms to
 extract the digit values, or I need to turn the fixed-point value into
 a string and then parse out the digits (never mind that there is no
 standard API call for turning the fixed-point value into a string to
 start with).
 
 >From there, it is still completely unclear how I could turn the fixed-point
 octet sequence (which I now hold as a string or as a series of decimal
 digits) into a value I use to do computation. I would have to multiply
 successive digits into an accumulator, dividing by 10 for every digit.
 
 This is simply useless for all intents and purposes, because it is far
 too much work.
 l

Resolution: 
Revised Text: 
Actions taken:
July 13, 1998: received issue
Discussion: 

End of Annotations:=====
Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Sat, 11 Jul 1998 13:08:58 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: issues@omg.org, port-rtf@omg.org
Subject: DynFixed interface isn't useful


The interface for DynFixed requires me to deal with a fixed-point type
as an octet sequence. The contents of the octet sequence are simply
the bytes that would be generated by the CDR marshaling rules for a
fixed-point value.

Fine, that allows me to get the values in and out, but it is
pragmatically
useless. Do we really expect every application dealing with DynFixed
to
re-implement the marshaling rules? Moreover, at run time, getting the
value in and out is very complex. Either I use decadic logarithms to
extract the digit values, or I need to turn the fixed-point value into
a string and then parse out the digits (never mind that there is no
standard API call for turning the fixed-point value into a string to
start with).

>From there, it is still completely unclear how I could turn the
fixed-point
octet sequence (which I now hold as a string or as a series of decimal
digits) into a value I use to do computation. I would have to multiply
successive digits into an accumulator, dividing by 10 for every digit.

This is simply useless for all intents and purposes, because it is far
too much work.

Unfortunately, it isn't that easy to fix. Conceptually, what I would
like
is:

	interface DynFixed : DynAny {		// Not legal IDL
		fixed get_value();
		void  set_value(in fixed val) raises(InvalidValue);
	};

But now, we run into a glitch, because there are a *large* number
of fixed point types (unless I've made a mistake, there are 528
different
fixed-point types):

	fixed<1,1>
	fixed<2,1>
	...
	fixed<32,1>
	fixed<2,2>
	fixed<3,2>
	...
	fixed<32,2>
	fixed<3,3>
	fixed<4,3>
	...
	fixed<31,31>
	fixed<32,32>
	
To make the above work, I would need a different operation for each
possible fixed type, which doesn't seem practical.

I think to get this to work, fixed actually would have to be either an
interface or a value type, with a generic fixed type at the root.
The DynAny interface could then use the generic root type --
operations
or attributes on the value would allow me to get the digits and scale
at run time.

I don't have an immediate suggestion for fixing this, but I'm flagging
it
now in the face of the ongoing discussions for how to deal with fixed
types,
because that discussion may be influenced by the above. Also, we may
well discover the need to pass a "generic" fixed-point type across
an interface (similar to the idea of a Pascal open array, as used
in the above IDL example).

The DynFixed interface we have now "works", but only in the sense that
it is technically possible to use DynFixed. As far as real application
code is concerned, the DynFixed interface is so low-level that it
might
as well not be there at all.

							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