You wouldn't happen to have a citation for this traditional way, would you?
tia, Robby On Thu, Apr 25, 2013 at 9:11 PM, Pierpaolo Bernardi <olopie...@gmail.com>wrote: > Ah, yes, right. > > > > On Fri, Apr 26, 2013 at 4:09 AM, Robby Findler < > ro...@eecs.northwestern.edu> wrote: > >> Yes, except that we do know something about what happens when it returns >> #t in the "in all other cases" case. >> >> Robby >> >> >> On Thu, Apr 25, 2013 at 9:03 PM, Pierpaolo Bernardi >> <olopie...@gmail.com>wrote: >> >>> 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? >>> >>> >>> >>> On Fri, Apr 26, 2013 at 1:37 AM, Robby Findler < >>> ro...@eecs.northwestern.edu> wrote: >>> >>>> 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). >>>> >>>> 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. >>>> >>>> When the arguments are mutable objects, then Macros and Danny's >>>> explanations are a good way to start understanding them. >>>> >>>> (After all, if you punch one crab named "Joe", the other one doesn't >>>> get a bruise.) >>>> >>>> Robby >>>> >>>> >>>> On Thu, Apr 25, 2013 at 3:45 PM, Marco Morazan <moraz...@gmail.com>wrote: >>>> >>>>> Joe, >>>>> >>>>> 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. >>>>> >>>>> equal? tests if its two items have the same value. >>>>> >>>>> eq? tests if two items are the same item. >>>>> >>>>> Using your example: >>>>> >>>>> >>>>> (define A (make-posn 4 5)) >>>>> (define B (make-posn (+ 3 1) (- 6 1))) >>>>> >>>>> Both A and B are items (in this case posns) that have the same value. >>>>> Thus, (equals? A B) is true. >>>>> >>>>> 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. >>>>> >>>>> Consider: >>>>> >>>>> (define C B) >>>>> >>>>> 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). >>>>> >>>>> 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). >>>>> >>>>> 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. >>>>> >>>>> Finally, eqv? is not used in HtDP and my advice would be to ignore its >>>>> existence with beginners. >>>>> >>>>> I hope this helps. >>>>> >>>>> Marco >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 25, 2013 at 2:31 PM, Ford, Joe <jf...@hollandhall.org>wrote: >>>>> >>>>>> 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? >>>>>> >>>>>> 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: >>>>>> >>>>>> (define FOUR "four") >>>>>> (define A (make-posn 4 5)) >>>>>> (define B (make-posn (+ 3 1) (- 6 1))) >>>>>> "-------------" >>>>>> (equal? FOUR "four") >>>>>> (equal? 4 (+ 1 3)) >>>>>> (equal? 4 (posn-x (make-posn 4 3))) >>>>>> (equal? A B) >>>>>> "-------------" >>>>>> (eq? FOUR "four") >>>>>> (eq? 4 (+ 1 3)) >>>>>> (eq? 4 (posn-x (make-posn 4 3))) >>>>>> (eq? A B) >>>>>> "---------------" >>>>>> (eqv? FOUR "four") >>>>>> (eqv? 4 (+ 1 3)) >>>>>> (eqv? 4 (posn-x (make-posn 4 3))) >>>>>> (eqv? A B) >>>>>> >>>>>> >>>>>> Why in the world would the above-defined A and B be considered >>>>>> "equal?" but not "eq?" or "eqv?"? >>>>>> >>>>>> -- >>>>>> *Joe Ford >>>>>> Technology Resources, Scheduling & Yearbook >>>>>> Holland Hall >>>>>> jf...@hollandhall.org >>>>>> >>>>>> * >>>>>> >>>>>> >>>>>> ____________________ >>>>>> Racket Users list: >>>>>> http://lists.racket-lang.org/users >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Cheers, >>>>> >>>>> Marco >>>>> >>>>> Have a´¨) >>>>> ¸.·´¸.·*´¨) ¸.·*¨) >>>>> (¸.·´ (¸.·´ * wonderful day! :) >>>>> >>>>> ____________________ >>>>> Racket Users list: >>>>> http://lists.racket-lang.org/users >>>>> >>>>> >>>> >>>> ____________________ >>>> Racket Users list: >>>> http://lists.racket-lang.org/users >>>> >>>> >>> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
