Re: [U2] 3.99 x 3 = 11
Not millions: 1102 needed to be hand-done; took about 2 weeks. Now changing programs which generate dictionaries. G On 24 January 2011 21:02, Symeon Breen syme...@gmail.com wrote: Weeks ? – you must have millions of them ;) From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: 24 January 2011 04:23 To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 Hi Dan, Yes, I do realise we could change our system to use only I-type dicts, with F1 value 1 for some data, value 2 for another, etc, etc. Pretty untidy. As you say, it would be a huge job. We still could not assign a field to use for stamps, complying with the rest of the system. We now list and inquire on dictionaries through programs which present them all in the same format. We are in the process of changing all dictionary items which calculate on quantity to I-types. Annoying, but achievable in weeks, rather than months. Thanks, Kate On 24 January 2011 15:42, Dan McGrath dmc...@imb.com.au wrote: Hi Kate, You can use multivalue and sub-multivalue marks can be used to keep it just as organised. :ED :P 001: DýMANDýENUM CLASSES 002: 10 003: 004: 005: 10L 006: M :EV :P 001: D 002: MAND 003: ENUM CLASSES We normally just use LISTDICT (an inbuilt paragraph) to display dictionary items :LISTDICT ourfile SORT DICT ourfile TYP LOC CONV MNAME FORMAT SM ASSOC BY TYP BY LOC BY @I D 13:38:56 24 JAN 2011 1 @ID TYP LOC.. CONV MNAME.. FORMAT SM ASSOC. CLASS D 10 10L M I can appreciate that it can be an enormous task to change an existing system though. Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Monday, 24 January 2011 12:19 PM To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 Hi Dan, Thanks for your suggestion. Yes, we use that space for the short description of the data. It would be very messy to try to use this additionally for: - before cell, after cell processing flags - minimum characters - store data field no - data required flag - display-only flag - max no of sets (assuming use F7 to define set this data belongs to, and that item for each item in the set with different type) - match patterns list - delimiter and sub-field no, if applicable - sundry code ID for validation - prompt ID for search - update stamps list (same format as other files: each with date, time, function, who) Especially when it all works appended to A and S type dicts - would take weeks or months to change! What happens on UniData if you ED and P, or print an I-type dict item? Do you stay viable? Cheers, Kate On 21 January 2011 18:06, Dan McGrath dmc...@imb.com.au wrote: With I-types, are you aware you can store whatever you want in Attribute 1 after the data type? This is where we store any additional information required as such data integrity checks, date last changed, etc. Log out issues with dictionary compilation must be specific to UniVerse (?) as we do not have that issue in UniData. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Friday, 21 January 2011 3:46 PM 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
Weeks ? you must have millions of them ;) From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: 24 January 2011 04:23 To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 Hi Dan, Yes, I do realise we could change our system to use only I-type dicts, with F1 value 1 for some data, value 2 for another, etc, etc. Pretty untidy. As you say, it would be a huge job. We still could not assign a field to use for stamps, complying with the rest of the system. We now list and inquire on dictionaries through programs which present them all in the same format. We are in the process of changing all dictionary items which calculate on quantity to I-types. Annoying, but achievable in weeks, rather than months. Thanks, Kate On 24 January 2011 15:42, Dan McGrath dmc...@imb.com.au wrote: Hi Kate, You can use multivalue and sub-multivalue marks can be used to keep it just as organised. :ED :P 001: DýMANDýENUM CLASSES 002: 10 003: 004: 005: 10L 006: M :EV :P 001: D 002: MAND 003: ENUM CLASSES We normally just use LISTDICT (an inbuilt paragraph) to display dictionary items :LISTDICT ourfile SORT DICT ourfile TYP LOC CONV MNAME FORMAT SM ASSOC BY TYP BY LOC BY @I D 13:38:56 24 JAN 2011 1 @ID TYP LOC.. CONV MNAME.. FORMAT SM ASSOC. CLASS D 10 10LM I can appreciate that it can be an enormous task to change an existing system though. Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Monday, 24 January 2011 12:19 PM To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 Hi Dan, Thanks for your suggestion. Yes, we use that space for the short description of the data. It would be very messy to try to use this additionally for: - before cell, after cell processing flags - minimum characters - store data field no - data required flag - display-only flag - max no of sets (assuming use F7 to define set this data belongs to, and that item for each item in the set with different type) - match patterns list - delimiter and sub-field no, if applicable - sundry code ID for validation - prompt ID for search - update stamps list (same format as other files: each with date, time, function, who) Especially when it all works appended to A and S type dicts - would take weeks or months to change! What happens on UniData if you ED and P, or print an I-type dict item? Do you stay viable? Cheers, Kate On 21 January 2011 18:06, Dan McGrath dmc...@imb.com.au wrote: With I-types, are you aware you can store whatever you want in Attribute 1 after the data type? This is where we store any additional information required as such data integrity checks, date last changed, etc. Log out issues with dictionary compilation must be specific to UniVerse (?) as we do not have that issue in UniData. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Friday, 21 January 2011 3:46 PM 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
Hi Dan, Thanks for your suggestion. Yes, we use that space for the short description of the data. It would be very messy to try to use this additionally for: - before cell, after cell processing flags - minimum characters - store data field no - data required flag - display-only flag - max no of sets (assuming use F7 to define set this data belongs to, and that item for each item in the set with different type) - match patterns list - delimiter and sub-field no, if applicable - sundry code ID for validation - prompt ID for search - update stamps list (same format as other files: each with date, time, function, who) Especially when it all works appended to A and S type dicts - would take weeks or months to change! What happens on UniData if you ED and P, or print an I-type dict item? Do you stay viable? Cheers, Kate On 21 January 2011 18:06, Dan McGrath dmc...@imb.com.au wrote: With I-types, are you aware you can store whatever you want in Attribute 1 after the data type? This is where we store any additional information required as such data integrity checks, date last changed, etc. Log out issues with dictionary compilation must be specific to UniVerse (?) as we do not have that issue in UniData. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Friday, 21 January 2011 3:46 PM 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB
Re: [U2] 3.99 x 3 = 11
Hi Mecki, Thanks for your suggestion. Yes, we use conversions for almost all numbers, but not quantity, for reasons stated (instead, use match patterns: 0N, 0N.0N, -0N, -0N.0N). We have been doing this for about 30 years. In early days, we split out the integer and decimal portion of quantity for calculation, as described. this was removed when it was fixed, but it may have been Ultimate, not UniVerse. Cheers, Kate On 21 January 2011 21:23, Mecki Foerthmann mec...@gmx.net wrote: AFAIK the result of an A-correlative has always been an integer. That's why I don't store numbers with decimal points. Ever heard of input conversions (i.e. MD2) ? That allows your users to enter decimal points but stores the data internally as integers. In your case 399 * 3 = 1197 which with an output conversion of MD2 shows 11.97. Even with that you may get wrong results if you divide small numbers through big ones in A-correlatives if you don't multiply with a multiple of 10 first. On 21/01/2011 04:45, Kate Stanton wrote: 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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 -- 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
Re: [U2] 3.99 x 3 = 11
Hi Ed, Thanks for your response. We cannot agree that this is a feature of Pick-based systems. I do hope you are not relying on decimals being truncated, as they are not in either BASIC programs or I-type dictionaries. For reasons given, we have allowed decimals in quantity in our Pick-based system for around 30 years, with complicated correlatives to cope in the past. After implementation of I-type dictionaries a few years ago, we are now reporting from dictionaries rather than programs, which is why this problem has arisen. Remember, someone decided that A-1 = B doing nothing if B is blank was a bug, and changed the behaviour of UniVerse - caused us huge hassles. If this were fixed to always only take integer portion of a number, we would be out of business. Cheers, Kate On 22 January 2011 03:46, Ed Clark u...@edclark.net wrote: These aren't bugs. They are features :) Going all the way back to the beginnings with pick and microdata/reality, math in the F and A processing codes has been integer only. This was on purpose, for speed I think. And it works fine if you follow the fundamental rule of not using decimal points internally. If you want your users to input 3.99 then your input routine should use ICONV to scale it to 399, and then scale again on output. On d3 (and I guess ultimate) 3.99 x 3 = 9. They do pure integer math in correlatives, truncating decimals. universe emulated this using the decimals but truncating the result. It's slightly more accurate but still keeps decimals out of the results, which was what was expected--it's a feature. F-correlatives are interpreted, but itypes compile their expressions to object code similar to what the basic compiler produces (for performance), and store that object code in the itype item itself. This is another feature--the compiled object has to go somewhere, and that's where they put it on universe. That's why you shouldn't display the entire itype item on a terminal--it contains binary object code, some of which will appear to your terminal as control characters, and throw your terminal into odd modes. If that does happen, most good terminal emulators have a menu option to reset the display--you aren't really locked up at that point. If you find yourself experiencing this a lot, you might want to consider putting together a dictionary viewer program (something fancier than LISTF) that will prevent you from displaying the embedded object code, and could also display version info, etc, if you store it. I've never been logged out on universe by using a changed dict without recompiling, but I guess it is possible. In that case you aren't being logged out--you are experiencing a memory error of some kind and aborting. If you can reproduce that then it really is a bug that should be reported. As someone else mentioned, you can use the first attribute of the itype to store arbitrary information--this works on A/S/D type dictionary items as well. universe only looks at the first letter, so anything after that is free to use. However, a better option might be to use some form of source control. On Jan 20, 2011, at 11:45 PM, Kate Stanton wrote: 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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,
Re: [U2] 3.99 x 3 = 11
Hi Dan, Yes, I do realise we could change our system to use only I-type dicts, with F1 value 1 for some data, value 2 for another, etc, etc. Pretty untidy. As you say, it would be a huge job. We still could not assign a field to use for stamps, complying with the rest of the system. We now list and inquire on dictionaries through programs which present them all in the same format. We are in the process of changing all dictionary items which calculate on quantity to I-types. Annoying, but achievable in weeks, rather than months. Thanks, Kate On 24 January 2011 15:42, Dan McGrath dmc...@imb.com.au wrote: Hi Kate, You can use multivalue and sub-multivalue marks can be used to keep it just as organised. :ED :P 001: DýMANDýENUM CLASSES 002: 10 003: 004: 005: 10L 006: M :EV :P 001: D 002: MAND 003: ENUM CLASSES We normally just use LISTDICT (an inbuilt paragraph) to display dictionary items :LISTDICT ourfile SORT DICT ourfile TYP LOC CONV MNAME FORMAT SM ASSOC BY TYP BY LOC BY @I D 13:38:56 24 JAN 2011 1 @ID TYP LOC.. CONV MNAME.. FORMAT SM ASSOC. CLASS D 10 10L M I can appreciate that it can be an enormous task to change an existing system though. Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Monday, 24 January 2011 12:19 PM To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 Hi Dan, Thanks for your suggestion. Yes, we use that space for the short description of the data. It would be very messy to try to use this additionally for: - before cell, after cell processing flags - minimum characters - store data field no - data required flag - display-only flag - max no of sets (assuming use F7 to define set this data belongs to, and that item for each item in the set with different type) - match patterns list - delimiter and sub-field no, if applicable - sundry code ID for validation - prompt ID for search - update stamps list (same format as other files: each with date, time, function, who) Especially when it all works appended to A and S type dicts - would take weeks or months to change! What happens on UniData if you ED and P, or print an I-type dict item? Do you stay viable? Cheers, Kate On 21 January 2011 18:06, Dan McGrath dmc...@imb.com.au wrote: With I-types, are you aware you can store whatever you want in Attribute 1 after the data type? This is where we store any additional information required as such data integrity checks, date last changed, etc. Log out issues with dictionary compilation must be specific to UniVerse (?) as we do not have that issue in UniData. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Friday, 21 January 2011 3:46 PM 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
AFAIK the result of an A-correlative has always been an integer. That's why I don't store numbers with decimal points. Ever heard of input conversions (i.e. MD2) ? That allows your users to enter decimal points but stores the data internally as integers. In your case 399 * 3 = 1197 which with an output conversion of MD2 shows 11.97. Even with that you may get wrong results if you divide small numbers through big ones in A-correlatives if you don't multiply with a multiple of 10 first. On 21/01/2011 04:45, Kate Stanton wrote: 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
These aren't bugs. They are features :) Going all the way back to the beginnings with pick and microdata/reality, math in the F and A processing codes has been integer only. This was on purpose, for speed I think. And it works fine if you follow the fundamental rule of not using decimal points internally. If you want your users to input 3.99 then your input routine should use ICONV to scale it to 399, and then scale again on output. On d3 (and I guess ultimate) 3.99 x 3 = 9. They do pure integer math in correlatives, truncating decimals. universe emulated this using the decimals but truncating the result. It's slightly more accurate but still keeps decimals out of the results, which was what was expected--it's a feature. F-correlatives are interpreted, but itypes compile their expressions to object code similar to what the basic compiler produces (for performance), and store that object code in the itype item itself. This is another feature--the compiled object has to go somewhere, and that's where they put it on universe. That's why you shouldn't display the entire itype item on a terminal--it contains binary object code, some of which will appear to your terminal as control characters, and throw your terminal into odd modes. If that does happen, most good terminal emulators have a menu option to reset the display--you aren't really locked up at that point. If you find yourself experiencing this a lot, you might want to consider putting together a dictionary viewer program (something fancier than LISTF) that will prevent you from displaying the embedded object code, and could also display version info, etc, if you store it. I've never been logged out on universe by using a changed dict without recompiling, but I guess it is possible. In that case you aren't being logged out--you are experiencing a memory error of some kind and aborting. If you can reproduce that then it really is a bug that should be reported. As someone else mentioned, you can use the first attribute of the itype to store arbitrary information--this works on A/S/D type dictionary items as well. universe only looks at the first letter, so anything after that is free to use. However, a better option might be to use some form of source control. On Jan 20, 2011, at 11:45 PM, Kate Stanton wrote: 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
I suspect part of the reason is accuracy, as well. Base 10 decimals don't necessarily convert to an exact base 2 decimal. 1.2 converts to something like 1.001100110011001100110011... Storing them as integers, then manipulating them within the code preserves the accuracy. Drew -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ed Clark Sent: Friday, January 21, 2011 9:47 AM To: U2 Users List Subject: Re: [U2] 3.99 x 3 = 11 These aren't bugs. They are features :) Going all the way back to the beginnings with pick and microdata/reality, math in the F and A processing codes has been integer only. This was on purpose, for speed I think. And it works fine if you follow the fundamental rule of not using decimal points internally. If you want your users to input 3.99 then your input routine should use ICONV to scale it to 399, and then scale again on output. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] 3.99 x 3 = 11
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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
[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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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
Re: [U2] 3.99 x 3 = 11
With I-types, are you aware you can store whatever you want in Attribute 1 after the data type? This is where we store any additional information required as such data integrity checks, date last changed, etc. Log out issues with dictionary compilation must be specific to UniVerse (?) as we do not have that issue in UniData. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kate Stanton Sent: Friday, 21 January 2011 3:46 PM 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 1, appending to the bit after, taking the first 4 chars of this and adding it, doing arithmetic then dividing result by 1. 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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ### ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
