Kate The original A and S types on PICK-like systems were designed purely with integer arithmethic in mind - hence the use of the MDn and MRn conversions to scale and descale. They are not designed for floating point work, so it's no surprise they don't give the answers you expect.
And with good reason.. Using non-integer maths is a very bad idea on *any* computer system since floating point operations are intrinsically inaccurate. Incidentally, a lot of SQL based financial apps do the same, even though there are high precision and decimal types available, preferring to store scaling factors alongside their prices to ensure they don't get hit by rounding/truncation errors, so it's not confined to our sector. And as for messing about with complex correlatives - why on EARTH would you want to do that, rather than just fixing the design? You've had 30 years to do so... BUT maybe it would be nice if it could be configurable, say through an entry in uvconfig, to work the same as an I-descriptor. I wouldn't want to see something that fundamental get changed, because it could well mess up other, well-behaved sites, unless it were a configurable option switched off by default. Brian -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: 21 January 2011 04:46 To: U2 Users List Subject: [U2] 3.99 x 3 = 11 Does anyone else have a problem with this? We have (for about 30 years) allowed users to use a decimal point when entering quantity. In the dim dark past (was it under Prime or Ultimate? don't remember) we discovered that correlatives ignored anything after a decimal point, so wrote horrible correlatives multiplying the bit before the point by 10000, appending 0000 to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 10000. In the slightly less dim dark past (before 1997, when we introduced our current change control system), we noticed that this problem had been fixed, and removed the complication from correlatives involving quantity. Now, many years and much development later, we extensively use dictionary output rather than programs for reports, forms (eg invoices) and queries. Inaccurate data is an unexpected result. On type S (or A) dictionaries, result of calculation in A or F correlatives is truncated to the decimal point (eg 3.99 x 3 = 11). Minor result is incorrect figures. Major result is under-reporting of totals which are not able to be reconciled to General Ledger (eg value of stock on hand). Rocket's response is that the manual says correlatives only do integer arithmetic. This is not quite true, as integer 3.99 x 3 would be 9. I-type dictionary items handle the data correctly (3.99 x 3 = 11.97). I-types have their own problems, in that fields after 10 are used for internal purposes, so are not able to carry extra information needed for data entry (such as data required, display only, validation rules, data change stamp, etc. I-types also are hard to work with as using a changed dictionary without compiling the dictionary logs the user out, and inadvertent attempt to display data in fields beyond F10 can lock user up, as well as untidily logging out. We are asking Rocket to consider this a bug. What do you think? TIA, Kate Kate Stanton Walstan Systems Ltd 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: + 64 9 360 5310 Mobile: + 64 21 400 486 Email: k...@walstan.com _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
