Re: [U2] Unidata programming books?
Hi If you are already a programmer then I am not sure a book is the right thing tbh - the manuals provided with unidata would suffice. If you are not a programmer, then I am not sure what book would be best, many of them are rather old. It may be better to learn general programming concepts first and to then apply these to unibasic. From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of newuser1 Sent: 01 March 2011 15:17 To: u2-users@listserver.u2ug.org Subject: [U2] Unidata programming books? Hi, I recently discovered this wonderful forum and I really would like to expand my unibasic/unidata programming skills especially writing subroutines. Can anyone recommend me some good books on this? We're using Unidata 7.1. Thank you -- View this message in context: http://old.nabble.com/Unidata-programming-books--tp31040442p31040442.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3474 - Release Date: 02/28/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] AUTO: Chris Thornton, Milton Keynes DataStage software engineer, is on leave. (returning 03/03/2011)
I am out of the office until 03/03/2011. I am on leave until Thursday 3rd March. For 8.5 / Concierge issues please contact lha...@us.ibm.com For other support issues, please contact dave.cheese...@uk.ibm.com For all other urgent issues please contact julian.vi...@uk.ibm.com Note: This is an automated response to your message Re: [U2] Unidata programming books? sent on 2/3/11 8:18:50. This is the only notification you will receive while this person is away. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] UV PE Linux
The copy I had expired on 2/28/11 and there's no current version on Rocket's website. Does anyone know when or if there will be an updated UV PE Linux version available? Bob Little UniVerse Developer Market America Greensboro, NC 336-478-1694 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV PE Linux
It appears you can get it here: http://www.rocketsoftware.com/u2/resources/downloads -- Carl Dula Voice: 973-227-8440 X111 Pulsar Systems, Inc.Fax: 973-227-8440 271 US Highway 46, STE H209 email:c...@pulsarsystems.com Fairfield, NJ 07004-2474http://www.pulsarsystems.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV PE Linux
I see UniData PE for Linux and UniVerse PE for Windows, but I don't see UniVerse PE for Linux. -bob -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Carl Dula Sent: Wednesday, March 02, 2011 7:32 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UV PE Linux It appears you can get it here: http://www.rocketsoftware.com/u2/resources/downloads -- Carl Dula Voice: 973-227-8440 X111 Pulsar Systems, Inc.Fax: 973-227-8440 271 US Highway 46, STE H209 email:c...@pulsarsystems.com Fairfield, NJ 07004-2474http://www.pulsarsystems.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] UV PE Linux
Sorry, try it here... http://www.rocketsoftware.com/u2/resources/premium/downloads/universe-linux?searchterm=universe+personal+edition+linux - Original Message - From: Carl Dula c...@pulsarsystems.com To: u2-users@listserver.u2ug.org Sent: Wednesday, March 02, 2011 7:32 AM Subject: RE: [U2] UV PE Linux It appears you can get it here: http://www.rocketsoftware.com/u2/resources/downloads -- Carl Dula Voice: 973-227-8440 X111 Pulsar Systems, Inc.Fax: 973-227-8440 271 US Highway 46, STE H209 email:c...@pulsarsystems.com Fairfield, NJ 07004-2474http://www.pulsarsystems.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV PE Linux
But this is the version which expired on Feb 28th 2011 ... -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Carl Dula Sent: Wednesday, March 02, 2011 12:50 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UV PE Linux Sorry, try it here... http://www.rocketsoftware.com/u2/resources/premium/downloads/universe-linux? searchterm=universe+personal+edition+linux - Original Message - From: Carl Dula c...@pulsarsystems.com To: u2-users@listserver.u2ug.org Sent: Wednesday, March 02, 2011 7:32 AM Subject: RE: [U2] UV PE Linux It appears you can get it here: http://www.rocketsoftware.com/u2/resources/downloads -- Carl Dula Voice: 973-227-8440 X111 Pulsar Systems, Inc.Fax: 973-227-8440 271 US Highway 46, STE H209 email:c...@pulsarsystems.com Fairfield, NJ 07004-2474http://www.pulsarsystems.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] UV PE Linux
Mike, Look into a little utility called timeshift. I don't know if it still works with later *nixs, I believe it's a wrapper that will run a process under any date you want it to be.I think that's what it did. I don't know what would happen if you started the UV server inside the time bubble??? But it might party like it's 1999! http://ex-parrot.com/~chris/software.html#timeshift Timeshift is a dynamic shared object which allows you to run a program with an altered view of system time. See also its README file. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Mike Street Sent: Wednesday, March 02, 2011 8:35 AM To: 'U2 Users List' Subject: Re: [U2] UV PE Linux But this is the version which expired on Feb 28th 2011 ... -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Carl Dula Sent: Wednesday, March 02, 2011 12:50 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UV PE Linux Sorry, try it here... http://www.rocketsoftware.com/u2/resources/premium/downloads/universe- linux? searchterm=universe+personal+edition+linux - Original Message - From: Carl Dula c...@pulsarsystems.com To: u2-users@listserver.u2ug.org Sent: Wednesday, March 02, 2011 7:32 AM Subject: RE: [U2] UV PE Linux It appears you can get it here: http://www.rocketsoftware.com/u2/resources/downloads -- Carl Dula Voice: 973-227-8440 X111 Pulsar Systems, Inc.Fax: 973-227-8440 271 US Highway 46, STE H209 email:c...@pulsarsystems.com Fairfield, NJ 07004-2474http://www.pulsarsystems.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-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV PE Linux
In Rockets last newsletter - 28 Feb 2011 - they state that UniVerse 11.1 on Linux as PE will be available real soon now... Bob Little-4 wrote: I see UniData PE for Linux and UniVerse PE for Windows, but I don't see UniVerse PE for Linux. - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/UV-PE-Linux-tp31048789p31050189.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Is this worth rewriting?
This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
On 3/2/2011 11:43 AM, Dave Laansma wrote: This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I dunno. If it works and the performance is GoodEnough, I would leave it. Parms is already a dimmed array, so each element is addressed independently. Might be fun to use the U2 vector functions on it and get rid of the loop, i.e. OCONVS() and SUM() instead of the loop. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Hi Dave, Not enough information. 1. How many records does it run against? 2. How long does it take to run? 3. How massive is the PARMS data? If 2 above is insignificant, you may be better off to let sleeping dogs lie, rather than having to test against a full EOM run. Otherwise, I vote for a rewrite. Be sure to test, test, test. Just my 2 pennies, Charlie Noah Charles W. Noah Associates cwn...@comcast.net The views and opinions expressed herein are my own (Charlie Noah) and do not necessarily reflect the views, positions or policies of any of my former, current or future employers, employees, clients, friends, enemies or anyone else who might take exception to them. On 03-02-2011 10:43 AM, Dave Laansma wrote: This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ 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] Is this worth rewriting?
Hi Dave, In general, access to an element of a dimensioned array is fast so the frequent references to PARM(12) should not be a problem. On the other hand, even with the benefits of field level hints, repeated references to the same field/value may be improved by extracting the data into a temporary variable. Incidentally, and at the risk of starting a new war on style, this is a great example of why developers should use equate tokens with meaningful names rather than numbers for field references. As someone who has never seen this code before, I haven't got a clue what it does. Using names hopefully makes the code readable, it makes it easy to find all references to a particular item without having to dismiss all the other references to the same field in a different file, and it reduces errors from typos. Ignore me if you like. It's just a personal hate!! Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Couldn't help but notice it was written without the += and -= constructs. Date: Wed, 2 Mar 2011 11:43:58 -0500 From: dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: [U2] Is this worth rewriting? This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ 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] Is this worth rewriting?
In a message dated 3/2/2011 9:12:57 AM Pacific Standard Time, martinphill...@ladybridge.com writes: Incidentally, and at the risk of starting a new war on style, this is a great example of why developers should use equate tokens with meaningful names rather than numbers for field references. As someone who has never seen this code before, I haven't got a clue what it does. Using names hopefully makes the code readable, it makes it easy to find all references to a particular item without having to dismiss all the other references to the same field in a different file, and it reduces errors from typos. Martin I stand behind you 100 % I'm not the one who took your wallet however. Names Good. Numbers Evil. W ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
In a message dated IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END Just as a follow up, IF Not Not, is very bad style. And parsing long and then short is as well. This part should have been done as IF PARMS(7)102,CM='' THEN CUMO(M) += PARMS(12)134,CM ELSE CUMO(M) += PARMS(7)102,CM END Infinitely more legible. W Fire that programmer. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
If it works, why bother? It IS an ugly piece of code, though. On 02/03/2011 16:43, Dave Laansma wrote: This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ 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] Is this worth rewriting?
Well -- I usually code so the 'first clause' is my 'expected outcome' -- that is, if the PARMS(7)102,CM is TYPICALLY 'not empty' -- so I would do # THEN myself as well.. I do it as much to express the code as the 'typical path'. I also perceive (although have never tested!) the THEN clause as being the 'lower cost' clause to execute. Don't know why I think that or have a reason for thinking that -- I guess because of 'reading' the code, THEN is always the next line without having to 'skip ahead'. So I'm curious why it would that be a bad idea to say ' # THEN'? Is there actually any extra 'overhead'? Or is this a 'preference' issue? Myself, I actually think of it as being 'better documented' explaining how I think the average transaction should progress (usually taking the THEN statements.) Wondering why that is a 'bad thing'??? David W. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Wednesday, March 02, 2011 12:10 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Is this worth rewriting? In a message dated IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END Just as a follow up, IF Not Not, is very bad style. And parsing long and then short is as well. This part should have been done as IF PARMS(7)102,CM='' THEN CUMO(M) += PARMS(12)134,CM ELSE CUMO(M) += PARMS(7)102,CM END Infinitely more legible. W Fire that programmer. ___ 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] Is this worth rewriting?
On 3/2/2011 1:34 PM, David Wolverton wrote: So I'm curious why it would that be a bad idea to say ' # THEN'? Is there actually any extra 'overhead'? Or is this a 'preference' issue? Myself, I actually think of it as being 'better documented' explaining how I think the average transaction should progress (usually taking the THEN statements.) Wondering why that is a 'bad thing'??? David W.s IMO, less code is better code as long as it doesn't involve magic. I will always use += and drop the #''. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Begin case Case code will never run on any machine ever again ; not worth rewriting Case 1 ; someone will probably look at the code That someone will probably be me yes, rewrite it and give it a rev number. End case Begin case case PARMS(7)102,CM='' ;CUMO(M) += PARMS(12)134,CM case 1 ; CUMO(M) += PARMS(7)102,CM END case Infinitely more legible. --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
The += I completely agree with. No arguments on that point at all. But #or = ... that's the exact same amount of code! ;-) And this example seems to point that ONE or the other is needed. That is, you could not change their code IF PARMS(7)102,CM # '' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM END ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END To be a SHORTER: IF PARMS(7)102,CM THEN CUMO(M)=CUMO(M)+PARMS(12)134,CM END ELSE CUMO(M)=CUMO(M)+PARMS(7)102,CM END As what if PARMS(7)102,CM = 0? 0 would 'fail' the 2nd test, but is 'not blank'. So you cannot 'shorten' the clause at all. It either has to be = or # in this case (not knowing anything about the data). My point was that someone said you should NEVER say '# THEN' And I will not dispute this logic could be done with CASE statements - but again, that was not the point I'm trying to delve into more deeply. DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 12:40 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? On 3/2/2011 1:34 PM, David Wolverton wrote: So I'm curious why it would that be a bad idea to say ' # THEN'? Is there actually any extra 'overhead'? Or is this a 'preference' issue? Myself, I actually think of it as being 'better documented' explaining how I think the average transaction should progress (usually taking the THEN statements.) Wondering why that is a 'bad thing'??? David W.s IMO, less code is better code as long as it doesn't involve magic. I will always use += and drop the #''. ___ 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] Is this worth rewriting?
On 3/2/2011 2:05 PM, David Wolverton wrote: As what if PARMS(7)102,CM = 0? 0 would 'fail' the 2nd test, but is 'not blank'. So you cannot 'shorten' the clause at all. It either has to be = or # in this case (not knowing anything about the data). Adding a zero into the sum is basically a NOOP. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
By jove, you're right! In this example, you COULD shorten the clause and it would work! I missed that!! But back to the 'issue' I was raising, although in this example it's moot - the generic statement was that 'IF ... # ... THEN' is 'bad style' ?? I still have missed why that should be considered 'wrong' or 'bad'. If it's purely style, then that's OK too and discussion over! Different horses for different courses! But when someone tells me something is 'bad', I want to know the reasons why so I can advance my understanding. DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 1:09 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? On 3/2/2011 2:05 PM, David Wolverton wrote: As what if PARMS(7)102,CM = 0? 0 would 'fail' the 2nd test, but is 'not blank'. So you cannot 'shorten' the clause at all. It either has to be = or # in this case (not knowing anything about the data). Adding a zero into the sum is basically a NOOP. ___ 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] Is this worth rewriting?
On 3/2/2011 2:18 PM, David Wolverton wrote: By jove, you're right! In this example, you COULD shorten the clause and it would work! I missed that!! But back to the 'issue' I was raising, although in this example it's moot - the generic statement was that 'IF ... # ... THEN' is 'bad style' ?? I still have missed why that should be considered 'wrong' or 'bad'. If it's purely style, then that's OK too and discussion over! Different horses for different courses! But when someone tells me something is 'bad', I want to know the reasons why so I can advance my understanding. DW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 1:09 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? On 3/2/2011 2:05 PM, David Wolverton wrote: As what if PARMS(7)102,CM = 0? 0 would 'fail' the 2nd test, but is 'not blank'. So you cannot 'shorten' the clause at all. It either has to be = or # in this case (not knowing anything about the data). Adding a zero into the sum is basically a NOOP. ___ 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 I like the way pylint nags me on my python code. I bet we could make a unibasic lint. http://www.logilab.org/card/pylintfeatures ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Argh! Multi statement lines in a case construct. Shoot me now. Sorry. Bill Brutzman wrote: Begin case Case code will never run on any machine ever again ; not worth rewriting Case 1 ; someone will probably look at the code That someone will probably be me yes, rewrite it and give it a rev number. End case Begin case case PARMS(7)102,CM='' ;CUMO(M) += PARMS(12)134,CM case 1 ; CUMO(M) += PARMS(7)102,CM END case Infinitely more legible. --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
The reason I ask specifically of the repeated references is, during one of the sessions at U2UG-Denver, it was implied that each time you reference a specific location in a table, the OS basically has to start at the beginning of the table and 'find' its way to that location (explained in my over-simplified way of thinking). Thus why the REMOVE statement is preferred when sequentially referencing a table rather than a FOR/NEXT loop referencing each element individually. The REMOVE statement keeps a pointer as to where it left off in the table and simply goes to the next AM/VM/SM/RM I have personally experienced (and thus embraced) the truly extraordinary performance improvement with the REMOVE statement and would encourage everyone to do so as well. To address a couple comments: This would appear to me to be 'textbook' code, implying it was likely written by a newly graduated college student. With all due respect to college grads, I can't believe some of the code I wrote a few years ago, let alone what I must have done fresh out of college. This code is likely 15+ years old and certainly could use a facelift, as could any of us after any 15-year stint of our lives. To get more detailed would be debating cosmetics ... a debate not intended for this thread. Nearly half-a-million records run through this code each month, it takes about 1.5 hours and is critical that it run at peak efficiency. Therefore my primary objective is performance. Thank you all for the rousing debate. That being said, I think I'll do my modifications and let the group know what the results are. Once again, thank you! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 11:50 AM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? On 3/2/2011 11:43 AM, Dave Laansma wrote: This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I dunno. If it works and the performance is GoodEnough, I would leave it. Parms is already a dimmed array, so each element is addressed independently. Might be fun to use the U2 vector functions on it and get rid of the loop, i.e. OCONVS() and SUM() instead of the loop. ___ 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] Git and U2
Has anyone used Git and U2 - either UniVerse or Unidata - together? Or any other suggestions for a version control - open source is preferred? Thanks in advance, djm - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Git-and-U2-tp31053109p31053109.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Hi Dave, The reason I ask specifically of the repeated references is, during one of the sessions at U2UG-Denver, it was implied that each time you reference a specific location in a table, the OS basically has to start at the beginning of the table and 'find' its way to that location Whilst REMOVE is the quickest way to walk through a dynamic array, field extraction in UV uses a hint mechanism to keep track of the last field accessed. For example, if you have a huge dynamic array and extract field 640, yes, it will have to walk along from the start. If you next go to access field 650, it starts from the known position of field 640 so it will be much faster. This mechanism only works for fields, not values. Also, as far as I know, Unidata doesn't have this mechanism so it would need to start over each time. Dimensioned arrays are totally different. You can access X(1000) just as quickly as X(1) because it is little more than a reference to an indexed table of pointers. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] U2-Users Digest, Vol 23, Issue 2
you say tha half a million records go thru this monthly? what is the concern then of creating a value of zero vs leaving a CUMM element null? it would seem highly unlikely that not a single record you process has no value. just element the tests for null that only stop a single addition and are not truely conditional. jay Message: 10 Date: Wed, 2 Mar 2011 11:43:58 -0500 From: Dave Laansma dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: [U2] Is this worth rewriting? Message-ID: 071256f97fa0fa498115009ae88175b2017b9...@hubmail2.hubbardsupply.com Content-Type: text/plain; charset=US-ASCII This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN === ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Git and U2
On 3/2/2011 3:18 PM, DavidJMurray (mvdbs.com) wrote: Has anyone used Git and U2 - either UniVerse or Unidata - together? Or any other suggestions for a version control - open source is preferred? Thanks in advance, djm - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com If you are trying to push forward with python knowledge, might I recommend mercurial over git. It can be installed via easy_install or pip and has better integration with windows/aix/linux than git. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
What Martin said. It would be better to extract to temporary 1-attribute variables and loop through those rather than looping through the 101st attribute repeatedly. Especially for the prior prior year when LY.CNT = 24. So I say aye. This can definitely be improved. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Git and U2
I use CVS with Universe. I chose to use shell scripts to build Universe accounts; I use the same scripts for both Linux and Windows (via cygwin). rex ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Optimization is about getting rid of bottlenecks in the code. Does this code snippet really represent a significant percentage of the total processing time? Really, what percent? If you can't quantify it, don't change it. rex ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
On 3/2/2011 4:07 PM, Rex Gozar wrote: Optimization is about getting rid of bottlenecks in the code. Does this code snippet really represent a significant percentage of the total processing time? Really, what percent? If you can't quantify it, don't change it. rex ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users +1. * /We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified/^[5] http://en.wikipedia.org/wiki/Program_optimization#cite_note-4 - Donald Knuth http://en.wikipedia.org/wiki/Donald_Knuth * /Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is./ - Rob Pike http://en.wikipedia.org/wiki/Rob_Pike * /The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet./ - Michael A. Jackson http://en.wikipedia.org/wiki/Michael_A._Jackson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Yes and the code would make much more sense if they had names other than parm... You know, stuff like QTY, COST and SALES crazy things like that aye -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Wednesday, March 02, 2011 12:56 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? What Martin said. It would be better to extract to temporary 1-attribute variables and loop through those rather than looping through the 101st attribute repeatedly. Especially for the prior prior year when LY.CNT = 24. So I say aye. This can definitely be improved. ___ 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] Is this worth rewriting?
On 3/2/2011 5:08 PM, Allen E. Elwood wrote: Yes and the code would make much more sense if they had names other than parm... You know, stuff like QTY, COST and SALES crazy things like that aye -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Wednesday, March 02, 2011 12:56 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? What Martin said. It would be better to extract to temporary 1-attribute variables and loop through those rather than looping through the 101st attribute repeatedly. Especially for the prior prior year when LY.CNT = 24. So I say aye. This can definitely be improved. ___ 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 That is an object used in prelude. It is passed around everywhere. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Let me clarify. The problem in my mind is not with the IF X # '' THEN It's with the ELSE portion, which in effect *means* IF X # (# '') The Else clause is essentially executed on a Not Not condition. That adds unnecessary confusion for the next programmer. W -Original Message- From: David Wolverton dwolv...@flash.net To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Wed, Mar 2, 2011 10:34 am Subject: Re: [U2] Is this worth rewriting? Well -- I usually code so the 'first clause' is my 'expected outcome' -- that is, if the PARMS(7)102,CM is TYPICALLY 'not empty' -- so I would do # THEN myself as well.. I do it as much to express the code as the 'typical path'. I also perceive (although have never tested!) the THEN clause as being the 'lower cost' clause to execute. Don't know why I think that or have a reason for thinking that -- I guess because of 'reading' the code, THEN is always the next line without having to 'skip ahead'. So I'm curious why it would that be a bad idea to say ' # THEN'? Is there actually any extra 'overhead'? Or is this a 'preference' issue? Myself, I actually think of it as being 'better documented' explaining how I think the average transaction should progress (usually taking the THEN statements.) Wondering why that is a 'bad thing'??? David W. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Wednesday, March 02, 2011 12:10 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Is this worth rewriting? In a message dated IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END Just as a follow up, IF Not Not, is very bad style. And parsing long and then short is as well. This part should have been done as IF PARMS(7)102,CM='' THEN CUMO(M) += PARMS(12)134,CM ELSE CUMO(M) += PARMS(7)102,CM END Infinitely more legible. W Fire that programmer. ___ 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-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Dave you are correct when referring to dynamic arrays, the 101 type entries in your code. In general, outside of the REMOVE type operations, references like that, must start at field 1 and walk the array until it gets to field 101, reading every character between. Which is why, in general, very large dynamic references are not a good idea. However, it only bites you, when your process that used to handle 100 records a day, now has to handle 100,000 and this code becomes the bottleneck, while your trucks are sitting at the dock waiting as one of my clients used to often say. For the dimensioned array references in your code, the (12) type entries, that is not the case. These dimensioned array references, calculate the offset position, and jump directly to the start of that cell in the array. The cell's content, may be out-of-cell, stored later in the memory map, but it's probably more typical, that it can read the value immediately after the jump. I can get more technical if you need :) Will Johnson -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, Mar 2, 2011 11:55 am Subject: Re: [U2] Is this worth rewriting? The reason I ask specifically of the repeated references is, during one of the sessions at U2UG-Denver, it was implied that each time you reference a specific location in a table, the OS basically has to start at the beginning of the table and 'find' its way to that location (explained in my over-simplified way of thinking). Thus why the REMOVE statement is preferred when sequentially referencing a table rather than a FOR/NEXT loop referencing each element individually. The REMOVE statement keeps a pointer as to where it left off in the table and simply goes to the next AM/VM/SM/RM I have personally experienced (and thus embraced) the truly extraordinary performance improvement with the REMOVE statement and would encourage everyone to do so as well. To address a couple comments: This would appear to me to be 'textbook' code, implying it was likely written by a newly graduated college student. With all due respect to college grads, I can't believe some of the code I wrote a few years ago, let alone what I must have done fresh out of college. This code is likely 15+ years old and certainly could use a facelift, as could any of us after any 15-year stint of our lives. To get more detailed would be debating cosmetics ... a debate not intended for this thread. Nearly half-a-million records run through this code each month, it takes about 1.5 hours and is critical that it run at peak efficiency. Therefore my primary objective is performance. Thank you all for the rousing debate. That being said, I think I'll do my modifications and let the group know what the results are. Once again, thank you! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 11:50 AM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? On 3/2/2011 11:43 AM, Dave Laansma wrote: This is some old code that I didn't write, so please don't use it for anything profitable ... The proposal to the group is: Due to the repeated references deep into the PARMS tables, if this were rewritten to reference these locations as few times as possible, IN YOUR OPINION, would there be a significant improvement in the performance of this subroutine? All in favor of rewrite, say AYE All opposed, say NAY (I'm testing some U2UG-Denver skills) MONTHLY.USAGE: CM=MONTH+LY.CNT FOR M=1 TO 12 IF PARMS(12)101,CM#'' OR PARMS(12)133,CM#'' OR PARMS(12)134,CM#'' THEN CUM(M)=PARMS(12)101,CM+PARMS(12)133,CM+PARMS(12)134,CM END IF PARMS(7)100,CM#'' OR PARMS(7)101,CM#'' OR PARMS(7)102,CM#'' THEN IF PARMS(7)100,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)100,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)101,CM END IF PARMS(7)101,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)101,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)133,CM END IF PARMS(7)102,CM#'' THEN CUMO(M)=CUMO(M)+PARMS(7)102,CM ELSE CUMO(M)=CUMO(M)+PARMS(12)134,CM END END CM=CM-1; IF CM=0 THEN CM=24 NEXT M RETURN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I dunno. If it works and the performance is
Re: [U2] Is this worth rewriting?
That is an object used in prelude. It is passed around everywhere. The question was how to make it faster. In a loop you want to eliminate redundant overhead to accomplish this. The way to stop that overhead in the reference to dynamic vars is to place them into single attr vars as Kevin suggested; thereby reducing the dynamic parsing that occurs automatically in the background. After the loop, THEN put them back in the object. You will see a SIGNIFICANT increase in AFishInSea with this simple task. I do it routinely ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] REMOVE() was Is This Worth Rewriting
I tried to drink the KoolAid and use REMOVE on some projects, but found a show stopper on UDT6.1. I cannot remember the specifics. Oh, I remember, In cases where you are addressing aligned mv's with your loop variable it was not saving you that much because you still need extract the other vars. Does that make sense? If you have 4 aligned mv's. You only gain on the 1st, but still have 3 extracts per iteration. It was cleaner just to keep the FOR loop. One more reason I am pushing to do my business logic in python where I have a whole lot more options in data structures. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [AD] RE: Git and U2
I have available U2-based SCM (Software Configuration Mgr)... called Ch. O Menu-driven O User-interface - Developer to specify change notes - no command-line hassle O Integrates with VOC the latest rev and file path O OSGI... Cross References Subs and their revs O Reports... O Where-Used... shows what data files are opened by what programs O Apps Listing O Subs Listing O Recent Changes O Integrates With an Action.Item AI program O Ninety-Day Try-And-Buy. O Licenses: One year, one seat, tech support Included. O Ch $299Non-profit $109 O AI $299 $109 O Ch AI $499 $199 --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [AD] RE: Git and U2
On 3/2/2011 5:43 PM, Bill Brutzman wrote: I have available U2-based SCM (Software Configuration Mgr)... calledCh. O Menu-driven O User-interface - Developer to specify change notes - no command-line hassle O Integrates with VOC the latest rev and file path O OSGI... Cross References Subs and their revs O Reports... O Where-Used... shows what data files are opened by what programs O Apps Listing O Subs Listing O Recent Changes O Integrates With an Action.ItemAI program O Ninety-Day Try-And-Buy. O Licenses: One year, one seat, tech support Included. OCh $299Non-profit $109 OAI $299 $109 OChAI $499 $199 --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Bill, is it SB+ aware? Does that license allow integration with other tools? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [AD] RE: Git and U2
Right now, Ch is not SB+ aware. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Wednesday, March 02, 2011 5:45 PM To: U2 Users List Subject: Re: [U2] [AD] RE: Git and U2 On 3/2/2011 5:43 PM, Bill Brutzman wrote: I have available U2-based SCM (Software Configuration Mgr)... calledCh. O Menu-driven O User-interface - Developer to specify change notes - no command-line hassle O Integrates with VOC the latest rev and file path O OSGI... Cross References Subs and their revs O Reports... O Where-Used... shows what data files are opened by what programs O Apps Listing O Subs Listing O Recent Changes O Integrates With an Action.ItemAI program O Ninety-Day Try-And-Buy. O Licenses: One year, one seat, tech support Included. OCh $299Non-profit $109 OAI $299 $109 OChAI $499 $199 --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Bill, is it SB+ aware? Does that license allow integration with other tools? ___ 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] REMOVE() was Is This Worth Rewriting
Yes. Your aligned multivalues are also referred to as dependent-controlling sets. You have one attribute controlling the placements of the values for the others. Nasty buggers, always bite. You have to grab them right behind the ears. -Original Message- From: Steve Romanow slestak...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, Mar 2, 2011 2:35 pm Subject: Re: [U2] REMOVE() was Is This Worth Rewriting I tried to drink the KoolAid and use REMOVE on some projects, but found a show stopper on UDT6.1. I cannot remember the specifics. Oh, I remember, In cases where you are addressing aligned mv's with your loop variable it was not saving you that much because you still need extract the other vars. Does that make sense? If you have 4 aligned mv's. You only gain on the 1st, but still have 3 extracts per iteration. It was cleaner just to keep the FOR loop. One more reason I am pushing to do my business logic in python where I have a whole lot more options in data structures. ___ 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] Is this worth rewriting?
From:David Wolverton The += I completely agree with. No arguments on that point at all. I've actually only adopted use of +=, -=, etc in Pick BASIC over the last few years. I've been concerned that older developers wouldn't recognize the syntax, and that it wasn't portable across Pick platforms or releases. I dunno how valid either of those concerns are or were, just passing along the thought... T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE to 007: IF (TEA : EAT : ATE) # '' THEN CUM(M) = TEA + EAT + ATE likewise, 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN to 011: IF (YAM : AMY : MYA) # '' THEN AU$0.02. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Thursday, 3 March 2011 11:47 AM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1BP44gKpel/56DrG1wRmlu33A3lhc6Vco/0.6 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
My druthers... IF (TEA + CAKE + ...) THEN ATE += TEA + CAKE + ... CASE @TRUE ;* finding CASE 1 is unintuitive use of a magic number / antithetical case statements may be obviated (for testing etc) by CASE @FALSE -Original Message- 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE to 007: IF (TEA : EAT : ATE) # '' THEN CUM(M) = TEA + EAT + ATE ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
If you are running UniData, you can also move the TEA, EAT, ATE, YAM, AMY MYA outside of the FOR M loop if you exclude CM. Inside you can than do TEACM = TEA1,CM, etc Of course, as stated by others, whether it is worth the changing/testing time cannot be known unless you have actually benchmarked this code to determine if it will make a meaningful difference. On the other hand, if you change it to actually make the variable names/code more meaningful so the next poor soul doesn't need to read in several times to understand it, then sure, go ahead. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Thursday, 3 March 2011 11:47 AM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ 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
Re: [U2] Git and U2
David My favorite is Perforce. It' not open source but a two user, five workspace version is free. I use one workspace on development and one on production so five is plenty for me. It is not MV aware but I've used it with Unidata, Universe and jBASE. It has command line and GUI interfaces for Windows, Linux and several others. Don From: DavidJMurray (mvdbs.com) nab...@mvdbs.com To: u2-users@listserver.u2ug.org Sent: Wed, March 2, 2011 3:18:37 PM Subject: [U2] Git and U2 Has anyone used Git and U2 - either UniVerse or Unidata - together? Or any other suggestions for a version control - open source is preferred? Thanks in advance, djm - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Git-and-U2-tp31053109p31053109.html Sent from the U2 - Users mailing list archive at Nabble.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] Is this worth rewriting?
try this, your loops are using too many conditionals. What kind of data is this, string, integer, etc? MONTHLY.USAGE: -- CM = MONTH + LY.CNT TEA = PARMS(12)101,CM EAT = PARMS(12)133,CM ATE = PARMS(12)134,CM FOR M = 1 TO 12 IF TEA+EAT+ATE '' THEN CUM(M) = TEA+EAT+ATE YAM = PARMS(7)100,CM AMY = PARMS(7)101,CM MYA = PARMS(7)102,CM IF YAM+AMY+MYA '' THEN IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE END CM -= 1 ; IF CM = 0 THEN CM = 24 NEXT M RETURN Date: Thu, 3 Mar 2011 13:38:27 +1100 From: dmc...@imb.com.au To: u2-users@listserver.u2ug.org Subject: Re: [U2] Is this worth rewriting? If you are running UniData, you can also move the TEA, EAT, ATE, YAM, AMY MYA outside of the FOR M loop if you exclude CM. Inside you can than do TEACM = TEA1,CM, etc Of course, as stated by others, whether it is worth the changing/testing time cannot be known unless you have actually benchmarked this code to determine if it will make a meaningful difference. On the other hand, if you change it to actually make the variable names/code more meaningful so the next poor soul doesn't need to read in several times to understand it, then sure, go ahead. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Thursday, 3 March 2011 11:47 AM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
I didn't realize the CM var could be used so I re-wrote it. This program logic looks horrible though, I would definitely re-write it with consideration of indexing some fields to make it run more efficient. Chris MONTHLY.USAGE: CM = MONTH+LY.CNT FOR M = 1 TO 12 TEA = PARMS(12)101,CM EAT = PARMS(12)133,CM ATE = PARMS(12)134,CM IF TEA+EAT+ATE # '' THEN CUM(M) = TEA+EAT+ATE YAM = PARMS(7)100,CM AMY = PARMS(7)101,CM MYA = PARMS(7)102,CM IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE CM -= 1 ; IF CM = 0 THEN CM = 24 NEXT M RETURN Date: Thu, 3 Mar 2011 13:38:27 +1100 From: dmc...@imb.com.au To: u2-users@listserver.u2ug.org Subject: Re: [U2] Is this worth rewriting? If you are running UniData, you can also move the TEA, EAT, ATE, YAM, AMY MYA outside of the FOR M loop if you exclude CM. Inside you can than do TEACM = TEA1,CM, etc Of course, as stated by others, whether it is worth the changing/testing time cannot be known unless you have actually benchmarked this code to determine if it will make a meaningful difference. On the other hand, if you change it to actually make the variable names/code more meaningful so the next poor soul doesn't need to read in several times to understand it, then sure, go ahead. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Thursday, 3 March 2011 11:47 AM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
All right, I just went ahead and rewrote this the way I would do it since I haven't written a single bit of code since I got laid off at the end of September. And I did it while my wife and I are watching Judge Judy - it was *fun* :-) Granted I can't use real var names since I don't know what these are, but using a simple var name replacement scheme, this illustrates what I would consider the least amount of overhead for this. A) reduced the overhead on the repetitive calls to over 100 attrs. The system needs to look at *every single byte* in the record until it gets to attr desired. If these are 25,000 byte records this would be a HUGE amount of needless throughput which you can calc by (iterations - 2) * average bytes to read before attr needed * number of times the statement is used in the loop B) Yup, got rid of the #. Not only does this make more sense, but # is REALLY doing two comparisons: and C) Got rid of the leading 7 digit indent to make it more readable D) I don't see the necessity of testing three vars to see if they aren't zero before adding them together. If they are zero, the equation will work. If they are not zero, the equation will work. I can see maybe doing that if the equation was doing any dividing to avoid the can't divide by zero error, but not on adding. E) I always make all my IF's block IF's to stub them out for future dev, as well as to make them easier to read. So I did that at the bottom even though it was just for one add stmt. F) My eyes are really getting old. I need spaces between VARs and operands so they don't smush together. So I spaced accordingly to make everything just a tad more readable as well. Now, this takes more lines of code. But many times more lines of code can be way faster than fewer lines of code especially if the extra lines of code are OUTSIDE of the loop. MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = PARMS(12)101 P12.133 = PARMS(12)133 P12.134 = PARMS(12)134 P7.100 = PARMS(7)100 P7.101 = PARMS(7)101 P7.102 = PARMS(7)102 FOR M = 1 TO 12 CUM(M) = P12.1011,CM + P12.1331,CM + P12.1341,CM IF P7.1001,CM = '' THEN CUMO(M) += P12.1011,CM END ELSE CUMO(M) += P7.1001,CM END IF P7.1011,CM = '' THEN CUMO(M) += P12.1331,CM END ELSE CUMO(M) += P7.1011,CM END IF P7.1021,CM = '' THEN CUMO(M) += P12.1341,CM END ELSE CUMO(M) += P7.1021,CM END CM -= 1 IF CM = 0 THEN CM = 24 END NEXT M PARMS(12)101 = P12.101 PARMS(12)133 = P12.133 PARMS(12)134 = P12.134 PARMS(7)100 = P7.100 PARMS(7)101 = P7.101 PARMS(7)102 = P7.102 RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Wednesday, March 02, 2011 4:47 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ 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] Is this worth rewriting?
#1 In a binary register, in machine code, there is no such thing as #. There is NOT and = which is two comparisons. Now, granted, there have been significant improvements in cpu's since I did machine code in 1975, so maybe that has changed... #2 Ummmhey, that's funny. I think I did that when I got to the part about the pictures of bedbugs in Judge Judy, which was really disgusting and made my brain fall out lol -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 7:30 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? 2 points of note for you. 1) In regards to B), I think I should just clarify that despite # also being able to be written as , is *not* 2 comparisons, but still one. 2) You don't need to reassign P* back into PARAMS after the loop since they are never updated. Cheers, Dan PS: Messing about with code would be a lot more fun than watching Judge Judy :) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single snip ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
#1 In x86 assembly, you use can use JE or JNE. So you do the comparison, then jump. How you jump (or don't jump) determines if it was an = or #. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:49 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? #1 In a binary register, in machine code, there is no such thing as #. There is NOT and = which is two comparisons. Now, granted, there have been significant improvements in cpu's since I did machine code in 1975, so maybe that has changed... #2 Ummmhey, that's funny. I think I did that when I got to the part about the pictures of bedbugs in Judge Judy, which was really disgusting and made my brain fall out lol -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 7:30 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? 2 points of note for you. 1) In regards to B), I think I should just clarify that despite # also being able to be written as , is *not* 2 comparisons, but still one. 2) You don't need to reassign P* back into PARAMS after the loop since they are never updated. Cheers, Dan PS: Messing about with code would be a lot more fun than watching Judge Judy :) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single snip ___ 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
Re: [U2] Is this worth rewriting?
A suggestion: Raise the @VM to @AM to improve dynamic array performance. Attribute lookups are way faster than value lookups, and you have already extracted the data to a new variable MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = RAISE(PARMS(12)101) P12.133 = RAISE(PARMS(12)133) P12.134 = RAISE(PARMS(12)134) P7.100 = RAISE(PARMS(7)100) P7.101 = RAISE(PARMS(7)101) P7.102 = RAISE(PARMS(7)102) FOR M = 1 TO 12 CUMO(M) = P12.101CM + P12.133CM + P12.134CM IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END NEXT M RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single bit of code since I got laid off at the end of September. And I did it while my wife and I are watching Judge Judy - it was *fun* :-) Granted I can't use real var names since I don't know what these are, but using a simple var name replacement scheme, this illustrates what I would consider the least amount of overhead for this. A) reduced the overhead on the repetitive calls to over 100 attrs. The system needs to look at *every single byte* in the record until it gets to attr desired. If these are 25,000 byte records this would be a HUGE amount of needless throughput which you can calc by (iterations - 2) * average bytes to read before attr needed * number of times the statement is used in the loop B) Yup, got rid of the #. Not only does this make more sense, but # is REALLY doing two comparisons: and C) Got rid of the leading 7 digit indent to make it more readable D) I don't see the necessity of testing three vars to see if they aren't zero before adding them together. If they are zero, the equation will work. If they are not zero, the equation will work. I can see maybe doing that if the equation was doing any dividing to avoid the can't divide by zero error, but not on adding. E) I always make all my IF's block IF's to stub them out for future dev, as well as to make them easier to read. So I did that at the bottom even though it was just for one add stmt. F) My eyes are really getting old. I need spaces between VARs and operands so they don't smush together. So I spaced accordingly to make everything just a tad more readable as well. Now, this takes more lines of code. But many times more lines of code can be way faster than fewer lines of code especially if the extra lines of code are OUTSIDE of the loop. MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = PARMS(12)101 P12.133 = PARMS(12)133 P12.134 = PARMS(12)134 P7.100 = PARMS(7)100 P7.101 = PARMS(7)101 P7.102 = PARMS(7)102 FOR M = 1 TO 12 CUM(M) = P12.1011,CM + P12.1331,CM + P12.1341,CM IF P7.1001,CM = '' THEN CUMO(M) += P12.1011,CM END ELSE CUMO(M) += P7.1001,CM END IF P7.1011,CM = '' THEN CUMO(M) += P12.1331,CM END ELSE CUMO(M) += P7.1011,CM END IF P7.1021,CM = '' THEN CUMO(M) += P12.1341,CM END ELSE CUMO(M) += P7.1021,CM END CM -= 1 IF CM = 0 THEN CM = 24 END NEXT M PARMS(12)101 = P12.101 PARMS(12)133 = P12.133 PARMS(12)134 = P12.134 PARMS(7)100 = P7.100 PARMS(7)101 = P7.101 PARMS(7)102 = P7.102 RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Wednesday, March 02, 2011 4:47 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003: FOR M = 1 TO 12 004: TEA = PARMS(12)101,CM 005: EAT = PARMS(12)133,CM 006: ATE = PARMS(12)134,CM 007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE 008: YAM = PARMS(7)100,CM 009: AMY = PARMS(7)101,CM 010: MYA = PARMS(7)102,CM 011: IF YAM # '' OR AMY # '' OR MYA # '' THEN 012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA 013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT 014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE 015: END 016: CM -= 1 ; IF CM = 0 THEN CM = 24 017: NEXT M 018: RETURN So I'd say AYE - or YEA, if you use meaningful variables Regards, Keith ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Oh yeah, assembly - no sweat, you could do that on an old IBM360 along with floating point math and hosts of really awesome and incredibly mind numbing complicated stuff. But non-relocateable machine code? You know, the stuff that's *really* doing the work? I've never seen any that could do a NOT and an = at the same time even on the 360. And with reduced instruction sets being all the rage, it's probably not been added, eh? In any event, it's not a significant enough to have any measurable effect on speed, but is easier to look at. Btw, the rumor was that the teacher that I had for year two of the 360 assembly, who used to write I/O routines in machine code for IBM at the time as his day job, lost his mind and sat in the corner laughing to himself before they finally gave him a padded suit. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 8:00 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? #1 In x86 assembly, you use can use JE or JNE. So you do the comparison, then jump. How you jump (or don't jump) determines if it was an = or #. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:49 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? #1 In a binary register, in machine code, there is no such thing as #. There is NOT and = which is two comparisons. Now, granted, there have been significant improvements in cpu's since I did machine code in 1975, so maybe that has changed... snip ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Nice! I tend to eschew RAISE and LOWER as they can cause really bummer problems if you forget to LOWER before stuffing back into a record and testing doesn't find it, and then it hits the live account and all hell breaks loose. But for stuff that doesn't go back into a record, that's pretty cool -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Wednesday, March 02, 2011 8:13 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? A suggestion: Raise the @VM to @AM to improve dynamic array performance. Attribute lookups are way faster than value lookups, and you have already extracted the data to a new variable MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = RAISE(PARMS(12)101) P12.133 = RAISE(PARMS(12)133) P12.134 = RAISE(PARMS(12)134) P7.100 = RAISE(PARMS(7)100) P7.101 = RAISE(PARMS(7)101) P7.102 = RAISE(PARMS(7)102) snip ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
Yes, in the real instruction that gets send down those long multi-stage pipe lines in our multi-core CPUs :) They take the same amount of clock cycles to compare if a 32bit/64 bit value is equal, or not equal. When values are compared it merely sets one of the many flags in the CPU. This binary flag is used to determine if it was equal or not, the only difference in the machine code is whether you perform an action if the flag is true or perform an action if the flag is false. This is as true in RISC processors as it is in CISC. But yes, this sort of optimisation is rarely needed. In fact, if you were to ever write the code in C/C++ the compiler would automatically optimise the machine code far better than most mere mortals could :) For some reason, you mentioning your teacher made me think of The Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 3:42 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? Oh yeah, assembly - no sweat, you could do that on an old IBM360 along with floating point math and hosts of really awesome and incredibly mind numbing complicated stuff. But non-relocateable machine code? You know, the stuff that's *really* doing the work? I've never seen any that could do a NOT and an = at the same time even on the 360. And with reduced instruction sets being all the rage, it's probably not been added, eh? In any event, it's not a significant enough to have any measurable effect on speed, but is easier to look at. Btw, the rumor was that the teacher that I had for year two of the 360 assembly, who used to write I/O routines in machine code for IBM at the time as his day job, lost his mind and sat in the corner laughing to himself before they finally gave him a padded suit. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 8:00 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? #1 In x86 assembly, you use can use JE or JNE. So you do the comparison, then jump. How you jump (or don't jump) determines if it was an = or #. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:49 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? #1 In a binary register, in machine code, there is no such thing as #. There is NOT and = which is two comparisons. Now, granted, there have been significant improvements in cpu's since I did machine code in 1975, so maybe that has changed... snip ___ 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
Re: [U2] Is this worth rewriting?
The other thing to try, though not really a performance improvement, is the following: Replace: IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END with CUMO(M) += (IF P7.100CM = '' THEN P12.101CM ELSE P7.100CM) CUMO(M) += (IF P7.101CM = '' THEN P12.133CM ELSE P7.101CM) CUMO(M) += (IF P7.102CM = '' THEN P12.134CM ELSE P7.102CM) Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Thursday, 3 March 2011 3:13 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? A suggestion: Raise the @VM to @AM to improve dynamic array performance. Attribute lookups are way faster than value lookups, and you have already extracted the data to a new variable MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = RAISE(PARMS(12)101) P12.133 = RAISE(PARMS(12)133) P12.134 = RAISE(PARMS(12)134) P7.100 = RAISE(PARMS(7)100) P7.101 = RAISE(PARMS(7)101) P7.102 = RAISE(PARMS(7)102) FOR M = 1 TO 12 CUMO(M) = P12.101CM + P12.133CM + P12.134CM IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END NEXT M RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single bit of code since I got laid off at the end of September. And I did it while my wife and I are watching Judge Judy - it was *fun* :-) Granted I can't use real var names since I don't know what these are, but using a simple var name replacement scheme, this illustrates what I would consider the least amount of overhead for this. A) reduced the overhead on the repetitive calls to over 100 attrs. The system needs to look at *every single byte* in the record until it gets to attr desired. If these are 25,000 byte records this would be a HUGE amount of needless throughput which you can calc by (iterations - 2) * average bytes to read before attr needed * number of times the statement is used in the loop B) Yup, got rid of the #. Not only does this make more sense, but # is REALLY doing two comparisons: and C) Got rid of the leading 7 digit indent to make it more readable D) I don't see the necessity of testing three vars to see if they aren't zero before adding them together. If they are zero, the equation will work. If they are not zero, the equation will work. I can see maybe doing that if the equation was doing any dividing to avoid the can't divide by zero error, but not on adding. E) I always make all my IF's block IF's to stub them out for future dev, as well as to make them easier to read. So I did that at the bottom even though it was just for one add stmt. F) My eyes are really getting old. I need spaces between VARs and operands so they don't smush together. So I spaced accordingly to make everything just a tad more readable as well. Now, this takes more lines of code. But many times more lines of code can be way faster than fewer lines of code especially if the extra lines of code are OUTSIDE of the loop. MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = PARMS(12)101 P12.133 = PARMS(12)133 P12.134 = PARMS(12)134 P7.100 = PARMS(7)100 P7.101 = PARMS(7)101 P7.102 = PARMS(7)102 FOR M = 1 TO 12 CUM(M) = P12.1011,CM + P12.1331,CM + P12.1341,CM IF P7.1001,CM = '' THEN CUMO(M) += P12.1011,CM END ELSE CUMO(M) += P7.1001,CM END IF P7.1011,CM = '' THEN CUMO(M) += P12.1331,CM END ELSE CUMO(M) += P7.1011,CM END IF P7.1021,CM = '' THEN CUMO(M) += P12.1341,CM END ELSE CUMO(M) += P7.1021,CM END CM -= 1 IF CM = 0 THEN CM = 24 END NEXT M PARMS(12)101 = P12.101 PARMS(12)133 = P12.133 PARMS(12)134 = P12.134 PARMS(7)100 = P7.100 PARMS(7)101 = P7.101 PARMS(7)102 = P7.102 RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Keith Johnson [DATACOM] Sent: Wednesday, March 02, 2011 4:47 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] Is this worth rewriting? Agreed that the dimensioned extract wouldn't make much difference, still the attributes numbers are quite high. The code below goes from 15 extracts maximum per for-next loop to 6. I can't help but think this might mean something if it takes 90 minutes to run. 001: MONTHLY.USAGE: 002: CM = MONTH + LY.CNT 003:
Re: [U2] Is this worth rewriting?
Actually, (at least in UniData) it is a performance improvement :). It has to do with how BASIC compiles the code into the object file and tags each line with a line number. Each time it jumps to a line or progresses to the next it must process the line number to update it for when it shows errors/warnings etc. By reducing the number of lines the instructions are on, you actually end up with both smaller object code and faster execution. How much though depends on how tight your looping and all but 99%+ cases the difference is dwarfed by disk access times, etc as to make it not worth it as a human optimisation task. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Thursday, 3 March 2011 4:16 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? The other thing to try, though not really a performance improvement, is the following: Replace: IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END with CUMO(M) += (IF P7.100CM = '' THEN P12.101CM ELSE P7.100CM) CUMO(M) += (IF P7.101CM = '' THEN P12.133CM ELSE P7.101CM) CUMO(M) += (IF P7.102CM = '' THEN P12.134CM ELSE P7.102CM) Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Thursday, 3 March 2011 3:13 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? A suggestion: Raise the @VM to @AM to improve dynamic array performance. Attribute lookups are way faster than value lookups, and you have already extracted the data to a new variable MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = RAISE(PARMS(12)101) P12.133 = RAISE(PARMS(12)133) P12.134 = RAISE(PARMS(12)134) P7.100 = RAISE(PARMS(7)100) P7.101 = RAISE(PARMS(7)101) P7.102 = RAISE(PARMS(7)102) FOR M = 1 TO 12 CUMO(M) = P12.101CM + P12.133CM + P12.134CM IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END NEXT M RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single bit of code since I got laid off at the end of September. And I did it while my wife and I are watching Judge Judy - it was *fun* :-) Granted I can't use real var names since I don't know what these are, but using a simple var name replacement scheme, this illustrates what I would consider the least amount of overhead for this. A) reduced the overhead on the repetitive calls to over 100 attrs. The system needs to look at *every single byte* in the record until it gets to attr desired. If these are 25,000 byte records this would be a HUGE amount of needless throughput which you can calc by (iterations - 2) * average bytes to read before attr needed * number of times the statement is used in the loop B) Yup, got rid of the #. Not only does this make more sense, but # is REALLY doing two comparisons: and C) Got rid of the leading 7 digit indent to make it more readable D) I don't see the necessity of testing three vars to see if they aren't zero before adding them together. If they are zero, the equation will work. If they are not zero, the equation will work. I can see maybe doing that if the equation was doing any dividing to avoid the can't divide by zero error, but not on adding. E) I always make all my IF's block IF's to stub them out for future dev, as well as to make them easier to read. So I did that at the bottom even though it was just for one add stmt. F) My eyes are really getting old. I need spaces between VARs and operands so they don't smush together. So I spaced accordingly to make everything just a tad more readable as well. Now, this takes more lines of code. But many times more lines of code can be way faster than fewer lines of code especially if the extra lines of code are OUTSIDE of the loop. MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = PARMS(12)101 P12.133 = PARMS(12)133 P12.134 = PARMS(12)134 P7.100 = PARMS(7)100 P7.101 = PARMS(7)101 P7.102 = PARMS(7)102 FOR M = 1 TO 12 CUM(M) = P12.1011,CM + P12.1331,CM + P12.1341,CM IF P7.1001,CM = '' THEN CUMO(M) += P12.1011,CM END ELSE CUMO(M) += P7.1001,CM END IF P7.1011,CM = '' THEN CUMO(M) += P12.1331,CM END ELSE CUMO(M) += P7.1011,CM END IF P7.1021,CM
Re: [U2] Is this worth rewriting?
Ok, just to be clear, there is a difference between an interpreted instruction and a hard wired machine code instruction. An actual BRANCH ON NOTEQUAL operand ANALOG *circuit* must be etched in silicon at the flip-flop level before it's a machine code instruction. So like, not impossible. But here's the cool point. Digital devices, are implemented with capacitors, transistors, resistors. Analog devices. I dunno, just makes me laugh every time I think about the fact that at the lowest level there is really no such thing as digital because electricity is analog lol Speaking of analog (how's that for a segue?), all guitar pros still use tube amps. I make tube amps! It's so different to work with 500 volt tubes and transformers than programming. [shameless brag] Here's an upcoming starlet using one of the Hiwatt DR504 clone amps I built by hand for her playing with Earl Slick (David Bowie's guitarist after Stevie Ray got himself fired) http://www.youtube.com/watch?v=wTx1Pi1_o4c [/shameless brag] -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 9:10 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? Yes, in the real instruction that gets send down those long multi-stage pipe lines in our multi-core CPUs :) They take the same amount of clock cycles to compare if a 32bit/64 bit value is equal, or not equal. When values are compared it merely sets one of the many flags in the CPU. This binary flag is used to determine if it was equal or not, the only difference in the machine code is whether you perform an action if the flag is true or perform an action if the flag is false. This is as true in RISC processors as it is in CISC. But yes, this sort of optimisation is rarely needed. In fact, if you were to ever write the code in C/C++ the compiler would automatically optimise the machine code far better than most mere mortals could :) For some reason, you mentioning your teacher made me think of The Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html snip ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
That *is* cool! I still remember helping my dad with his tube tester. He'd repair radios and TVs for his friends from work. In return he got their rejects for parts. We never had to buy a TV... There's something about the sound from an old tube radio that you can't beat! Sometimes when I think about what's actually going on, physically, in a computer I'm amazed they work as well as they do! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Wednesday, March 02, 2011 10:05 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? Ok, just to be clear, there is a difference between an interpreted instruction and a hard wired machine code instruction. An actual BRANCH ON NOTEQUAL operand ANALOG *circuit* must be etched in silicon at the flip-flop level before it's a machine code instruction. So like, not impossible. But here's the cool point. Digital devices, are implemented with capacitors, transistors, resistors. Analog devices. I dunno, just makes me laugh every time I think about the fact that at the lowest level there is really no such thing as digital because electricity is analog lol Speaking of analog (how's that for a segue?), all guitar pros still use tube amps. I make tube amps! It's so different to work with 500 volt tubes and transformers than programming. [shameless brag] Here's an upcoming starlet using one of the Hiwatt DR504 clone amps I built by hand for her playing with Earl Slick (David Bowie's guitarist after Stevie Ray got himself fired) http://www.youtube.com/watch?v=wTx1Pi1_o4c [/shameless brag] -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Wednesday, March 02, 2011 9:10 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? Yes, in the real instruction that gets send down those long multi-stage pipe lines in our multi-core CPUs :) They take the same amount of clock cycles to compare if a 32bit/64 bit value is equal, or not equal. When values are compared it merely sets one of the many flags in the CPU. This binary flag is used to determine if it was equal or not, the only difference in the machine code is whether you perform an action if the flag is true or perform an action if the flag is false. This is as true in RISC processors as it is in CISC. But yes, this sort of optimisation is rarely needed. In fact, if you were to ever write the code in C/C++ the compiler would automatically optimise the machine code far better than most mere mortals could :) For some reason, you mentioning your teacher made me think of The Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html snip ___ 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] Is this worth rewriting?
Which is where the -T option on the BASIC statement comes in handy, though debugging then become s much harder. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath Sent: Thursday, 3 March 2011 4:24 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? Actually, (at least in UniData) it is a performance improvement :). It has to do with how BASIC compiles the code into the object file and tags each line with a line number. Each time it jumps to a line or progresses to the next it must process the line number to update it for when it shows errors/warnings etc. By reducing the number of lines the instructions are on, you actually end up with both smaller object code and faster execution. How much though depends on how tight your looping and all but 99%+ cases the difference is dwarfed by disk access times, etc as to make it not worth it as a human optimisation task. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Thursday, 3 March 2011 4:16 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? The other thing to try, though not really a performance improvement, is the following: Replace: IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END with CUMO(M) += (IF P7.100CM = '' THEN P12.101CM ELSE P7.100CM) CUMO(M) += (IF P7.101CM = '' THEN P12.133CM ELSE P7.101CM) CUMO(M) += (IF P7.102CM = '' THEN P12.134CM ELSE P7.102CM) Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Thursday, 3 March 2011 3:13 PM To: U2 Users List Subject: Re: [U2] Is this worth rewriting? A suggestion: Raise the @VM to @AM to improve dynamic array performance. Attribute lookups are way faster than value lookups, and you have already extracted the data to a new variable MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = RAISE(PARMS(12)101) P12.133 = RAISE(PARMS(12)133) P12.134 = RAISE(PARMS(12)134) P7.100 = RAISE(PARMS(7)100) P7.101 = RAISE(PARMS(7)101) P7.102 = RAISE(PARMS(7)102) FOR M = 1 TO 12 CUMO(M) = P12.101CM + P12.133CM + P12.134CM IF P7.100CM = '' THEN CUMO(M) += P12.101CM END ELSE CUMO(M) += P7.100CM END IF P7.101CM = '' THEN CUMO(M) += P12.133CM END ELSE CUMO(M) += P7.101CM END IF P7.102CM = '' THEN CUMO(M) += P12.134CM END ELSE CUMO(M) += P7.102CM END NEXT M RETURN -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen E. Elwood Sent: Thursday, 3 March 2011 2:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? All right, I just went ahead and rewrote this the way I would do it since I haven't written a single bit of code since I got laid off at the end of September. And I did it while my wife and I are watching Judge Judy - it was *fun* :-) Granted I can't use real var names since I don't know what these are, but using a simple var name replacement scheme, this illustrates what I would consider the least amount of overhead for this. A) reduced the overhead on the repetitive calls to over 100 attrs. The system needs to look at *every single byte* in the record until it gets to attr desired. If these are 25,000 byte records this would be a HUGE amount of needless throughput which you can calc by (iterations - 2) * average bytes to read before attr needed * number of times the statement is used in the loop B) Yup, got rid of the #. Not only does this make more sense, but # is REALLY doing two comparisons: and C) Got rid of the leading 7 digit indent to make it more readable D) I don't see the necessity of testing three vars to see if they aren't zero before adding them together. If they are zero, the equation will work. If they are not zero, the equation will work. I can see maybe doing that if the equation was doing any dividing to avoid the can't divide by zero error, but not on adding. E) I always make all my IF's block IF's to stub them out for future dev, as well as to make them easier to read. So I did that at the bottom even though it was just for one add stmt. F) My eyes are really getting old. I need spaces between VARs and operands so they don't smush together. So I spaced accordingly to make everything just a tad more readable as well. Now, this takes more lines of code. But many times more lines of code can be way faster than fewer lines of code especially if the extra lines of code are OUTSIDE of the loop. MONTHLY.USAGE: CM = MONTH + LY.CNT P12.101 = PARMS(12)101 P12.133 = PARMS(12)133 P12.134 =
Re: [U2] Is this worth rewriting?
The parens are redundant since concat is a higher precedence than Not Also how about If YAM:AMY:MYA IS NOT(NULL) THEN more intuitive :)~~ In a message dated 3/2/2011 4:54:51 P.M. Pacific Standard Time, brian.whiteh...@pentanasolutions.com writes: 011: IF (YAM : AMY : MYA) # '' THEN ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Is this worth rewriting?
You my friend get the micro-management award for this thread. In a message dated 3/2/2011 9:24:18 P.M. Pacific Standard Time, dmc...@imb.com.au writes: Actually, (at least in UniData) it is a performance improvement :). It has to do with how BASIC compiles the code into the object file and tags each line with a line number. Each time it jumps to a line or progresses to the next it must process the line number to update it for when it shows errors/warnings etc. By reducing the number of lines the instructions are on, you actually end up with both smaller object code and faster execution. How much though depends on how tight your looping and all but 99%+ cases the difference is dwarfed by disk access times, etc as to make it not worth it as a human optimisation task. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
