On Sun, 14 Sep 2008, Art Eschenlauer wrote:
> Clint,
>
> You have understood my question and concisely phrased my concern ("Icon's
> built-in hash function is useless for sets, because sets are mutable").
> Choice B, or a variant of it (defining my own hash for a set, and
> maintaining a table with hashes as keys and sets as values), was all that
> I could come up with as an alternative to using seteq( ).
>
>
>
> Hugh,
>
Roughly counting these then:
> Here is a brief concrete summary of the problem:
> - There are hundreds of computers.
1E3
> - Each computer has a configuration consisting of a combination of
> versions of several dozen configuration items.
1E5
> - Each configuration item is defined by a unique id and a path to where a
> file may be located on a computer.
That ends up as a unique id, whatever size, it maps to a number.
> - Each configuration item may be absent or may be one of up to a dozen
> versions.
1E6
> - Each version of a configuration item is distinguished (from other
> versions of the same configuration item) by its file size and last
> modification date.
File size is 64 bits these days, and up until 2038 time is 32 bit.
So expanding those to positions in a bit array is not possible.
Reducing "time" to "date" helps, that's much easier because going back to
the dawn of computing there can only be about 26000 days. And if
configuration files aren't too big (10K) this is more manageable (than
assuming a terabyte each!).
> - I want to know all of the configurations, how many there are of each,
> and for each configuration, which computers have it.
Then I think a bit array for each computer should fit in about a megabyte,
circa 100MB for the lot, and they'd be compressible when not in use.
Then it comes back to the hole (0) or slot (U) in an index card
OUOOUOU
You push your knitting needles through, metaphorically of course ;-)
pick them up and you have the cards that match.
>
> Right now, I am fetching the configurations, reading them into tables of a
> relational database, and performing SQL queries to get the information
> that I want. But this approach takes a lot of storage, and every time
How much, against my estimate?
> that I want to add a new file, I have to rewrite a bunch of queries. So,
In this system adding a new file would be flipping a bit in a megabyte
file. Or 8MB each if you keep them as text. But SQL can handle bits
IIRC. I've worked with it, but don't consider myself fluent. It might
be quicker to use a big database of bits than doing this in Icon, but
maybe speed faster then so much doesn't matter.
> I was trying for a more elegant solution in Icon.
>
Hugh
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
