Practical Array Processing: Dynamic Arrays

[RingerSoftware]

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
** This thread discusses the Content article: Practical Array Processing: Dynamic Arrays0

[rockym@ccgov.net]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
Chris, The problem is that he is only allocating the space for the number of elements - even though he defined the data structure to handle 1,000 elements. If you use the %sizeof he'd allocate space for nstores # of 1,000 element arrays, not nstores # of elements. IOW - if you made the change you offered, for 30 nStores you'd allocate 30,000 elements, rather than the 30 that is desired. Also, reading through the file twice seems counterproductive. How about using %REALLOC after each read, allowing the array to grow as you go? You could have it allocate memory every ten elements to reduce the # of times this is done (or 50 or whatever). To me, it's not good programming practice. To not deallocate memory because it doesn't fit his personal style (allocate with a BIF %ALLOC, dellocate with an opcode DEALLOC ptr) is counterproductive - on one hand you're presumably worried about memory space being used while not doing proper cleanup of memory is just silly. Somebody will look at that code and get confused on what the intended objective is and screw it up by something like putting in the %Sizeof as you suggest. You're better off just having a 1,000 element array than to play games such as this. It isn't straightforward and self-documenting.

[RingerSoftware]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
Rocky, %Size like I suggested only gets the size of one element. To get the total array size, you would need to specify %Size(aStores:*ALL); Chris

[rockym@ccgov.net]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
Chris, Thanks for the correction. After looking it up you are correct. However, I still think that this really isn't good programming practice for the other reasons stated.

[RingerSoftware]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
Rocky, I agree. I'd bump it (%realloc) by 50 or 100 elements at a time, in one read loop. In all actuality, there's really nothing wrong with just going with DIM(1000) and forgetting about it. I can allocate 16 Meg of RAM in RPG about 0.001 seconds, so a DIM(1000) of 30 bytes is *nothing* in terms of CPU usage and speed (and use %subarr or the "# of elements to search" parm). Joe was just demonstrating a technique. We get to chose where to apply it and not apply it. (Thanks Joe) Chris

[J.Pluta]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
You're right of course, Chris. I was thinking about doing exactly what you said, and then something else popped up and I forgot completely. Thanks for pointing it out!!

[J.Pluta]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
I'll give you the DEALLOC argument, although I thought I was pretty clear about the options. I still think there's a point to be made as to how you release memory, especially if you're in ACTGRP(*NEW), but that's a different discussion. I should have just put in the DEALLOC and then made my arguments. As to reading through the file twice, while I agree that in this trivial example it doesn't make as much sense, the technique is actually pretty powerful especially in SQL where you can get the number of records using a COUNT(*) and then read all the records in one fell swoop (which I hope to show in a subsequent tip). As to being potentially confusing, while simplicity is good complexity is sometimes required. If a technique is useful but non-intuitive, that's what comments are for. I'm not a big believer in "self-documenting" code. That's not to say that I advocate writing purposely obtuse code; I like code that is concise and readable. But I don't worry about the code being difficult when needed; we are after all programmers, and if it was easy everyone could do it .

[rockym@ccgov.net]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **

But I don't worry about the code being difficult when needed; we are after all programmers, and if it was easy everyone could do it .

LOL - I often say "If it were easy, any ol' schmuck could do it!" I realize that SQL can easily give record counts and what not. I'm just trying to figure out what the real benefit is. As Chris mentioned you can allocate a huge amount of memory very quickly, so where do you see the benefit of going through this process rather than simply allocating the memory? In my mind, there has to be some fairly substantial gains in order to not be concerned with being difficult to read. Sometimes we can be penny wise and dollar foolish so to speak, such as multiplying the date by an obtuse number (10000.01) in order to move the year around. While functional it's not clear what the goal is, it takes a performance hit, and since it took advantage of a quirk it had forward compatability issues - ie free format RPG. Penny wise, dollar foolish. I know your code here is MUCH better than that, just illustrating how we can sometimes be "clever" and not be as productive as we had hoped. And while SQL does return the COUNT - it still requires reading the file through... granted it is usually done very quickly, but I would think that allocating memory is still faster. Could you give an example where this process would be beneficial?

[aglauser]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
I'm not sure that COUNT always reads the whole file, probably depends on selection criteria, available metadata and indices. As for where this is useful, any time that making a reasonable guess as to how many elements are 'more than enough' is very difficult or impossible. I find that processing data coming in from trading partners is an common application area where this makes sense. It's difficult to predict when some change in one of the businesses involved may lead to a sudden spike in transactions. When writing code with reuseablity in mind, reducing arbitrary limits can increase the chance for that code to be used in unexpected ways later on.

[efnkay]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
Interestingly the following two statements produce the same value for count(*)... SELECT COUNT(*) FROM FILENAME SELECT COUNT(*) FROM FILENAME FETCH FIRST 10 ROWS ONLY However this statement will just return the first 10 rows. SELECT * FROM FILENAME FETCH FIRST 10 ROWS ONLY

[efnkay]

Re:Practical Array Processing: Dynamic Arrays

** This thread discusses the article: Practical Array Processing: Dynamic Arrays **
You get it...??? The first two statements only produce one row in the result set, while the 3rd statement produces a row in the result set for each record in the table...