[omniORB] bug in CORBA::Fixed constructor

[Luke Deller]

Thanks Duncan for your responses.  Since my original post I have learned
that omniORB's behaviour in this regard corresponds to CORBA versions
prior
to CORBA 2.5.  There was a change made in 2.5 making leading and
trailing
zeros in fixed point literals to be significant.  The discussion that
led to
this change is documented here:
http://www.omg.org/issues/issue3581.txt

Two earlier discussions in which Michi Henning brought this up without
success:
http://www.omg.org/issues/issue1068.txt
http://www.omg.org/issues/issue1667.txt

Duncan Grisby wrote:
> The thing is, that despite the name, CORBA::Fixed in C++ and
CORBA.fixed
> in Python are actually decimal floating point.

Yes, with regards to arithmetic.  However I think it is fair to call the
corresponding IDL types "fixed-point", because the precision and scale
are
defined in the IDL type (and thus GIOP represents fixed-point values as
a
mantissa only without including the scale or precision).  They would map
to
proper fixed point types in a language which has such types (eg Ada?)

> It doesn't make any sense to maintain leading and trailing zeros in a
> floating point number. How would the precision and decimals behave
during
> arithmetic if leading and trailing zeros were maintained?  The
supposed
> rules in the IDL specification don't actually say what to do, only
state
> the obvious about what the maximum digits and scale values can be.

I'm not so concerned about the behaviour of arithmetic here.  The issue
is maintaining correct IDL types.

Here's an example which I think illustrates the problem:

==== blah.idl ===
module blah {
    typedef fixed<5,2> Money;
    const Money fifty_cents = 000.50d;
};
==== end blah.idl ===

>>> import blah
>>> blah.fifty_cents.decimals()
1

This should be 2 because blah::fifty_cents is of type Money which is
defined as fixed<5,2>.  Similarly I'd want to construct values like this
at runtime
using the appropriate constructor.

As for arithmetic, both the Java class "java.math.BigDecimal" and the
Python
class "decimal.Decimal" do floating-point decimal arithmetic which
maintains
trailing zeros, eg:

>>> from decimal import Decimal
>>> Decimal("1.10")*Decimal("1.10")
Decimal("1.2100")

So apparently maintaining trailing zeros through arithmetic like this
makes
sense to some people.  Personally I can't see the use of this behaviour
in
arithmetic so I'm not going to argue with you that it makes sense :-)
The rules of arithmetic can be well-defined though.

> I think that bit of the spec is inconsistent with the other parts that
> describe how fixed literals get involved in arithmetic, and with the
> details of the language mappings. Fixed point is generally very badly
> specified in all the CORBA specs.

Yes, I've noticed that fixed point in general does seem poorly thought
out
in the CORBA specs.  What in particular are you referring to as an
inconsistency here?  I can't see why significant trailing and leading
zeros
in string literals couldn't be implemented consistently with the spec.

Thanks for your patience in reading this far :-)
Luke.


**********************************************************************************************

Important Note
This email (including any attachments) contains information which is
confidential and may be subject to legal privilege.  If you are not
the intended recipient you must not use, distribute or copy this
email.  If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this
email are not necessarily the views of XPlan Technology.

It is the duty of the recipient to virus scan and otherwise test the
information provided before loading onto any computer system.
Xplan Technology does not warrant that the
information is free of a virus or any other defect or error.
**********************************************************************************************