[Chicken-users] Nested hash-tables, and so on..

2014-02-09 Thread mfv
Hi, 

I've been fooling around a bit with chicken, and now I am on towards a small
project. I have a question regarding the performance of list and
hash-tables.

I plan to use nested hash tables as a data structure e.g.

hash-table1
  |
  key1
 |
 hash-table2
   |
   key2
  |
  list/string/some data

Are there objections to such a nested hash table structure e.g. should one
keep it as flat as possible and use multiple hash-table is parallel  in order 
to maximize performance?

Regards, 

mfv






 

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Nested hash-tables, and so on..

2014-02-09 Thread .alyn.post.
On Sun, Feb 09, 2014 at 03:29:09PM +0100, mfv wrote:
 Hi, 
 
 I've been fooling around a bit with chicken, and now I am on towards a small
 project. I have a question regarding the performance of list and
 hash-tables.
 
 I plan to use nested hash tables as a data structure e.g.
 
 hash-table1
   |
   key1
  |
  hash-table2
|
key2
   |
   list/string/some data
 
 Are there objections to such a nested hash table structure e.g. should one
 keep it as flat as possible and use multiple hash-table is parallel  in order 
 to maximize performance?
 

In non-scheme languages, I use this technique a lot.  It's a poor
man's struct, and when you don't exactly know what problem you're
solving yet, that's precisely the data structure you need.

If you're worried about multiple hash table lookups, you can create
a composite key: pick a character/object that won't appear in key1..n,
and use it as a separator, joining and splitting your key to convert
it to/from it's composite.  I've rarely used this technique, compared
to the above above nested hash tables, so I suspect that nested
hashing will be adequate to solving the problem you have in mind.

I don't believe there is anything fundamentally wrong with your
approach.

-a
-- 
my personal website: http://c0redump.org/

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Nested hash-tables, and so on..

2014-02-09 Thread Kon Lovett

On Feb 9, 2014, at 11:12 AM, .alyn.post. alyn.p...@lodockikumazvati.org wrote:

 On Sun, Feb 09, 2014 at 03:29:09PM +0100, mfv wrote:
 Hi, 
 
 I've been fooling around a bit with chicken, and now I am on towards a small
 project. I have a question regarding the performance of list and
 hash-tables.
 
 I plan to use nested hash tables as a data structure e.g.
 
 hash-table1
  |
  key1
 |
 hash-table2
   |
   key2
  |
  list/string/some data
 
 Are there objections to such a nested hash table structure e.g. should one
 keep it as flat as possible and use multiple hash-table is parallel  in 
 order to maximize performance?
 
 
 In non-scheme languages, I use this technique a lot.  It's a poor
 man's struct, and when you don't exactly know what problem you're
 solving yet, that's precisely the data structure you need.
 
 If you're worried about multiple hash table lookups, you can create
 a composite key: pick a character/object that won't appear in key1..n,
 and use it as a separator, joining and splitting your key to convert
 it to/from it's composite.  I've rarely used this technique, compared
 to the above above nested hash tables, so I suspect that nested
 hashing will be adequate to solving the problem you have in mind.

Any Scheme object can be hashed w/ the SRFI 69 equal?-hash function. So a 
composite key represented as a pair/list, vector, or record is feasible. 

 
 I don't believe there is anything fundamentally wrong with your
 approach.
 
 -a
 -- 
 my personal website: http://c0redump.org/
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Nested hash-tables, and so on..

2014-02-09 Thread mfv
Hi folks, 

thanks for the comments and suggestions. I will go forward with nested
hash-tables then and have a look at composite keys. (=

Cheers! 

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users