home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4661 < prev    next >
Encoding:
Text File  |  1992-12-24  |  4.6 KB  |  109 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!spool.mu.edu!torn!nott!cunews!cunews!knight
  3. From: knight@mrco.carleton.ca (Alan Knight)
  4. Subject: Re: Equality
  5. Message-ID: <knight.725232043@cunews>
  6. Sender: news@cunews.carleton.ca (News Administrator)
  7. Reply-To: knight@mrco.carleton.ca (Alan Knight)
  8. Organization: Carleton University
  9. References: <1992Dec21.184405.2215@midway.uchicago.edu>
  10. Date: Thu, 24 Dec 1992 21:20:43 GMT
  11. Lines: 98
  12.  
  13. In <1992Dec21.184405.2215@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
  14.  
  15. >So just what exactly do you all mean when you say "equality".  If it's just 
  16. >another binary predicate, why bother to call it equality?  If not, what 
  17. >semantic properties should it have?  The recent object/value discussion brought
  18. >up some examples which cause me to question my preconceived notions.  I will
  19. >below attempt to list those notions, in hope the group will provide useful 
  20. >comments.   Throughout the following, "object" is used as in current OO 
  21. >languages, to represent both "objects" and "values".  
  22.  
  23. >1) Equality should be reflexive.  
  24. >    I thought this was obvious, but IEEE754 may provide a counterexample.
  25.  
  26. >2) Equality should be symettric.
  27. >3) Equality should be transitive.
  28.  
  29. I already mentioned interval arithmetic, for which this does not hold.
  30. You said that there didn't appear to be a good equality operation for
  31. interval arithmetic, which is quite possibly true, but doesn't mean
  32. that I don't want to use it. If so, your system would need to allow
  33. things for which there is no equality operation.
  34.  
  35. >4) Substitution of equals for equals should give equals.
  36. >5) If two objects are equal at one point in program execution, they should be
  37. >     equal at all points. 
  38.  
  39. If you have this condition, then you have to use identity or else have
  40. immutable values. I don't see why it should have to hold. 
  41.  
  42. >6) Assignment should respect equality.   (Assuming no side-effects, after 
  43. >   executing x:=a; it should be true that x=a.
  44.  
  45. This also fails for IEEE floating point arithmetic. 
  46.  
  47. >7) If your parameter passing model is based on assignment, 6) should hold 
  48. >   mutatis mutandi.
  49. This too. 
  50.  
  51. >8) If two objects are equal, they should be behaviourally indistinguishable. 
  52. >   The converse need not hold, but often will.
  53.  
  54. For graphs, one might wish to consider isomorphic graphs equal.
  55.  
  56. >9) Two sets A,B are equal iff  for_all(x:A)there_exists(y:B) such y=x, and
  57. >   vice versa.
  58.  
  59. Apparently sets are not objects, since one has an equality operation
  60. for them which is not the same as that for other objects (identity).
  61. If I make my own implementation of sets, or some other type of
  62. collection, which equality do I use.
  63.  
  64. >Given mutable objects, identity was the only practical definition I found
  65. >which would  support all of the above.  However, identity is not a practical 
  66. >equality definition for all objects we wish to program with (vis, integers). 
  67. >In these cases, if immutability holds, users may be able to define equality
  68. >in ways which satisfy the above, and there are good reasons to let them try. 
  69.  
  70. Removing condition 5 would make it rather easier.  
  71.  
  72. One might also have functions as objects, which might satisfy all of
  73. those conditions but not be identical.
  74.  
  75. >This is comp.object, so presumably when people talk equality here, they don't 
  76. >mean bitwise or address equality, although these may be used as implementation 
  77. >techniques.   The following questions also arise do to object orientation: 
  78. >May two objects of different classes be equal?  May two objects be equal even 
  79. >if they don't respond to the same protocol?  If they respond to the same 
  80. >protocol but have no common superclass which defines that protocol 
  81. >(i.e. protocol similarity is incidental)?  
  82.  
  83. How about 1.0 = 1
  84.           1/1 = 1
  85.           1+0i = 1
  86.  
  87. These are certainly of different classes, and they might have a
  88. different protocol (depending if operations like mantissa or imaginary
  89. part are implemented for integers).
  90.  
  91. >If programmers view equality as just another binary predicate, perhaps I 
  92. >should come up with a different name for the operation I need.  Any 
  93. >suggestions?
  94.  
  95. How about identity? 
  96.  
  97. I think that you are trying to take a very strong definition of
  98. equality that can work for some mathematical abstractions and apply it
  99. to everything.  I don't think this definition of equality is universal
  100. in mathematics either. One often refers to two sides of a triangle
  101. being equal, meaning that their lengths are equal. I, and others, have
  102. already mentioned graphs.
  103.  
  104. -- 
  105.  Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x1027 
  106.  Dept. of Mechanical and Aerospace Engineering              
  107.  Carleton University, Ottawa, Ontario, Canada, K1S 5B6      
  108.  
  109.