[plt-scheme] eqv? equal?

You may also consider:

(define a (box 1))
(define b (box 1))
(eqv? a b) ;--> #f because a and b are two different boxes (see below)
(equal? a b) ;--> #t because boxes a and b have the same content.
(set-box! b 2) ; this does not affect box a!
(equal? a b) ;--> #f because now the boxes have different contents.

There are different meanings for the words "the same". Two of them are:

1: The same content (recursively without being trapped by circular constructs) This is what equal? does (approximately) Because equal? must recur on the structure of the object, it is slower than eqv?.

2: The same in the sense that if the objects are mutable, changing one also changes the other. This is what eqv? does. This means that for objects like boxes, (mutable) lists and vectors, eqv? only has to look whether or not the two arguments point to the same place in storage.

When comparing things like numbers and symbols, equal? and eqv? yield the same results and you probably wont notice any difference in speed.

Jos


  ----- Original Message ----- 
  From: emre berat nebioglu 
  To: plt-scheme at list.cs.brown.edu 
  Sent: Sunday, March 01, 2009 8:15 PM
  Subject: [plt-scheme] eqv? equal?


  Sorry for this newbie question.But i wonder so much about eqv? and equal?.In the some discussin that passes on ffreenode #scheme.I see some sentence which is "eqv? is faster than equal? in comparison.So i thought eqv? and equal? returns boolean thing #t or #f right ? So why?

  In that point,i have three question about that.

  what is the thing that makes eqv? faster than equal?.


  which one is more powerful on programming  ?

  What is the reason that equal? still be used ? If eqv? is faster than equal?.

  Regards.



------------------------------------------------------------------------------


  _________________________________________________
    For list-related administrative tasks:
    http://list.cs.brown.edu/mailman/listinfo/plt-scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090301/8040169a/attachment.html>