memq and member

S

Suresh Jeevanandam

Guest
From cdsdoc:

The memq Function

The memq function is the same as the member function except that it uses
the eq function for finding the element. Because the eq function is more
efficient than the equal function, use memq whenever possible based on
the nature of the data. For example, if the list to search contains only
symbols, then using the memq function is more efficient than using the
member function.


But it does not suggest when using memq instead of member would fail.

Can somebody give an example where using memq would give false results.

--
Suresh
 
With symbols, strings and intergers I guess member and memq are equivalent.

aList = list( "a" "b" "c" "d" )
member( "c" aList )
=> ("c" "d")
memq( "c" aList )
=> ("c" "d")

bList = list( 'a 'b 'c 'd )
member( 'c bList )
=> (c d)
memq( 'c bList )
=> (c d)

But not with floats there you have to use 'member'

cList = list( 1.0 2.0 3.0 4.0 )
member( 3.0 cList )
=> (3.0 4.0)
memq( 3.0 cList )
=> nil


Bernd
 
On Tue, 26 Sep 2006 13:47:49 +0200, Bernd Fischer
<bernd.fischer@xignalerif.r'4054-50];p5.de> wrote:

With symbols, strings and intergers I guess member and memq are equivalent.

aList = list( "a" "b" "c" "d" )
member( "c" aList )
=> ("c" "d")
memq( "c" aList )
=> ("c" "d")

bList = list( 'a 'b 'c 'd )
member( 'c bList )
=> (c d)
memq( 'c bList )
=> (c d)

But not with floats there you have to use 'member'

cList = list( 1.0 2.0 3.0 4.0 )
member( 3.0 cList )
=> (3.0 4.0)
memq( 3.0 cList )
=> nil


Bernd
Click to expand...
That's not quite it...

Best place to look is the documentation for eq. eq effectively compares the
memory address. So, you should not use eq on strings - because you can't really
guarantee that they are the same address, unless one variable is directly set to
another. Sometimes strings which happen to have the same value but were
separately assigned may be eq, because the system tries to be efficient about
not storing the same value twice - but that's not guaranteed.

In practice you should only use eq with symbols, and with lists which were built
from list cells - so for example, if you do:

a='(1 2 3)
b=cons(4 a)
c='(1 2 3)
eq(a cdr(b)) => t
eq(a c) => nil

Andrew.


--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 
Andrew Beckett wrote:
On Tue, 26 Sep 2006 13:47:49 +0200, Bernd Fischer
bernd.fischer@xignalerif.r'4054-50];p5.de> wrote:

With symbols, strings and intergers I guess member and memq are equivalent.

aList = list( "a" "b" "c" "d" )
member( "c" aList )
=> ("c" "d")
memq( "c" aList )
=> ("c" "d")

bList = list( 'a 'b 'c 'd )
member( 'c bList )
=> (c d)
memq( 'c bList )
=> (c d)

But not with floats there you have to use 'member'

cList = list( 1.0 2.0 3.0 4.0 )
member( 3.0 cList )
=> (3.0 4.0)
memq( 3.0 cList )
=> nil


Bernd

That's not quite it...

Best place to look is the documentation for eq. eq effectively compares the
memory address. So, you should not use eq on strings - because you can't really
guarantee that they are the same address, unless one variable is directly set to
another. Sometimes strings which happen to have the same value but were
separately assigned may be eq, because the system tries to be efficient about
not storing the same value twice - but that's not guaranteed.

In practice you should only use eq with symbols, and with lists which were built
from list cells - so for example, if you do:

a='(1 2 3)
b=cons(4 a)
c='(1 2 3)
eq(a cdr(b)) => t
eq(a c) => nil

Andrew.
Click to expand...

Andrew,
If the list contains only dbObjects, then, can we say it is safe to
use memq ?
Eg.
inst1 = dbFindAnyInstByName(geGetEditCellView() "MN0")
when(memq(inst1 geGetSelSet())
println("target is selected.")
)
--
Suresh


--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
Click to expand...
 
On Thu, 28 Sep 2006 11:12:52 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:

Andrew,
If the list contains only dbObjects, then, can we say it is safe to
use memq ?
Eg.
inst1 = dbFindAnyInstByName(geGetEditCellView() "MN0")
when(memq(inst1 geGetSelSet())
println("target is selected.")
)
Click to expand...
Well, I wouldn't. From the eq documentation:

The eq function runs considerably faster than equal but should only be used for
testing equality of symbols or shared lists. Using eq on types other than
symbols and lists will give unpredictable results and should be avoided.
For testing equality of numbers, strings, and lists in general, the equal
function and not the eq function should be used. You can test for equality
between symbols using eq more efficiently than using the == operator, which is
the same as the equal function.


With something that is inherently a pointer, like a dbobject, there would be no
benefit of eq anyway, so I would just stick with member.

Note the speed improvement comes with cases where there is a negative
outcome - the first thing that equal() does is to check if the items are eq
anyway - and only do the detailed check, value by value, if eq returns nil.

Andrew.


--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 
Andrew,

SKILL-Lint always hints to use 'memq' rather then 'meber' no mater
what datatypes used in the list.

SUGGEST (MEMBER1): /home/bernd/SKILL/unsupportedSampels/searchForCell.il, line
11 (BFsearchForCell) : Consider use of memq rather than member:
member(viewToSearchIn ((d_cell~>views)~>name))

Any way to make SKILL-Lint more intelligent and do a datatype check before it
makes this suggestion?

Bernd
 
On Mon, 02 Oct 2006 11:07:44 +0200, Bernd Fischer
<bernd.fischer@xignalerif.r'4054-50];p5.de> wrote:

Andrew,

SKILL-Lint always hints to use 'memq' rather then 'meber' no mater
what datatypes used in the list.

SUGGEST (MEMBER1): /home/bernd/SKILL/unsupportedSampels/searchForCell.il, line
11 (BFsearchForCell) : Consider use of memq rather than member:
member(viewToSearchIn ((d_cell~>views)~>name))

Any way to make SKILL-Lint more intelligent and do a datatype check before it
makes this suggestion?

Bernd
Click to expand...
Bernd,

SKILL Lint is a static checking tool, and datatypes in SKILL are dynamic - you
can't predict until run time what values will be in the list being processed.

That's why it says "Consider" in the suggestion when you enable the hint rules.

Regards,

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 
Bernd,
In fact, I also got this suggestion in Skill Lint, and started wondering
about memq. :)

Now, I think I will just stick to member everywhere.
--
Suresh

Bernd Fischer wrote:
Andrew,

SKILL-Lint always hints to use 'memq' rather then 'meber' no mater
what datatypes used in the list.

SUGGEST (MEMBER1):
/home/bernd/SKILL/unsupportedSampels/searchForCell.il, line
11 (BFsearchForCell) : Consider use of memq rather than member:
member(viewToSearchIn ((d_cell~>views)~>name))

Any way to make SKILL-Lint more intelligent and do a datatype check
before it
makes this suggestion?

Bernd
Click to expand...
 
On Tue, 03 Oct 2006 15:14:23 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:

Bernd,
In fact, I also got this suggestion in Skill Lint, and started wondering
about memq. :)

Now, I think I will just stick to member everywhere.
Click to expand...
The real benefit of memq (and eq) is with lists - to avoid having to compare
every member of the list for equality. Of course, you can only use eq/memq if
the lists you're comparing are going to be the same memory location, not just
the same values - but in those cases it can be a lot faster.

For other objects, there's really no benefit.

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 
Andrew Beckett wrote:
On Tue, 03 Oct 2006 15:14:23 +0530, Suresh Jeevanandam
sureshj@DELETETHISti.com> wrote:

Bernd,
In fact, I also got this suggestion in Skill Lint, and started wondering
about memq. :)

Now, I think I will just stick to member everywhere.

The real benefit of memq (and eq) is with lists - to avoid having to compare
every member of the list for equality. Of course, you can only use eq/memq if
the lists you're comparing are going to be the same memory location, not just
the same values - but in those cases it can be a lot faster.

For other objects, there's really no benefit.

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
Click to expand...
Andrew,
Just to summarize, (and make sure my understanding is correct),
o There is not much speed improvement in cases where both memq and
member pass. (Because equal also comes out as soon as the addresses match.)
o There will be speed difference in the other cases. And memq should be
used to gain this speed improvement if we just want to check the address
and come out.

--
Suresh
 
On Wed, 04 Oct 2006 23:40:47 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:

Andrew Beckett wrote:
On Tue, 03 Oct 2006 15:14:23 +0530, Suresh Jeevanandam
sureshj@DELETETHISti.com> wrote:

Bernd,
In fact, I also got this suggestion in Skill Lint, and started wondering
about memq. :)

Now, I think I will just stick to member everywhere.

The real benefit of memq (and eq) is with lists - to avoid having to compare
every member of the list for equality. Of course, you can only use eq/memq if
the lists you're comparing are going to be the same memory location, not just
the same values - but in those cases it can be a lot faster.

For other objects, there's really no benefit.

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.

Andrew,
Just to summarize, (and make sure my understanding is correct),
o There is not much speed improvement in cases where both memq and
member pass. (Because equal also comes out as soon as the addresses match.)
o There will be speed difference in the other cases. And memq should be
used to gain this speed improvement if we just want to check the address
and come out.
Click to expand...
Yes, that's right (assuming you're talking about comparing lists).

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top