AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 0 |
r3wp | 11 |
total: | 11 |
results window for this page: [start: 1 end: 11]
world-name: r3wp
Group: Rebol School ... Rebol School [web-public] | ||
Janko: 8-Feb-2009 | it is normal that hash! will only hash "keys" of assoc on first level, if you want on sublevels you can iterate the list and turn it into hashes acordingly .. if you have a lot of data hash is a lot faster 650x in this test http://www.rebol.com/article/0020.html | |
Group: !REBOL3-OLD1 ... [web-public] | ||
BrianH: 3-May-2006 | Sometimes I return a hash index as a query result set, for database-like functions. If I had to use an assoc instead I'm sure it would be fine as long as select was still O(1) like a hash. | |
BrianH: 3-May-2006 | Most of the time I use it like an assoc, or like a fully indexed table. | |
BrianH: 3-May-2006 | The main advantage a hash has over an assoc is that you aren't limited to simple key-value records, you can use longer records. | |
BrianH: 3-May-2006 | I would want an assoc to be able to have any string type as a key and words as well, at least. | |
Ladislav: 3-May-2006 | The main advantage a hash has over an assoc is that you aren't limited to simple key-value records, you can use longer records. - yes, that is the domain where hash! should be better | |
BrianH: 3-May-2006 | Still, if assocs are drastically faster it would be worth it. I could use blocks or lists and assoc indexes if I need them. | |
BrianH: 3-May-2006 | Assoc indexes to lists would be useful, as useful as I've found hash indexes to lists to be. I'd use hashes and lists more often if block parsing worked on them. | |
BrianH: 4-May-2006 | Jamie, that was referring to using a hash as a table rather than as an index. If you use a hash rather than a block for your table, all of your searches would be faster without needing any seperate indexes. The only way to have the speed of searching a block be comparable would be to keep it sorted and use a binary search (what RebDB does I think), but that doesn't help much with multiple keys that require different sorting orders. On the other hand, I've been sold on the idea that when you use a hash as an index (rather than the table), you are basically using it like an assoc, so using a structure optimized for that behavior would probably be best. | |
BrianH: 4-May-2006 | As for the hash (or assoc) index and list data combo, it has some advantages. When you are inserting and removing data a lot lists have a known speed benefit but the real advantage as far as indexes are concerned is in how lists handle series offsets (I'm using the word offset here because I'm using the word index to refer to the external hash/assoc index). Blocks encode their offsets as a number offset from the beginning of the series: >> a: [a b c] == [a b c] >> b: skip a 2 == [c] >> index? b == 3 >> insert next a 'd == [b c] >> b == [b c] >> index? b == 3 List offsets are pointers to the associated list element. >> a: make list! [a b c] == make list! [a b c] >> b: skip a 2 == make list! [c] >> index? b == 3 >> insert next a 'd == make list! [b c] >> b == make list! [c] >> index? b == 4 If you are indexing your data and your data in in a block, you need to update your index with almost every insertion and removal because the references to latter positions of the block in the index will be invalid. With list insertion and removal, external references are likely to still be valid unless the referenced elements themselves are deleted. If you are sure to delete the reference from the index (or replace it with nones) the rest of the index should be OK. New index references can just be tacked on the end, or put into the first empty entry. This makes live indexes a lot more practical. On the down side, if you are using lists and they are long enough to make linear searches impractical, you really do need an external index for them to be useful. Also you need to balance the overhead and complexity of keeping the indexes updated against their benefit. This technique is not for the faint of heart unless you can get some guru to do algorithms for you. | |
Group: Power Mezz ... Discussions of the Power Mezz [web-public] | ||
Graham: 30-Jan-2010 | >> do %mezz/filter-html.r Script: "HTML Filter" (none) ** Script Error: macro has no value ** Near: !set-assoc: macro [assoc word value] [(:either) _pos: (:find) assoc word [(:poke) _pos 2 value/only] [ insert/on.. |