On Tue, Nov 12, 2013 at 06:41:18PM -0500, John Cowan wrote:
Peter Bex scripsit:
((a . foo) (a . bar)) = ?a=foo;a=bar
A HTTP server might interpret this query string differently from ?a=foo
Ah, I see. Yes, you're right; that's not really an a-list, as you wouldn't
search it with
For a tessellation function, I believe I should use a hash table or a alist to
save the index of some points to prevent duplicates. Yesterday I felt I should
test how fast would the hash-table work to index my 3d coordinates. For that
reason, I wrote that small benchmark and realized that the
Hi!
* Loïc Faure-Lacroix l...@vosnax.ru [131112 11:33]:
To do the same job, it takes 650s for the non destructive function
and 0.014s for the use of destructive ???alist-update!???. Anyone
can explain why is this so slow?
The non-destructive version creates a new list:
#;1 (define l '((a .
Hi Loïc,
I did not look on your paste. But a few hints:
alists are O(n) while hashtable are O(1) .
However the constant involved is larger for hashtable then alists.
Therefore alists are fast for small numbers of elements in the list.
Tables win when the number of elements becomes larger.
On Tue, Nov 12, 2013 at 02:33:23PM +0400, Loïc Faure-Lacroix wrote:
For a tessellation function, I believe I should use a hash table or a alist
to save the index of some points to prevent duplicates. Yesterday I felt I
should test how fast would the hash-table work to index my 3d
On Tue, Nov 12, 2013 at 03:13:49PM +0400, Loïc Faure-Lacroix wrote:
Ah right, I believed the update! would add the element to the list
destructively. After changing the second variant to include the newly created
element when not found. The alist gets much more slower than the hash-table.
Peter Bex scripsit:
alist-update will take O(n) to locate the key just like alist-update!,
but when it finds the entry, it will need to build a new list with
the entry replaced at the same position. That means it's O(n) to update
(for new keys it's O(1), they can just be consed onto the
On Tue, Nov 12, 2013 at 09:24:23AM -0500, John Cowan wrote:
Peter Bex scripsit:
alist-update will take O(n) to locate the key just like alist-update!,
but when it finds the entry, it will need to build a new list with
the entry replaced at the same position. That means it's O(n) to
Peter Bex scripsit:
Simple: for those who prefer functional updates, but don't want their
lists to keep growing endlessly.
Fair enough, though the persistent-hash-map egg probably is the Right
Thing.
Also, in some cases duplicate entries really mean something different
(for example in
On Tue, Nov 12, 2013 at 04:34:51PM -0500, John Cowan wrote:
Also, in some cases duplicate entries really mean something different
(for example in alist-uri query attribute mappings and such).
I don't understand this example.
((a . foo) (a . bar)) = ?a=foo;a=bar
A HTTP server might
As Peter said, the Query String format doesn’t prevent you from using multiple
time the same key for multiple values. One concrete example would be a form
with a couple of checkboxes. A group of checkbox could be named “ingredients”.
Each checkbox could have different values. Like Onions,
Peter Bex scripsit:
((a . foo) (a . bar)) = ?a=foo;a=bar
A HTTP server might interpret this query string differently from ?a=foo
Ah, I see. Yes, you're right; that's not really an a-list, as you wouldn't
search it with assoc (or equivalent).
--
MEET US AT POINT ORANGE AT MIDNIGHT BRING
12 matches
Mail list logo
