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
