Issue 3431: Marshaling fixed-point decimal types (interop) Source: Oracle (Mr. Stefan Bauer, ) Nature: Uncategorized Issue Severity: Summary: Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed types I ran into a question. The section doesn't mention how to indicate the scale of the written decimal. My understanding is that the TypeCode of kind fixed, which gets written before the value, indicates the maximum number of digits and the maximum scale, not what is currently contained in the number. To describe the current scale I would expect that a decimal point gets written to the stream, just like the decimals into the half-octets as described in 15.3.2.8. Resolution: Close with no Interop Revision Revised Text: Actions taken: March 16, 2000: received issue March 24, 2000: moved frpm core to interop October 4, 2000: closed issue Discussion: The TypeCode is only written to the stream if the fixed is contained in an any. Otherwise, both sender & receiver implicitly know the type. The GIOP encoding for fixed is well specified as packed BCD with the number of digits as specified by the fixed type as declared by the IDL. For the particular case above, the fixed value must be padded with zeros to fit the scale and digits requirement of the typecode. So, for fixed<4.2>, the value "1.2" is transmitted as "0120". this turns out to be a java-rtf issue. The signature of the methods void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() need to be changed to void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal, short, short) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed(short, short) where the short parameters indicate the digits and scale of the fixed-point decimal. This is because the information of the maximum number of digits and scale is lost when the IDL fixed gets mapped to the BigDecimal for write_fixed. On the other end, when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original scale without explicitly passing in the scale. For fixed contained in an Any this information can be gathered from the associated TypeCode. End of Annotations:===== Date: Thu, 16 Mar 2000 12:55:52 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org CC: Peter Walker , rip-dev Subject: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g+o!!XV^!!iB5!!:9Zd9 Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed types I ran into a question. The section doesn't mention how to indicate the scale of the written decimal. My understanding is that the TypeCode of kind fixed, which gets written before the value, indicates the maximum number of digits and the maximum scale, not what is currently contained in the number. To describe the current scale I would expect that a decimal point gets written to the stream, just like the decimals into the half-octets as described in 15.3.2.8. Stefan Bauer CORBA Technologies Sun Microsystems Inc. X-Authentication-Warning: corvette.floorboard.com: jbiggar-u10.cisco.com [171.71.228.71] didn't use HELO protocol Sender: jbiggar@corvette.floorboard.com Date: Thu, 16 Mar 2000 17:10:14 -0800 From: Jonathan Biggar <"jon"@jon@biggar.org> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Bauer CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o!@!!o;3!!@=Le9:nU!! Stefan Bauer wrote: > > Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of > fixed > types I ran into a question. The section doesn't mention how to > indicate > the scale of the written decimal. > > My understanding is that the TypeCode of kind fixed, which gets > written > before the value, indicates the maximum number of digits and the > maximum > scale, not what is currently contained in the number. To describe > the > current scale I would expect that a decimal point gets written to > the > stream, just like the decimals into the half-octets as described in > 15.3.2.8. The TypeCode is only written to the stream if the fixed is contained in an any. Otherwise, both sender & receiver implicitly know the type. For your particular case, the fixed value must be padded with zeros to fit the scale and digits requirement of the typecode. So, for fixed<4.2>, the value "1.2" is transmitted as "0120". -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 20 Mar 2000 09:13:04 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US MIME-Version: 1.0 To: Jonathan Biggar <"jon"@jon@biggar.org> CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: lJ)!!O#c!!C$#"!d$\d9 see below Jonathan Biggar wrote: > > Stefan Bauer wrote: > > > > Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of > fixed > > types I ran into a question. The section doesn't mention how to > indicate > > the scale of the written decimal. > > > > My understanding is that the TypeCode of kind fixed, which gets > written > > before the value, indicates the maximum number of digits and the > maximum > > scale, not what is currently contained in the number. To describe > the > > current scale I would expect that a decimal point gets written to > the > > stream, just like the decimals into the half-octets as described > in > > 15.3.2.8. > > The TypeCode is only written to the stream if the fixed is contained > in > an any. Otherwise, both sender & receiver implicitly know the type. So if I have the following scenario Sender has a java.math.BigDecimal with a certain scale. Sender writes it to an OutputStream using write_fixed(BigDecimal) (the scale information is lost) Receiver reads a BigDecimal from InputStream.read_fixed() you are saying that the receiver, implicitly knowing the type, has to apply setScale() to the BigDecimal in order to restore the original value? Unfortunately the scale and digits information of the IDL fixed is lost when you map it to a BigDecimal. The OutputStream.write_fixed() implementation has no knowledge about how to pad it with zeros as you describe for the case of Anys below. This seems a little odd to me. All because we want to save the dot in the GIOP message. But if that is the way it works then fine with me. > For your particular case, the fixed value must be padded with zeros to > fit the scale and digits requirement of the typecode. So, for > fixed<4.2>, the value "1.2" is transmitted as "0120". Having an (optional) dot instead of padding with zeros would work here too and save more space on average. I don't want to suggest changing the format. I just want to make sure my understanding is correct. If that's the way your ORBs work then I will make sure ours works that way too. -Stefan X-Authentication-Warning: corvette.floorboard.com: jbiggar-u10.cisco.com [171.71.228.71] didn't use HELO protocol Sender: jbiggar@corvette.floorboard.com Date: Mon, 20 Mar 2000 12:15:15 -0800 From: Jonathan Biggar <"jon"@jon@biggar.org> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Bauer CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Co5e9aRB!!WL"e9e5"e9 Stefan Bauer wrote: > > > Looking at formal/99-10-07, 15.3.2.8 which describes marshaling > of fixed > > > types I ran into a question. The section doesn't mention how to > indicate > > > the scale of the written decimal. > > > > > > My understanding is that the TypeCode of kind fixed, which gets > written > > > before the value, indicates the maximum number of digits and the > maximum > > > scale, not what is currently contained in the number. To > describe the > > > current scale I would expect that a decimal point gets written > to the > > > stream, just like the decimals into the half-octets as described > in > > > 15.3.2.8. > > > > The TypeCode is only written to the stream if the fixed is > contained in > > an any. Otherwise, both sender & receiver implicitly know the > type. > > So if I have the following scenario > > Sender has a java.math.BigDecimal with a certain scale. > Sender writes it to an OutputStream using write_fixed(BigDecimal) > (the > scale information is lost) > Receiver reads a BigDecimal from InputStream.read_fixed() > > you are saying that the receiver, implicitly knowing the type, has > to > apply setScale() to the BigDecimal in order to restore the original > value? > > Unfortunately the scale and digits information of the IDL fixed is > lost > when you map it to a BigDecimal. The OutputStream.write_fixed() > implementation has no knowledge about how to pad it with zeros as > you > describe for the case of Anys below. This is a defect in the Java InputStream & OutputStream specification. The GIOP encoding for fixed is well specified as packed BCD with the number of digits as specified by the fixed type as declared by the IDL. The Java InputStream & OutputStream classes need to have a digits and scale parameter added to read_fixed and write_fixed. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 21 Mar 2000 15:39:09 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US MIME-Version: 1.0 To: Jonathan Biggar <"jon"@jon@biggar.org> CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: dm0e9bdJ!!K~De922T!! Jonathan Biggar wrote: > > Stefan Bauer wrote: > > > > Looking at formal/99-10-07, 15.3.2.8 which describes > marshaling of fixed > > > > types I ran into a question. The section doesn't mention how > to indicate > > > > the scale of the written decimal. > > > > > > > > My understanding is that the TypeCode of kind fixed, which > gets written > > > > before the value, indicates the maximum number of digits and > the maximum > > > > scale, not what is currently contained in the number. To > describe the > > > > current scale I would expect that a decimal point gets written > to the > > > > stream, just like the decimals into the half-octets as > described in > > > > 15.3.2.8. > > > > > > The TypeCode is only written to the stream if the fixed is > contained in > > > an any. Otherwise, both sender & receiver implicitly know the > type. > > > > So if I have the following scenario > > > > Sender has a java.math.BigDecimal with a certain scale. > > Sender writes it to an OutputStream using write_fixed(BigDecimal) > (the > > scale information is lost) > > Receiver reads a BigDecimal from InputStream.read_fixed() > > > > you are saying that the receiver, implicitly knowing the type, has > to > > apply setScale() to the BigDecimal in order to restore the > original > > value? > > > > Unfortunately the scale and digits information of the IDL fixed is > lost > > when you map it to a BigDecimal. The OutputStream.write_fixed() > > implementation has no knowledge about how to pad it with zeros as > you > > describe for the case of Anys below. > > This is a defect in the Java InputStream & OutputStream > specification. > The GIOP encoding for fixed is well specified as packed BCD with the > number of digits as specified by the fixed type as declared by the > IDL. > The Java InputStream & OutputStream classes need to have a digits > and > scale parameter added to read_fixed and write_fixed. I agree that write_fixed needs to be changed. Or at least the new method write_fixed(BigDecimal, short, short) added to org.omg.CORBA.portable.OutputStream. If it causes too much pain to remove the current write_fixed(BigDecimal) then we should at least deprecate it and document that it causes loss of scale information. On the InputStream side, however, I don't see why we need digits and scale. For type checking maybe, to see whether the other ORB didn't marshal soemthing not corresponding to the type code. Note that padding a fraction with zeros causes the scale of the fixed to increase to its maximum value. This maximum value is what the TypeCode defines. So the fixed<10,5> with value 12345678.12 will be padded to 0012345678.12000. If you read that from the InputStream with read_fixed() you get the BigDecimal 12345678.12000 which has a greater scale (and more precision) than the original. Using the TypeCode information as in read_fixed(short, short) doesn't prevent this, so I don't see the value of it. -Stefan Sender: jon@corvette.floorboard.com Message-ID: <38D864F4.C38468DB@floorboard.com> Date: Tue, 21 Mar 2000 22:15:16 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Bauer CC: Jonathan Biggar <"jon"@jon@biggar.org>, orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> <38D8081D.CF1197B1@Eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: lOJ!!$?bd9Ra0e9VXl!! Stefan Bauer wrote: > > This is a defect in the Java InputStream & OutputStream > specification. > > The GIOP encoding for fixed is well specified as packed BCD with > the > > number of digits as specified by the fixed type as declared by the > IDL. > > The Java InputStream & OutputStream classes need to have a digits > and > > scale parameter added to read_fixed and write_fixed. > > I agree that write_fixed needs to be changed. Or at least the new > method > write_fixed(BigDecimal, short, short) added to > org.omg.CORBA.portable.OutputStream. If it causes too much pain to > remove the current write_fixed(BigDecimal) then we should at least > deprecate it and document that it causes loss of scale information. > > On the InputStream side, however, I don't see why we need digits and > scale. For type checking maybe, to see whether the other ORB didn't > marshal soemthing not corresponding to the type code. > > Note that padding a fraction with zeros causes the scale of the > fixed to > increase to its maximum value. This maximum value is what the > TypeCode > defines. So the fixed<10,5> with value 12345678.12 will be padded to > 0012345678.12000. If you read that from the InputStream with > read_fixed() you get the BigDecimal 12345678.12000 which has a > greater > scale (and more precision) than the original. Using the TypeCode > information as in read_fixed(short, short) doesn't prevent this, so > I > don't see the value of it. I think you misunderstand the IDL fixed point type and how it is marshalled. The value 12345678.12 is not a valid value for fixed<10,5>. A fixed<10.5> value may not have an absolute value larger than 99999.99999. If you have a Java BigDecimal value 12345678.12 and try to pass it as a fixed<10,5>, you should get a system exception of some variety, probably MARSHAL, BAD_ARG, or DATA_CONVERSION. For GIOP, fixed<10,5> is marshalled as a sign half-octet, 10 BCD half-octets and a 0 pad half-octet. This is why write_fixed() and read_fixed() both need the digits and scale. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 21 Mar 2000 23:40:22 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US MIME-Version: 1.0 To: Jonathan Biggar CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> <38D8081D.CF1197B1@Eng.sun.com> <38D864F4.C38468DB@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a3md94:De979cd9nd?!! Jonathan Biggar wrote: > > Stefan Bauer wrote: > > > This is a defect in the Java InputStream & OutputStream > specification. > > > The GIOP encoding for fixed is well specified as packed BCD with > the > > > number of digits as specified by the fixed type as declared by > the IDL. > > > The Java InputStream & OutputStream classes need to have a > digits and > > > scale parameter added to read_fixed and write_fixed. > > > > I agree that write_fixed needs to be changed. Or at least the new > method > > write_fixed(BigDecimal, short, short) added to > > org.omg.CORBA.portable.OutputStream. If it causes too much pain to > > remove the current write_fixed(BigDecimal) then we should at least > > deprecate it and document that it causes loss of scale > information. > > > > On the InputStream side, however, I don't see why we need digits > and > > scale. For type checking maybe, to see whether the other ORB > didn't > > marshal soemthing not corresponding to the type code. > > > > Note that padding a fraction with zeros causes the scale of the > fixed to > > increase to its maximum value. This maximum value is what the > TypeCode > > defines. So the fixed<10,5> with value 12345678.12 will be padded > to > > 0012345678.12000. If you read that from the InputStream with > > read_fixed() you get the BigDecimal 12345678.12000 which has a > greater > > scale (and more precision) than the original. Using the TypeCode > > information as in read_fixed(short, short) doesn't prevent this, > so I > > don't see the value of it. > > I think you misunderstand the IDL fixed point type and how it is > marshalled. The value 12345678.12 is not a valid value for > fixed<10,5>. A fixed<10.5> value may not have an absolute value > larger > than 99999.99999. If you have a Java BigDecimal value 12345678.12 > and > try to pass it as a fixed<10,5>, you should get a system exception > of > some variety, probably MARSHAL, BAD_ARG, or DATA_CONVERSION. Sorry, you are right, bad example. I easily get confused with those fixed types. What I meant to use was fixed<15,5>. But my point is still valid. Fixed<15,5> with value 12345678.12 will be padded to 0012345678.12000. > For GIOP, fixed<10,5> is marshalled as a sign half-octet, 10 BCD > half-octets and a 0 pad half-octet. > > This is why write_fixed() and read_fixed() both need the digits and > scale. The receiver calls read_fixed(15, 5) and gets back the BigDecimal 12345678.12000 which those three additional zeros as opposed to the original. How do you tell the receiver that those last three zeros are padded, not some extra precision. I guess it comes down to the question of whether you accept 12345678.12000 == 12345678.12. In a numerical sense they aren't equal. Look at java.math.BigDecimal which makes a distinction between equals() and compareTo() for exactly this reason. Also it appears that digits is not needed for read_fixed since it is always padded to size digits. Reading the fixed off the marshal stream stops at the sign half-octet, which is always last. Again, both points are minor and I don't want to change the format (to marshal a decimal point instead of padding with zeros, which was how this thread started). Therefore, if nobody objects here, I will go ahead and submit it as an issue to the java-rtf to add both digit and scale to both write_fixed and read_fixed as you suggested. -Stefan From: Paul Kyzivat To: orb_revision@omg.org Subject: RE: Marshaling fixed-point decimal types Date: Wed, 22 Mar 2000 11:16:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )?B!!&-p!!S<;!!>TSd9 > From: Stefan Bauer [mailto:Stefan.Bauer@eng.sun.com] > The receiver calls read_fixed(15, 5) and gets back the BigDecimal > 12345678.12000 which those three additional zeros as opposed to the > original. How do you tell the receiver that those last three zeros > are > padded, not some extra precision. The receiver isn't getting a padded value - he is getting exactly what the interface calls for. The padding, if you want to call it that, happens when the sender coerces his value to the fixed<15,5> type of the argument. This is no different than using a short value in a call where the declared type is long. > > I guess it comes down to the question of whether you accept > 12345678.12000 == 12345678.12. In a numerical sense they aren't > equal. > Look at java.math.BigDecimal which makes a distinction > between equals() and compareTo() for exactly this reason. This seems to be a discrepancy between the corba notion of fixed and the type the java language mapping uses to represent it. I don't know much about the origin of the fixed type in corba, but I'll bet you have Cobol to blame for the semantics. Paul Sender: jbiggar@corvette.floorboard.com Message-ID: <38D90609.95274CFE@floorboard.com> Date: Wed, 22 Mar 2000 09:42:33 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Bauer CC: orb_revision@omg.org, Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> <38D8081D.CF1197B1@Eng.sun.com> <38D864F4.C38468DB@floorboard.com> <38D878E6.168FDF33@Eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ()1e9;PC!!_BT!!Yn9e9 Stefan Bauer wrote: > > I think you misunderstand the IDL fixed point type and how it is > > marshalled. The value 12345678.12 is not a valid value for > > fixed<10,5>. A fixed<10.5> value may not have an absolute value > larger > > than 99999.99999. If you have a Java BigDecimal value 12345678.12 > and > > try to pass it as a fixed<10,5>, you should get a system exception > of > > some variety, probably MARSHAL, BAD_ARG, or DATA_CONVERSION. > > Sorry, you are right, bad example. I easily get confused with those > fixed types. What I meant to use was fixed<15,5>. > > But my point is still valid. Fixed<15,5> with value 12345678.12 will > be > padded to 0012345678.12000. > > > For GIOP, fixed<10,5> is marshalled as a sign half-octet, 10 BCD > > half-octets and a 0 pad half-octet. > > > > This is why write_fixed() and read_fixed() both need the digits > and > > scale. > > The receiver calls read_fixed(15, 5) and gets back the BigDecimal > 12345678.12000 which those three additional zeros as opposed to the > original. How do you tell the receiver that those last three zeros > are > padded, not some extra precision. > > I guess it comes down to the question of whether you accept > 12345678.12000 == 12345678.12. In a numerical sense they aren't > equal. > Look at java.math.BigDecimal which makes a distinction between > equals() > and compareTo() for exactly this reason. I can't help it if Java has a weird concept of arithmetic. :-) You can't rely on Java semantics being preserved here across the wire, since the other end might not be Java anyway. > Also it appears that digits is not needed for read_fixed since it is > always padded to size digits. Reading the fixed off the marshal > stream > stops at the sign half-octet, which is always last. True, the fixed format is actually self length-encoding, since it is easy to identify the end of a number due to the sign half-octet. It's a little slower doing that, though, rather than just calculating the number of octets used via a digits parameter. > Again, both points are minor and I don't want to change the format (to > marshal a decimal point instead of padding with zeros, which was how > this thread started). Therefore, if nobody objects here, I will go ahead > and submit it as an issue to the java-rtf to add both digit and scale to > both write_fixed and read_fixed as you suggested. Go ahead. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 22 Mar 2000 16:24:23 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: java-rtf@OMG.ORG CC: Jonathan Biggar , Peter Walker , rip-dev Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> <38D8081D.CF1197B1@Eng.sun.com> <38D864F4.C38468DB@floorboard.com> <38D878E6.168FDF33@Eng.sun.com> <38D90609.95274CFE@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~$?e98:De9#A'"!IMG!! As Jon indicates below this turns out to be a java-rtf issue. The signature of the methods void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() need to be changed to void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal, short, short) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed(short, short) where the short parameters indicate the digits and scale of the fixed-point decimal. This is because the information of the maximum number of digits and scale is lost when the IDL fixed gets mapped to the BigDecimal for write_fixed. On the other end, when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original scale without explicitly passing in the scale. For fixed contained in an Any this information can be gathered from the associated TypeCode. Stefan Bauer CORBA Technologies Sun Microsystems, Inc. > Jonathan Biggar wrote: > > > > Stefan Bauer wrote: > > > > > Looking at formal/99-10-07, 15.3.2.8 which describes > marshaling of fixed > > > > > types I ran into a question. The section doesn't mention how > to indicate > > > > > the scale of the written decimal. > > > > > > > > > > My understanding is that the TypeCode of kind fixed, which > gets written > > > > > before the value, indicates the maximum number of digits and > the maximum > > > > > scale, not what is currently contained in the number. To > describe the > > > > > current scale I would expect that a decimal point gets > written to the > > > > > stream, just like the decimals into the half-octets as > described in > > > > > 15.3.2.8. > > > > > > > > The TypeCode is only written to the stream if the fixed is > contained in > > > > an any. Otherwise, both sender & receiver implicitly know the > type. > > > > > > So if I have the following scenario > > > > > > Sender has a java.math.BigDecimal with a certain scale. > > > Sender writes it to an OutputStream using > write_fixed(BigDecimal) (the > > > scale information is lost) > > > Receiver reads a BigDecimal from InputStream.read_fixed() > > > > > > you are saying that the receiver, implicitly knowing the type, > has to > > > apply setScale() to the BigDecimal in order to restore the > original > > > value? > > > > > > Unfortunately the scale and digits information of the IDL fixed > is lost > > > when you map it to a BigDecimal. The OutputStream.write_fixed() > > > implementation has no knowledge about how to pad it with zeros > as you > > > describe for the case of Anys below. > > > > This is a defect in the Java InputStream & OutputStream > specification. > > The GIOP encoding for fixed is well specified as packed BCD with > the > > number of digits as specified by the fixed type as declared by the > IDL. > > The Java InputStream & OutputStream classes need to have a digits > and > > scale parameter added to read_fixed and write_fixed. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org Date: Wed, 22 Mar 2000 16:31:11 -0800 From: Stefan Bauer X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: Re: Marshaling fixed-point decimal types References: <38C7F333.D671C8EF@Eng.sun.com> <38D14A58.438911E5@Eng.sun.com> <200003170109.RAA17882@corvette.floorboard.com> <38D65C20.8E8E8B44@Eng.sun.com> <200003202014.MAA23742@corvette.floorboard.com> <38D8081D.CF1197B1@Eng.sun.com> <38D864F4.C38468DB@floorboard.com> <38D878E6.168FDF33@Eng.sun.com> <38D90609.95274CFE@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X8>!!QRQe9C-X!!"j`!! As Jon indicates below this turns out to be a java-rtf issue. The signature of the methods void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() need to be changed to void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal, short, short) java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed(short, short) where the short parameters indicate the digits and scale of the fixed-point decimal. This is because the information of the maximum number of digits and scale is lost when the IDL fixed gets mapped to the BigDecimal for write_fixed. On the other end, when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original scale without explicitly passing in the scale. For fixed contained in an Any this information can be gathered from the associated TypeCode. Stefan Bauer CORBA Technologies Sun Microsystems, Inc. > Jonathan Biggar wrote: > > > > Stefan Bauer wrote: > > > > > Looking at formal/99-10-07, 15.3.2.8 which describes > marshaling of fixed > > > > > types I ran into a question. The section doesn't mention how > to indicate > > > > > the scale of the written decimal. > > > > > > > > > > My understanding is that the TypeCode of kind fixed, which > gets written > > > > > before the value, indicates the maximum number of digits and > the maximum > > > > > scale, not what is currently contained in the number. To > describe the > > > > > current scale I would expect that a decimal point gets > written to the > > > > > stream, just like the decimals into the half-octets as > described in > > > > > 15.3.2.8. > > > > > > > > The TypeCode is only written to the stream if the fixed is > contained in > > > > an any. Otherwise, both sender & receiver implicitly know the > type. > > > > > > So if I have the following scenario > > > > > > Sender has a java.math.BigDecimal with a certain scale. > > > Sender writes it to an OutputStream using > write_fixed(BigDecimal) (the > > > scale information is lost) > > > Receiver reads a BigDecimal from InputStream.read_fixed() > > > > > > you are saying that the receiver, implicitly knowing the type, > has to > > > apply setScale() to the BigDecimal in order to restore the > original > > > value? > > > > > > Unfortunately the scale and digits information of the IDL fixed > is lost > > > when you map it to a BigDecimal. The OutputStream.write_fixed() > > > implementation has no knowledge about how to pad it with zeros > as you > > > describe for the case of Anys below. > > > > This is a defect in the Java InputStream & OutputStream > specification. > > The GIOP encoding for fixed is well specified as packed BCD with > the > > number of digits as specified by the fixed type as declared by the > IDL. > > The Java InputStream & OutputStream classes need to have a digits > and > > scale parameter added to read_fixed and write_fixed. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org