<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: SICP section 3.3.4</title>
	<atom:link href="http://eli.thegreenplace.net/2007/10/08/sicp-section-334/feed/" rel="self" type="application/rss+xml" />
	<link>http://eli.thegreenplace.net/2007/10/08/sicp-section-334/</link>
	<description>Eli Bendersky's personal website</description>
	<pubDate>Sat, 22 Nov 2008 00:56:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: luca</title>
		<link>http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125966</link>
		<dc:creator>luca</dc:creator>
		<pubDate>Sat, 16 Aug 2008 03:51:17 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125966</guid>
		<description>all right figured it out completely sorry for the useless posts</description>
		<content:encoded><![CDATA[<p>all right figured it out completely sorry for the useless posts</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lukasjob</title>
		<link>http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125236</link>
		<dc:creator>lukasjob</dc:creator>
		<pubDate>Wed, 06 Aug 2008 14:39:39 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125236</guid>
		<description>i'm sorry i got it now 
only thing that (push c lcout) shouldn't be (push c lcin)?</description>
		<content:encoded><![CDATA[<p>i&#8217;m sorry i got it now<br />
only thing that (push c lcout) shouldn&#8217;t be (push c lcin)?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lukasjob</title>
		<link>http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125233</link>
		<dc:creator>lukasjob</dc:creator>
		<pubDate>Wed, 06 Aug 2008 14:00:20 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-125233</guid>
		<description>(defun ripple-carry-adder (la lb ls c)
  (let ((n (length la)))
    (unless (= n (length lb) (length ls))
      (error "Expecting all lists of same length"))
    (labels (
      (ripple-build (la lb lcin ls lcout)
        (unless (null la)
          (full-adder (car la) (car lb) (car lcin)
                      (car ls) (car lcout))
          (ripple-build (cdr la) (cdr lb) (cdr lcin)
                        (cdr ls) (cdr lcout)))))

      (let ((lcin '()) (lcout '()))
        (dotimes (i n)
          (let ((ci (make-wire)))
            (push ci lcin)
            (push ci lcout)))
        (push c lcout)
        (ripple-build la lb lcin ls lcout))))) 

excuse me sir i'm struggling to go through this book and sometimes it's not easy I was trying to understand your function for ex 3.30 I was expecting something like the wire passed as c-out to full-adder used as the wire passed as c-in to the next full-adder in the sequence ... something like a swap between recursive calls but couldn't find anything like that ... mumble mumble ... *___*

luca</description>
		<content:encoded><![CDATA[<p>(defun ripple-carry-adder (la lb ls c)<br />
  (let ((n (length la)))<br />
    (unless (= n (length lb) (length ls))<br />
      (error &#8220;Expecting all lists of same length&#8221;))<br />
    (labels (<br />
      (ripple-build (la lb lcin ls lcout)<br />
        (unless (null la)<br />
          (full-adder (car la) (car lb) (car lcin)<br />
                      (car ls) (car lcout))<br />
          (ripple-build (cdr la) (cdr lb) (cdr lcin)<br />
                        (cdr ls) (cdr lcout)))))</p>
<p>      (let ((lcin &#8216;()) (lcout &#8216;()))<br />
        (dotimes (i n)<br />
          (let ((ci (make-wire)))<br />
            (push ci lcin)<br />
            (push ci lcout)))<br />
        (push c lcout)<br />
        (ripple-build la lb lcin ls lcout))))) </p>
<p>excuse me sir i&#8217;m struggling to go through this book and sometimes it&#8217;s not easy I was trying to understand your function for ex 3.30 I was expecting something like the wire passed as c-out to full-adder used as the wire passed as c-in to the next full-adder in the sequence &#8230; something like a swap between recursive calls but couldn&#8217;t find anything like that &#8230; mumble mumble &#8230; *___*</p>
<p>luca</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 3fen</title>
		<link>http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-124196</link>
		<dc:creator>3fen</dc:creator>
		<pubDate>Sat, 19 Jul 2008 12:36:44 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/10/08/sicp-section-334/#comment-124196</guid>
		<description>The change in queue from LILO to LIFO can't be simulated that way, I think. 

The procedures are like this:
(define x (make-wire))
(define y (make-wire))
(define z (make-wire))
(and-gate x y z)
(set-signal! x 0)
(set-signal! y 1)
(propagate)

(set-signal! x 1)   ; s1
(set-signal! y 0)   ; s2
(propagate)

set-signal! will add some segments to the-agenda, and the signal of z will change only after (propagate) is done. So that after s1, something like (set-signal! z 1) will be added to the-agenda, and s2 will add (set-signal! z 0). Here is the difference: if the LIFO queue is used, (propagate) will run (set-signal! z 0) first instead of (set-signal! z 1). Therefor, the signal of z will be 1 while x=1 and y=0 at last. It's not only a hazard, I guess.</description>
		<content:encoded><![CDATA[<p>The change in queue from LILO to LIFO can&#8217;t be simulated that way, I think. </p>
<p>The procedures are like this:<br />
(define x (make-wire))<br />
(define y (make-wire))<br />
(define z (make-wire))<br />
(and-gate x y z)<br />
(set-signal! x 0)<br />
(set-signal! y 1)<br />
(propagate)</p>
<p>(set-signal! x 1)   ; s1<br />
(set-signal! y 0)   ; s2<br />
(propagate)</p>
<p>set-signal! will add some segments to the-agenda, and the signal of z will change only after (propagate) is done. So that after s1, something like (set-signal! z 1) will be added to the-agenda, and s2 will add (set-signal! z 0). Here is the difference: if the LIFO queue is used, (propagate) will run (set-signal! z 0) first instead of (set-signal! z 1). Therefor, the signal of z will be 1 while x=1 and y=0 at last. It&#8217;s not only a hazard, I guess.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
