Re: [U2] Any limitation in UniVerse decimal places
(This response assumes that your upstream UniVerse billing application is totalling decimal amounts.) I don't know of specific limitations concerning decimal places, but I do know that precision differences in floating point math cause unexpected behavior. If you're trying to total dollar amounts in a program, it's a best practice to ICONV them into integers before any math operations -- this eliminates all floating point problems. AFAIK the query language RETRIEVE (i.e. LIST, SORT) performs math operations on the data as-stored in the record, then applies the OCONV before displaying the total (also avoiding floating point problems). rex apogee79 wrote: I shall explain the problem that I am encountering in the best detailed way that I can. I am working on a billing application (running on UniVerse), which sends details to a downstream application for invoicing. If several invoice groups are sent in one shot, where the total is approximately more that $20 million, an error occurs, due to rounding off. But when those invoice groups are sent one at a time, this condition does not occur. Is there any upper limit that is set in the configuration parameters? Can anyone please throw some light on this? G --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Any limitation in UniVerse decimal places
What... No source code? --B -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of apogee79 Sent: Thursday, May 07, 2009 2:43 AM To: u2-users@listserver.u2ug.org Subject: [U2] Any limitation in UniVerse decimal places I shall explain the problem that I am encountering in the best detailed way that I can. I am working on a billing application (running on UniVerse), which sends details to a downstream application for invoicing. If several invoice groups are sent in one shot, where the total is approximately more that $20 million, an error occurs, due to rounding off. But when those invoice groups are sent one at a time, this condition does not occur. Is there any upper limit that is set in the configuration parameters? Can anyone please throw some light on this? G -- View this message in context: http://www.nabble.com/Any-limitation-in-UniVerse-decimal-places-tp234211 16p23421116.html Sent from the U2 - Users mailing list archive at Nabble.com. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Any limitation in UniVerse decimal places
In short, problem can be described as it is caused by? the fact that on certain condition represented by combination of large number of invoices and over 9 digits totals Universe engine creates a small fractional addition to total number. Has anyone heard of this? G -Original Message- From: Rex Gozar rgo...@autopower.com To: u2-users@listserver.u2ug.org Sent: Thu, 7 May 2009 5:49 pm Subject: Re: [U2] Any limitation in UniVerse decimal places (This response assumes that your upstream UniVerse billing application is totalling decimal amounts.)? ? I don't know of specific limitations concerning decimal places, but I do know that precision differences in floating point math cause unexpected behavior.? ? If you're trying to total dollar amounts in a program, it's a best practice to ICONV them into integers before any math operations -- this eliminates all floating point problems.? ? AFAIK the query language RETRIEVE (i.e. LIST, SORT) performs math operations on the data as-stored in the record, then applies the OCONV before displaying the total (also avoiding floating point problems).? ? rex? ? apogee79 wrote:? I shall explain the problem that I am encountering in the best detailed way? that I can. I am working on a billing application (running on UniVerse),? which sends details to a downstream application for invoicing. If several? invoice groups are sent in one shot, where the total is approximately more? that $20 million, an error occurs, due to rounding off. But when those? invoice groups are sent one at a time, this condition does not occur. Is? there any upper limit that is set in the configuration parameters? Can? anyone please throw some light on this?? G? ---? u2-users mailing list? u2-us...@listserver.u2ug.org? To unsubscribe please visit http://listserver.u2ug.org/? You are invited to Get a Free AOL Email ID. - http://webmail.aol.in --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Any limitation in UniVerse decimal places
Hi, In short, problem can be described as it is caused by? the fact that on certain condition represented by combination of large number of invoices and over 9 digits totals Universe engine creates a small fractional addition to total number. Not quite right. The problem here is that, just as there are numbers that cannot be represented accurately in decimal such as 1/3, there are numbers that cannot be represented accurately in the binary notiation used by the computer. As an easy example, the number 0.2 cannot be represented accurately and ends up as something like 0.20001 as a close approximation. Because IEEE floating point has a limited number of bits to store the matissa part of the value, the whole thing scales with bigger numbers. Essentially, a number cannot have lots of significant figures, wherever they may be in relation to the decimal point. If you add up a large number of figures with these rounding errors they may accumulate to something significant. Even worse, if you decide to do decimal scaling with a simple multiply instead of an MD conversion code, the inaccuracies get scaled too. This problem is not unique to UniVerse. It is a well known probelm of floating point numbers in computer systems. The usual fix in the multivalue world is to scale numbers (dollars to cents, for example) so that all our numbers are integers. UV also provides a set of character string arithmetic functions if you really want to get clever. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Any limitation in UniVerse decimal places
Going way back to my pick days - I vaguely recall in some programs that used large number of digits to the left of decimal, we had to set the precision to a lower number (e.g. PRECISION 2). This basically took digits away from the right and made available to the left (assuming your data only has two decimal values). Mark -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of ggayat...@aol.in Sent: Thursday, May 07, 2009 8:26 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Any limitation in UniVerse decimal places In short, problem can be described as it is caused by? the fact that on certain condition represented by combination of large number of invoices and over 9 digits totals Universe engine creates a small fractional addition to total number. Has anyone heard of this? G --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Any limitation in UniVerse decimal places
Hi, Th String maths routines (SDIV, SMULT etc) that Martin alludes to at the bottom of his post are very effective, but do require code changes to all the calcuations in the program. You can achieve the same effect in Universe by putting $OPTIONS STRING.MATH at the top of the program. However, there may be other reasons for getting rounding errors. For example, if you have a an invoice for a number of items and you wish to calculate the tax on that invoice, you can do this one of two ways. You can calculate and round the tax on each item and then add up the individual tax amounts. Or you can add up the value of the items and calculate and round the tax on the total value. The two methods can give different figures. I know most people in the list will be familiar with that scenario but sometimes it is worth making sure that the obvious issues are covered before looking for something more unusual. cheers, asvin The problem here is that, just as there are numbers that cannot be represented accurately in decimal such as 1/3, there are numbers that cannot be represented accurately in the binary notiation used by the computer. As an easy example, the number 0.2 cannot be represented accurately and ends up as something like 0.20001 as a close approximation. Because IEEE floating point has a limited number of bits to store the matissa part of the value, the whole thing scales with bigger numbers. Essentially, a number cannot have lots of significant figures, wherever they may be in relation to the decimal point. If you add up a large number of figures with these rounding errors they may accumulate to something significant. Even worse, if you decide to do decimal scaling with a simple multiply instead of an MD conversion code, the inaccuracies get scaled too. This problem is not unique to UniVerse. It is a well known probelm of floating point numbers in computer systems. The usual fix in the multivalue world is to scale numbers (dollars to cents, for example) so that all our numbers are integers. UV also provides a set of character string arithmetic functions if you really want to get clever. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised and regulated by the Financial Services Authority. - SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group HSBC for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
