| battlesquid | i think you're right, but when generating all possible groups we need to store the priorities to know which is better |
| xtknight | once we figure out best groups, priorities can be discarded, no? |
| battlesquid | yes |
| xtknight | so an array (16 bytes total with 2 byte elements), would look like {560, 1007, 570, 1007, 810, 1007, 870, 1007} (id[0], class[0], id[1], class[1], id[n], class[n]) |
| battlesquid | xtknight, i may have misunderstood you - the memory required for the processing is what i'd like to know... xtknight, i assumed finite state meant "in total when program done" or similar (not native English speaker) |
| xtknight | that wont be any significant amount. we will be putting and discarding things in memory about a billion times, which means the CPU will be hitting its L2 cache very often. very little will go on especially if you use an optimizing compiler (which consists of most compilers) |
| Cale | The memory use will vary *greatly* depending on which algorithm you decide to use. |
| xtknight | battlesquid, oh battlesquid, not accumulated |
| battlesquid | xtknight, the script is written in Perl (if that's useful) |
| xtknight | ahh hmm |
| Cale | It's not worth worrying about the difference between integer representation types until you know what it is that you're actually going to do. |
| xtknight | battlesquid, again i think the easiest thing to do is "just try it" (tm) i dont believe that the amoutn of required memory will be anything out of the ordinary |
| Cale | Let's see if I can even brute force the number of possible groups, let alone the best one :) |
| Olathe | That depends on the algorithm, as Cale said. |
| battlesquid | let's leave memory for a while |
| xtknight | memory is constantly being used, but it is constantly being discarded. from my experience there is no reason any reasonably modern computer shouldn't be able to perform a problem like that which is why i said you shoul djust give it a try. im about 95% confident that it will work just fine |
| battlesquid | xtknight, it's about how much we need to hold at at the same time |
| xtknight | and not require anything insane that depends on the data if it finds four perfect candidates within the first four iterations, then that's the best case heard of big O-notation |
| battlesquid | yes, so i want to figure out if i can use a hash or if i will get combinatorial explosion |
| xtknight | basically you want, in the Worst-Case, the amount of memory required for such an operation |
| battlesquid | yes |
| xtknight | i believe it wont be more than 2bytes*(number of list items)*3columns + (16bytes per group*NumberOfPossibleGroups) , and it could possibly be less than that we do need to find out the number of possible groups, then |
| battlesquid | or rather just how many groups can be made (we'll need that first anyway) xtknight, yes :) |
| xtknight | well is there something we do know about the maximum possible of groups? i dang wel lknow there cant be a billion, let's try and limit that |
| Olathe | Umm, it's huge. |
| battlesquid | well, order is like before unimportant (so that's imiting it) *limiting |
| xtknight | ya hmm |
| battlesquid | and employees on group=4, courses on group=4 (actually these are params) |
| xtknight | i believe i made an error though. there is no reason (16*numberofPossibleGroups) would be in memory all at once. because probably only 0.1% of those groups would work, right? |