From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hengqing Hu Newsgroups: gmane.lisp.guile.user Subject: Re: Hash table read syntax in guile 2.0 Date: Mon, 18 Feb 2013 11:28:09 +0800 Message-ID: <55F02E3B-5F91-4005-99AF-0400DE697C3A@gmail.com> References: <7CB57FD4-FAAA-4F9C-9A04-F6DFA215C344@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1361158109 29987 80.91.229.3 (18 Feb 2013 03:28:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2013 03:28:29 +0000 (UTC) Cc: guile-user To: Daniel Hartwig Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Feb 18 04:28:51 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7HPN-00078V-W2 for guile-user@m.gmane.org; Mon, 18 Feb 2013 04:28:50 +0100 Original-Received: from localhost ([::1]:46830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7HP4-0001EZ-2L for guile-user@m.gmane.org; Sun, 17 Feb 2013 22:28:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7HOv-0001EI-97 for guile-user@gnu.org; Sun, 17 Feb 2013 22:28:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7HOs-0007d1-Db for guile-user@gnu.org; Sun, 17 Feb 2013 22:28:21 -0500 Original-Received: from mail-pa0-f49.google.com ([209.85.220.49]:33972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7HOs-0007bf-2N for guile-user@gnu.org; Sun, 17 Feb 2013 22:28:18 -0500 Original-Received: by mail-pa0-f49.google.com with SMTP id kp6so2596472pab.36 for ; Sun, 17 Feb 2013 19:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=xCp0o89m7bh4NfKedYunM+1JYDCt+wCIKvPLlwvkUOQ=; b=SncNPk+ABl3hOp3m0gfGHs1VBCMd/MgUK16JNzmjcfKDz4Xvbx1MY2D0Lm5OQ9EoDr Ft9dFotfW6kNUczJlI0+/6UZvNMyPB9PPjWP4oUYjrvD45oFRh4wglacpmbUzdr6VpuX EFa4XB9QVEtRndXiqPi6q5WseO4yJAF9DOLAHnycJqNd4fYILeDln60ELDsdwQlVAK/7 +uArsTDLqbMGJ/C2otzrJP06JVr99GzpXU6IplftXfPVtLGznJ8SJ/NA/P5aRKqMPhpV QC895BQxHJx6GIm6gAQz9+9sXGcgPl1HCdgix6SeG1l2fy/wpSqr5wCrhrOo6ARp2/oU e86Q== X-Received: by 10.68.47.39 with SMTP id a7mr25840783pbn.155.1361158092552; Sun, 17 Feb 2013 19:28:12 -0800 (PST) Original-Received: from [192.168.0.3] ([60.162.89.201]) by mx.google.com with ESMTPS id c3sm58441546pax.9.2013.02.17.19.28.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 19:28:11 -0800 (PST) In-Reply-To: X-Mailer: iPad Mail (9B206) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.49 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10127 Archived-At: Here it is: https://github.com/hudayou/fib Welcome your suggestions! =D4=DA 2013-2-18=A3=AC11:24=A3=ACDaniel Hartwig =D0=B4=B5= =C0=A3=BA > On 18 February 2013 11:14, Hengqing Hu wrote: >> Though I didn't look into the implementation. >>=20 >> I suppose length is a constant time operation here, >> if you use fold instead to get the same thing. >> It would be linear time. >=20 > This is not guaranteed. >=20 >>=20 >> Knowing something is empty or not rises after I put something inside >> and then take something out. >> Then I dont't know whether there are still something left, so I need to e= xamine it. >> Or if something can tell me. >=20 > Although the point of your algorithm is vague, I believe you will find > a better one using hash-fold that does not involve checking for > emptiness. >=20 > Why do you need to know if some elements are left, and what happens if > there are? Do you have some code I could look at?