Experimental Physics and
Industrial Control System

> 1) reflexive =>  x==x is always true
> 2) symetric  => if x==y then y==x
> 3) transitive => if x==y and y==z then x==z

I agree that this is the correct definition of equivalence.

It's somewhat slower to guarantee this, but perhaps necessary.

It may be that a fast, but incorrect == operator may not be very useful.

Jeff

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Wednesday, September 28, 2005 7:07 AM
> To: [email protected]
> Subject: Re: data access structures, strings
> 
> Jeff Hill wrote:
> 
> >Please pardon an internal debate converted to a mail message :-)
> >
> >
> >
> >>>Use 'assign' instead of 'operator =',
> >>>'isEqual' instead of 'operator ==',
> >>>
> >>>
> >>Shouldn't this also apply to dataAccess? {Or should I say :-) }
> >>
> >>
> >
> >PropertyCatalog currently has "operator =" and "operator ==".
> >
> >O Do they meet the conventional wisdom test? That is, is their purpose
> >roughly equivalent to the purpose of these operators with primitive
types?
> I
> >Originally I thought yes, but I have thought about this further and its
> >probably more accurate to call 'operator =' "extract what's in the LHS
> from
> >the RHS", and what 'operator ==' does "return true if everything in the
> LHS
> >is equivalent in the RHS".
> >
> Should  == (or equals) always guarantee that it is an equivalence
relation?
> 
> That is
> 
> 1) reflexive =>  x==x is always true
> 2) symetric  => if x==y then y==x
> 3) transitive => if x==y and y==z then x==z
> 
> Java states that if a class overrides equals it should gurantee that its
> implementation is an equivalence relation.
> 
> I suspect similar advice appears somewhere for C++.
> 
> dataAccess == does not appear to be  symetric
> 
> If containers are implemented for
> 
> struct A { int x; int y} and struct B {int x; int y; int z}
> 
> Then won't the following happen if A.x=B.x and A.y=B.y?
> 
> A==B is true but B==A is false
> 
> Marty

Replies:

Re: data access structures, strings Kay-Uwe Kasemir

References:

Re: data access structures, strings Marty Kraimer

Navigate by Date:

Prev: Re: ICALEPCS 2005: EPICS workshop: EPICS V4 Runtime Database Marty Kraimer

Next: RE: data access structures, strings Jeff Hill

Index: 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: data access structures, strings Marty Kraimer

Next: Re: data access structures, strings Kay-Uwe Kasemir

Index: 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024