<div dir="ltr">You wouldn't happen to have a citation for this traditional way, would you?<div><br></div><div>tia,<br>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 9:11 PM, Pierpaolo Bernardi <span dir="ltr"><<a href="mailto:olopierpa@gmail.com" target="_blank">olopierpa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah, yes, right.<div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Fri, Apr 26, 2013 at 4:09 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, except that we do know something about what happens when it returns #t in the "in all other cases" case.<span><font color="#888888"><div>
<br></div><div>Robby</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Apr 25, 2013 at 9:03 PM, Pierpaolo Bernardi <span dir="ltr"><<a href="mailto:olopierpa@gmail.com" target="_blank">olopierpa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The traditional way of explaining eq? is that it works when one of the arguments is a symbol or a mutable data structure. In all other cases the result is implementation dependent. Is this explanation still valid for racket?<div>
<div><div>
<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 1:37 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think that either of these explanations are really the right way to think about eq?. The only way to really understand eq? on immutable values is to understand that it is exposing low-level details of the implementation to you (ostensibly for performance reasons). That is, if (eq? a b) returns #true (where a and b are immutable things like the structs in the previous messages), then that tells you that equal? will return also return #true. When it returns #false all you know is that equal? may or may not return #true (ie, you know nothing).<div>
<br></div><div>This may seem like a strange primitive (and it is), but it can be very useful for performance reasons, since it takes constant time but equal? may take up to linear time in the size of its inputs.</div><div>
<br></div><div>When the arguments are mutable objects, then Macros and Danny's explanations are a good way to start understanding them.</div><div><br></div><div>(After all, if you punch one crab named "Joe", the other one doesn't get a bruise.)<span><font color="#888888"><br>
<div><div><div><br></div><div>Robby</div></div></div></font></span></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 3:45 PM, Marco Morazan <span dir="ltr"><<a href="mailto:morazanm@gmail.com" target="_blank">morazanm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Joe,<br><br></div>Perhaps a more pedestrian explanation might help. There is a difference between two items having the same value and two items being the same item.<br>
<br></div>equal? tests if its two items have the same value.<br><br></div>eq? tests if two items are the same item.<br><br></div>Using your example:<div><br><br>(define A (make-posn 4 5))<br>(define B (make-posn (+ 3 1) (- 6 1)))<br>
<br></div></div>Both A and B are items (in this case posns) that have the same value. Thus, (equals? A B) is true.<br><br></div>A and B, however, are not the same item (they are two different posns that happen to have the same value). Thus, (eq? A B) is false.<br>
<br></div>Consider:<br><br></div>(define C B)<br><br></div>Now, C and B are the same item (the same posn). Thus, (eq? C B) is true. As C and A are not the same posn, we have (eq? C A) is false. As you would expect (equal? C A) is true (because the have the same value).<br>
<br></div>eq? returning true suffices to know that equal? returns true (if two items are the same item, then clearly they have the same value). equal? returning true does not suffice to know what eq? returns (given that two different items may or may not have the same value).<br>
<br></div>This difference is not relevant for most of HtDP, because it is not until your reach the material with assignment that you need to understand/know if two items are the same item or not. Before the assignment material, you are always testing for value equality.<br>
<br></div><div>Finally, eqv? is not used in HtDP and my advice would be to ignore its existence with beginners.<br></div><div><br></div>I hope this helps.<br><br></div>Marco<br><div><div><div><div><div><div><div><div><div>
<div><div><br><br></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Thu, Apr 25, 2013 at 2:31 PM, Ford, Joe <span dir="ltr"><<a href="mailto:jford@hollandhall.org" target="_blank">jford@hollandhall.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>I have a group of high school students with a question... can someone please explain to beginner Racket users the differences between these three boolean functions: eq? equal? eqv?<br>
<br></div>
We have read the help menu verbage visible from DrRacket, but simply don't understand what it is saying. Maybe that's lack of context or vocabulary... but we're struggling a bit. To test simple variations of application, we wrote some simple code (shown below) but don't understand why the results are what they are:<br>
<br>(define FOUR "four")<br>(define A (make-posn 4 5))<br>(define B (make-posn (+ 3 1) (- 6 1)))<br>"-------------"<br>(equal? FOUR "four")<br>(equal? 4 (+ 1 3))<br>(equal? 4 (posn-x (make-posn 4 3)))<br>
(equal? A B)<br>"-------------"<br>(eq? FOUR "four")<br>(eq? 4 (+ 1 3))<br>(eq? 4 (posn-x (make-posn 4 3)))<br>(eq? A B)<br>"---------------"<br>(eqv? FOUR "four")<br>(eqv? 4 (+ 1 3))<br>
(eqv? 4 (posn-x (make-posn 4 3)))<br>(eqv? A B)<br><br><br></div>Why in the world would the above-defined A and B be considered "equal?" but not "eq?" or "eqv?"?<span><font color="#888888"><br clear="all">
<div><div><div>
<br>-- <br><div dir="ltr"><i>Joe Ford<br>
Technology Resources, Scheduling & Yearbook<br>
Holland Hall<br>
<a href="mailto:jford@hollandhall.org" target="_blank">jford@hollandhall.org</a><br><br></i><img alt=""><br><br></div>
</div></div></div></font></span></div>
<br></div></div><div>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></div></blockquote></div><span><font color="#888888"><br><br clear="all"><br>-- <br><br>Cheers,<br><br>Marco<br><br>Have a´¨)<br>¸.·´¸.·*´¨) ¸.·*¨)<br>(¸.·´ (¸.·´ * wonderful day! :)
</font></span></div>
<br>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>
</div></div><br>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>