@novinosrin wrote:
@Tom Thank you Sir for the note. I'm afraid if we do not include the data portion, the hash object compile/execution time operaton anyway does an automatic inclusion of keys as data too consequently doubling the hash entry length and memory footprint;
For example; To test what's in hash table , I added the output method to your code to view the contents
data want ;
set have end=z;
by id ;
if _n_=1 then do;
dcl hash h() ;
h.definekey('id','ch') ;
h.definedone() ;
end;
if first.id then count=0;
count+(0=h.add());
if z then h.output(dataset:'whats_in_hash_table');
run;
You would notice Id and ch combo are populated as data values in hash too confirming my initial point.-whats_in_hash_table
I don't really know how hash tables are stored in memory, but they obviously need to know the keys in order for them to work. So adding data variables also will by definition take more space. Your test of what gets written to an output dataset probably has little to do with what is actually stored in memory.
Secondly, your boolean approach to increment count is great had ch been sorted i'd think, but i'm afraid we would need the count previously enumerated parked somewhere to retrieve and replace be it in a hash table or an array. Methinks this where OP prolly was perhaps stuck.
Not sure what you point is. The normal variable COUNT has the current count. Whether more logic is needed or not depends on what the original question actually wants.
Thirdly, Clear() helps in freeing up memory after processing each by group. A way to manage memory. The combo idea of ID and CH as opposed to just CH helps testing and debugging effectively since visualizing the contents of hash tables makes it comfy to know what's going on.
PS The best fun tricky part of hashes that cause confusion is, when the keys and data portion are the same , the data portion alone can be modified. 🙂
If you are going to clear the hash after each ID group then there is no need to store the ID in the hash.
... View more
