unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Are `eqv?' and `eq?' the same?
@ 2013-08-25 11:39 Alexandru Cojocaru
  2013-08-25 12:39 ` Pascal J. Bourguignon
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Alexandru Cojocaru @ 2013-08-25 11:39 UTC (permalink / raw)
  To: guile-user

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

|Hi,

from the GUILE manual [0]:|
||
     `eq?|' tests just for the same object (essentially a pointer 
comparison)
     `eqv?'| extends |`eq?'| to look at the value of numbers and characters.

this is what I get:

     scheme@(guile-user)> (eq? 3 (+ 1 2))
     $1 = #t

is this behavior intentional or some type of bug?

Best regards,
Alexandru Cojocaru

[0]: https://www.gnu.org/software/guile/manual/html_node/Equality.html

[-- Attachment #2: Type: text/html, Size: 981 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Are `eqv?' and `eq?' the same?
  2013-08-25 11:39 Are `eqv?' and `eq?' the same? Alexandru Cojocaru
@ 2013-08-25 12:39 ` Pascal J. Bourguignon
  2013-08-25 12:41 ` Noah Lavine
  2013-08-25 20:13 ` Ian Price
  2 siblings, 0 replies; 4+ messages in thread
From: Pascal J. Bourguignon @ 2013-08-25 12:39 UTC (permalink / raw)
  To: guile-user

Alexandru Cojocaru <xojoc@gmx.com> writes:

> Hi,
>
> from the GUILE manual [0]:
>
>     `eq?' tests just for the same object (essentially a pointer
> comparison)
>     `eqv?' extends `eq?' to look at the value of numbers and
> characters.
>
> this is what I get:
>
>     scheme@(guile-user)> (eq? 3 (+ 1 2))
>     $1 = #t
>
> is this behavior intentional or some type of bug?

Yes.


A some implementations internalize small integers (and characters).

A lot of implementations even don't allocate small integers (fixnums) as
objects, but encode them instead as immediate values.


So:

         (let ((x 3)
               (y (+ 1 2)))
            (eq? x y))

could be represented in memory in different ways:

   +-------+
x: |  f:3  |
   +-------+
y: |  f:3  |
   +-------+



   +-------+
x: |  p0---|----------+
   +-------+          |
y: |  p0---|--------+ |
   +-------+        | |
                    | |
                    v v
               +----------+
               |    f:3   |
               +----------+

   +-------+
x: |  p1---|-----------------------------+
   +-------+                             |
y: |  p2---|--------+                    |
   +-------+        |                    |
                    |                    |
                    v                    v
               +----------+        +----------+ 
               |    f:3   |        |    f:3   |
               +----------+        +----------+

This later case would occur if the number was a bignum:
b:391278903129038129038129038901238901 for example.
(f: denotes the type tag for fixnums, b: the type tag for bignums).


Now, even if we're in the second situation, for example, we could get
it also with:  (let ((x 3) (y x)) (eq? x y)),  it is still possible that
in the process of calling a function such as eq? the argument be copied,
so that in 

   (define (eq? a b) …)

we could get a situation like:

   +-------+
a: |  p1---|-----------------------------+
   +-------+                             |
b: |  p2---|--------+                    |
   +-------+        |                    |
                    |                    |
                    v                    v
               +----------+        +----------+ 
               |    f:3   |        |    f:3   |
               +----------+        +----------+

even starting from the second or (less probable) first situation!


Now, if inside eq? we have the first or second situation, then the
result will be #t, and in the third situation, the result will be #f.


That's all you learn from eq?, which, for characters and numbers, is not
much interesting: it only tells you something about how numbers are
implemented and processed by the implementation.



-- 
__Pascal Bourguignon__
http://www.informatimago.com/




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Are `eqv?' and `eq?' the same?
  2013-08-25 11:39 Are `eqv?' and `eq?' the same? Alexandru Cojocaru
  2013-08-25 12:39 ` Pascal J. Bourguignon
@ 2013-08-25 12:41 ` Noah Lavine
  2013-08-25 20:13 ` Ian Price
  2 siblings, 0 replies; 4+ messages in thread
From: Noah Lavine @ 2013-08-25 12:41 UTC (permalink / raw)
  To: Alexandru Cojocaru; +Cc: Guile Mailing List

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

Hello,

eq? and eqv? are sort of a funny pair. eqv? actually has sensible semantics
- if two things are eqv?, then a normal scheme program should never notice
the difference between them (they are operationally equivalent). eq? is
defined not in terms of Scheme, but in terms of Scheme's implementation -
two things are eq? if they are represented with the same bit of memory.

The reason for eq? is that eq? can be implemented very efficiently,
especially on old hardware that was current when that part of the Scheme
standard was written. For some types (i.e. booleans and symbols), eq? is
the same as eqv?, so eq? is used like a higher-performing shortcut to eqv?.
Nowadays, it's probably best to just use eqv? and spend your time worrying
about cache misses if you care about performance.

The particular case you mention is not a bug, but it's also not guaranteed
to work for all numbers. Guile represents small numbers (less than 2^62 on
64-bit systems, I believe) without a pointer, which means that the obvious
eq? implementation treats them as the same thing. This is allowed by the
standard, but it won't hold true for big numbers, which are represented as
blocks of memory allocated in the heap.

Best,
Noah


On Sun, Aug 25, 2013 at 7:39 AM, Alexandru Cojocaru <xojoc@gmx.com> wrote:

>  Hi,
>
> from the GUILE manual [0]:
>
>     `eq?' tests just for the same object (essentially a pointer
> comparison)
>     `eqv?' extends `eq?' to look at the value of numbers and characters.
>
> this is what I get:
>
>     scheme@(guile-user)> (eq? 3 (+ 1 2))
>     $1 = #t
>
> is this behavior intentional or some type of bug?
>
> Best regards,
> Alexandru Cojocaru
>
> [0]: https://www.gnu.org/software/guile/manual/html_node/Equality.html
>

[-- Attachment #2: Type: text/html, Size: 2535 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Are `eqv?' and `eq?' the same?
  2013-08-25 11:39 Are `eqv?' and `eq?' the same? Alexandru Cojocaru
  2013-08-25 12:39 ` Pascal J. Bourguignon
  2013-08-25 12:41 ` Noah Lavine
@ 2013-08-25 20:13 ` Ian Price
  2 siblings, 0 replies; 4+ messages in thread
From: Ian Price @ 2013-08-25 20:13 UTC (permalink / raw)
  To: Alexandru Cojocaru; +Cc: guile-user

Alexandru Cojocaru <xojoc@gmx.com> writes:

>     `eq?' tests just for the same object (essentially a pointer
> comparison)
>     `eqv?' extends `eq?' to look at the value of numbers and
> characters.
>
> this is what I get:
>
>     scheme@(guile-user)> (eq? 3 (+ 1 2))
>     $1 = #t
>
> is this behavior intentional or some type of bug?
The wording seems less than ideal, but the behaviour is perfectly
fine, at least as far as the standard is concerned.

Having said that my advice, to you, and to everyone reading this, is
basically always use eqv?. No correct program will ever be broken by
using it and the efficiency gains if eq? are marginal.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-08-25 20:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-25 11:39 Are `eqv?' and `eq?' the same? Alexandru Cojocaru
2013-08-25 12:39 ` Pascal J. Bourguignon
2013-08-25 12:41 ` Noah Lavine
2013-08-25 20:13 ` Ian Price

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).