Hi!
Daniel Hartwig skribis:
> From 3330f00f54649cdd0914b6ff03c7b7bbc38ffa8d Mon Sep 17 00:00:00 2001
> From: Daniel Hartwig
> Date: Sun, 17 Feb 2013 16:38:31 +0800
> Subject: [PATCH] add hash-count for native tables
>
> * libguile/hashtab.c (scm_hash_count): New function. Count the number
>
On 18 February 2013 13:39, Hengqing Hu wrote:
> Thanks for spending time to investigate.
Sure.
>
> One thing I'd like to point out, the intention of use hash-length
> in remove-unrelated-blocks is to avoid furthur processing
> if all blocks are related.
This involves the assumption that the siz
Thanks for spending time to investigate.
One thing I'd like to point out, the intention of use hash-length
in remove-unrelated-blocks is to avoid furthur processing
if all blocks are related.
Of course you can use your left hand for the purpose of your right hand.
It does not mean having one hand
On 18 February 2013 11:28, Hengqing Hu wrote:
> Here it is:
>
> https://github.com/hudayou/fib
>
> Welcome your suggestions!
Please see the attached patch.
For remove-unrelated-blocks, building the hash-tree may be suboptimal
and I suspect could be avoided altogether, but I have not investigated
Here it is:
https://github.com/hudayou/fib
Welcome your suggestions!
在 2013-2-18，11:24，Daniel Hartwig 写道：
> On 18 February 2013 11:14, Hengqing Hu wrote:
>> Though I didn't look into the implementation.
>>
>> I suppose length is a constant time operation here,
>> if you use fold instead to g
On 18 February 2013 11:14, Hengqing Hu wrote:
> Though I didn't look into the implementation.
>
> I suppose length is a constant time operation here,
> if you use fold instead to get the same thing.
> It would be linear time.
This is not guaranteed.
>
> Knowing something is empty or not rises af
Though I didn't look into the implementation.
I suppose length is a constant time operation here,
if you use fold instead to get the same thing.
It would be linear time.
Knowing something is empty or not rises after I put something inside
and then take something out.
Then I dont't know whether th
On 18 February 2013 10:36, Hengqing Hu wrote:
> Thanks for the collaboration.
>
> You are right, that's what I mean by a deep list.
So what do you consider the length of the example deep list, is it
two, three, or six? Length implies a particular dimension, which is
naturally the ordering of the
Thanks for the collaboration.
You are right, that's what I mean by a deep list.
One usage of knowing the information is to tell
whether the hash table is empty or not,
Since a hash-empty? procedure is not provided.
在 2013-2-18，10:01，Daniel Hartwig 写道：
> On 17 February 2013 22:15, Hengqing Hu
On 18 February 2013 09:00, Daniel Hartwig wrote:
> I included the special case as it runs in
> constant time, I suppose changing the order and making PRED optional
> would be a neater interface.
Actually, lets not leak this implementation detail in the API, as it
is not a natural property of hash
On 17 February 2013 22:15, Hengqing Hu wrote:
> I don't know it's intentional or a bug,
> but now object->string returns something different.
It was an intentional change. Previously you could not tell apart two
distinct hash tables that happened to have the same number of elements
and bucket si
On 17 February 2013 21:41, Ludovic Courtès wrote:
> Hi!
>
> Daniel Hartwig skribis:
>> +To count all elements:
>> +
>> +@lisp
>> +(hash-count #f h)
>
> I would instead recommend (hash-count (const #t) h), and remove the
> special case. WDYT?
A clearer example, sure. I included the special case
Hi!
Daniel Hartwig skribis:
> From ec52416c2060cff11d0cb435df49207e5aa3dc7a Mon Sep 17 00:00:00 2001
> From: Daniel Hartwig
> Date: Sun, 17 Feb 2013 16:38:31 +0800
> Subject: [PATCH] add hash-count for native tables
>
> * libguile/hashtab.c (scm_hash_count): New function. Count the number
>
I don't know it's intentional or a bug,
but now object->string returns something different.
My understanding of length and fold is the same for deep lists as for
hash table.
It's great you have provided a patch so a constant time way
to know no of key/value bindings in a hash table could be more
On 17 February 2013 11:55, Hengqing Hu wrote:
> Dear list,
>
> It seems the read syntax of a hash table has been silently changed.
>
> Now (make-hash-table) produces
> #
> instead what was in 1.8
> #
>
> But the document is not updated yet?
>
Hi
That's how hash-table values are printed, true, bu
Dear list,
It seems the read syntax of a hash table has been silently changed.
Now (make-hash-table) produces
#
instead what was in 1.8
#
But the document is not updated yet?
I used to use the read syntax to get the length of the hash table.
It would be more convinient if a hash-length procedur
16 matches
Mail list logo
