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,
Here is a brief concrete summary of the problem:
- There are hundreds of computers.
- Each computer has a configuration consisting of a combination of
versions of several dozen configuration items.
- Each configuration item is defined by a unique id and a path to where a
file may be located on a computer.
- Each configuration item may be absent or may be one of up to a dozen
versions.
- Each version of a configuration item is distinguished (from other
versions of the same configuration item) by its file size and last
modification date.
- I want to know all of the configurations, how many there are of each,
and for each configuration, which computers have it.
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
that I want to add a new file, I have to rewrite a bunch of queries. So,
I was trying for a more elegant solution in Icon.
On Sun, September 14, 2008 12:52 pm, Clinton Jeffery said:
> I liked Hugh's answers (and questions) in reply to your question. Perhaps
> I
> can
> add a little value or a different perspective.
>
> It would be easy to add access to Icon's built-in hash function, there is
> probably
> an IPL procedure which does the same thing, but Icon's built-in hash
> function
> is useless for sets, because sets are mutable. If you insert a set A into
> a
> set
> of sets G, and then insert a new member into set A, how would hashing
> work?
> Instead of hashing on the aggregate of the contents of structures, Icon
> and
> Unicon
> just hash on their reference (pointer) or serial #, and if a later set
> happens to have
> the same size and contents, hashing (and the member() function) do not
> consider
> them to match.
>
> Some options: A) we could all get together and implement immutable sets
> (and
> other
> structure types) for which hashing on contents would be safe. B) map your
> sets down onto
> another type such as strings or bit vectors which can be hashed. C) get
> real fancy, and
> modify the existing set type to behave in some reasonable way when
> handling
> elements
> that are sets, or other structure types (but this would be hard to sell to
> the community).
> I guess in the past I have used Option B with reasonable success, but I am
> not claiming
> it will be cheap or trivial. Others may have other good suggestions, like
> Hugh did.
>
> Cheers,
> Clint
>
-------------------------------------------------------------------------
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
