| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Float numbers in WF |
« View previous topic :: View next topic » |
| Author |
Message
|
| Milesi |
 Posted: Tue Oct 07, 2003 7:26 pm Post subject: Float numbers in WF |
 |
|
Apprentice
Joined: 15 Apr 2002
Posts: 37
|
Hello,
When we first design our worflow, we decided to store various amounts using the float data type. Unfortunately we recently realized that float values are approximate of decimal value, as they are binary fractions.
The effect can be noticed if you look at a xml message from a float data type container with for example the value 0.5560, the xml message will show 0.5560000000000001.
The problem is that we use those container values in the short description field of activities. This field is limited in length to 256 characters and such behavior could cause the description to become too big. As this description is parsed on a custom client to show user relevant information about an activity, going over the limit will at best mess up the display at worst create an error on the client. On top of this, it is hard to explain to users (and managers…) that the value they are seeing is just a representation of the actual figures.
The issue was raised to IBM and they replied us that it is perfectly normal. Which I understand, but which doesn't solve my problem. I need to change my float data types. But to what?
Option 1: Strings. Why not, the client handles the conversions and significant figures accuracy. So far so good, except that I haven’t found any way to convert back this string value to a decimal value for routing conditions. For example a routing rule such as BETA > 0.125. The only conversion I have found is VALUE() which convert a string expression to an integer.
Option 2. Long. This option requires us to define for every entry the number of significant figures. First issue, it depends on other data (For example currencies) Second issue, any program that will have to work with the container must be able to understand this notation, and convert the two long values to float. Third issue, the description field to render the value properly will have to look like %BETA%.%ALPHA%, then what if alpha represent the number of cents and this number is actually 02, it will show .2 instead. Finally, we have an interface that uses DTD from workflow to map data to another system. Change in container structures means change in DTD and substantial work on there side.
Hopefully there is an option that I have missed out.
Sorry for the long post and thank you for your help.
Regards. |
|
| Back to top |
|
 |
| Ratan |
| Posted: Tue Oct 07, 2003 8:31 pm Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
If I get your question correctly, your only problem is the display. Have two Container members one to hold the actual Float value and another to hold a string representation of it. Use the actual Float value for transitions and the string value for display.
Is this what you are looking for?
_________________
-Ratan |
|
| Back to top |
|
|
| Milesi |
| Posted: Tue Oct 07, 2003 9:31 pm Post subject: |
|
|
Apprentice
Joined: 15 Apr 2002
Posts: 37
|
| Ratan wrote: |
If I get your question correctly, your only problem is the display. Have two Container members one to hold the actual Float value and another to hold a string representation of it. Use the actual Float value for transitions and the string value for display.
Is this what you are looking for? |
Thank you for your suggestion.
It is an option indeed and we thought of it. It has two big impacts so: first the custom client code must be changed to handle this duality (always save both values in case of float values). It doesn't sound too bad as it is only when writing to container that we have to change this. The second issue is the interface of XML messages to other systems. If the container change the DTD will also change and all the maps will have to be changed.
Maybe an option to this is to put all the string values associated to a float in a separate data structure and only map the normal structures to the UPES activity that send the XML message.
This might be a possible work around, but I am wondering if there is anything simpler. |
|
| Back to top |
|
|
| Milesi |
| Posted: Tue Oct 07, 2003 9:40 pm Post subject: |
|
|
Apprentice
Joined: 15 Apr 2002
Posts: 37
|
We are also concerned with the following that is part of the answer we had from IBM:
"In conclusion, a floating-point number is, in many ways, only
an approximation of a true integer or decimal value. For this reason,
this field type should NOT be used for monetary data, nor for other
data where exact precision is required." |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Oct 08, 2003 11:26 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
What version are you using... I seem to recall an issue with floating point numbers in XML that was fixed with SP1 or SP2 of V3.4. I dont have access to my doc at the moment, so you will have to have a look on your own.
GOOD LUCK
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| Milesi |
| Posted: Wed Oct 08, 2003 5:31 pm Post subject: |
|
|
Apprentice
Joined: 15 Apr 2002
Posts: 37
|
| jmac wrote: |
What version are you using... I seem to recall an issue with floating point numbers in XML that was fixed with SP1 or SP2 of V3.4. I dont have access to my doc at the moment, so you will have to have a look on your own.
GOOD LUCK |
Thanks for the info John.
We just installed SP3 for V3.4. We previously had XML issues on V3.2 where the number of significant digits was in certain cases 10 instead of 16 as mentionned in the documentation (Which mainly caused issues for large numbers). At the time it was corrected with a fix wich I thing was indeed included in a service pack. The issue we face now is not related to XML, what the XML shows is actually the value saved in DB2 as IBM confirmed. Our problem is that their is no simple solution to have exact decimal values in containers that are actually considered as numerical values (For the purpose of comparaison, routing, display from description). Using long or string data types are work around.
I was hoping I had missunderstood something along the way. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
