Imported from previous forum
[ original email was from Jim Northey - jnorthey@jandj.com ]
I was wondering if anyone else had implemented composite scaled numbers yet? For what seems like very little value over scaled numbers (as I read the definitions in the TE spec 1.0) there is alot of extra work in terms of coding to handle the two entries in the PMAP for the composite scaled number datatype.
Was wondering if anyone else had this same concern and question?
[ original email was from Jim Northey - jnorthey@jandj.com ]
I guess I need to reply to my own thread following a discussion with Rolf. Turns out the two field version of the Scaled Number (referred to in TE as the Composite Scaled Number) is very useful and because the mantissa and exponent are separate fields, the number of encoding alternatives is greatly increased. For instance, the exponent can be treated separately in terms of copy encoding.
In fact, in future versions of FAST, it may make sense to deprecate the Scaled Number datatype.
One last point - it might make sense to rename the Composite Scaled Number datatype to Decimal to sync it up with the important TD specification.
I was wondering if anyone else had implemented composite scaled numbers
yet? For what seems like very little value over scaled numbers (as I
read the definitions in the TE spec 1.0) there is alot of extra work in
terms of coding to handle the two entries in the PMAP for the composite
scaled number datatype. Was wondering if anyone else had this same
concern and question?