none
Defining = operator without <> operator RRS feed

  • Question

  • Hi,

    I am surprised to find that I cannot define the "=" operator for a class without including the definition of "<>" operator. Why the compiler insists on this? What is the big problem to define "=" without defining "<>"? I think "<>" is nothing more than the opposite of "=", so why does the compiler need to define it too??

    Is it really necessary for the compiler to add something like this

            Public Shared Operator <>(ByVal a As TestClass, ByVal b As TestClass) As Boolean
                Return Not a = b
            End Operator

    I feel that the compiler should understand it intuitively without the necessity to define <>.

    Thanks to any replies.

    Friday, March 22, 2013 8:01 PM

Answers

  • My other point aside, if you're comparing two classes then you're going about it incorrectly.

    Defining (or overloading) the various equality operators for a class is the correct way to allow value comparisons of two instances of that class.    The '=' operator is not a mathematical operator - it is a logical operator that evaluates to either True or False.

    It is quite proper, and very common, to define the '=' operator for a class with multiple properties.  Without it, the class does not have a value comparison.   The developer needs to decide which properties must match for two instances to be declared equal, and, if those properties are themselves objects, whether that equality is value equality or reference equality.  The meaning of '=' is specific to a class and does not necessarily mean that the two instances are identical in all respects.

    Microsoft says " You do generally need to overload the logical operators in pairs. These paired cases include = and <>, ..."  The point that OP is making is that since the only valid definition for '<>' is 'Not A = B' why does the developer need to do this - surely the compiler can work it out.  Or, at least, it should not be required for the developer to define it, but it should default.

    Ref: http://msdn.microsoft.com/en-us/library/ms379613(v=vs.80).aspx


    • Edited by Acamar Saturday, March 23, 2013 2:15 AM sp
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:42 PM
    Saturday, March 23, 2013 2:10 AM
  •  

    This seems to be pretty good, but I can't think of any example .Can you please give an example where (a<>b) is not simply (Not a=b) (if possible)?

    I think it very difficult to have such situation because it requires that a<>b and a=b are both true or both false. These expressions after all are not probabilities.

    When dealing with undeterministic state, an object can be in an know state or unknow state.

    Usualy, "True" will be used as the known state, so when = or <> return True, the object will be considered to in the specified state.

    if false, then the object is in an unknown state

    This situation is quite frequent when working with Statistic

    But, Let take a simple example, ... a patient in a hepatitis clinic

    then if

    patient = New InfectedPatient

    return true, we know that the patient is infected : True is deterministic

    but if return false, it doesn't means that he is not infected, it can be because the "Test_Are_Conclusive" property is false or because the property "HasPassTheTest" is false

    The same way, if

    patient <> new notInfectedPatient

    return true, it is deterministic, we know thet he is not an Not infected patient, but if it return false, it doesn't means that he is infected, for that same reason as before

    <> is not (Not = )

    Public Class Form1
    
        Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    
            Dim Patient1 As New Patient With {.HasPass_HepatiA_Test = True,
                                              .IsInfected = True}
    
            Dim Patient2 As New Patient With {.HasPass_HepatiA_Test = False}
    
            Dim Dum
            Dum = (Patient1 = New InfectedPatient) ' True : it is deterministic
    
            Dum = (Patient1 <> New NonInfectedPatient) ' True :  it is deterministic
    
            Dum = (Patient2 = New InfectedPatient) ' return false :  But any false result is not deterministic -- patient2 may be infected
    
        End Sub
    End Class
    
    
    Interface IPatient
        Property HasPass_HepatiA_Test As Boolean
        Property IsInfected As Boolean
    End Interface
    
    
    Class Patient : Implements IPatient
        Public Property PatientID As String
        Public Property HasPass_HepatiA_Test As Boolean Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean Implements IPatient.IsInfected
        Public Shared Operator =(ByVal PatientA As Patient, ByVal PatientB As IPatient) As Boolean
            If PatientA.HasPass_HepatiA_Test Then
                If PatientA.IsInfected = PatientB.IsInfected Then
                    Return True
                End If
            End If
            Return False
        End Operator
    
        Public Shared Operator <>(ByVal PatientA As Patient, ByVal PatientB As IPatient) As Boolean
            If PatientA.HasPass_HepatiA_Test Then
                If PatientA.IsInfected <> PatientB.IsInfected Then
                    Return True
                End If
            End If
            Return False
        End Operator
    End Class
    
    
    Class InfectedPatient : Implements IPatient
        Public Property HasPass_HepatiA_Test As Boolean = True _
              Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean = True _
               Implements IPatient.IsInfected
    End Class
    
    
    Class NonInfectedPatient : Implements IPatient
        Public Property HasPass_HepatiA_Test As Boolean = True _
              Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean = False _
               Implements IPatient.IsInfected
    End Class

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:38 PM
    Saturday, March 23, 2013 5:11 PM
  • "There are cases that a Boolean expression is not well known whether it is true or false; there is only probability of each; in these cases both = and <> should return false"

    Is that true? 

    'Proabalistic' is just a different way of calculating True and False, and does not affect the VB requirement that 'Not =' must be the same as '<>'.

    With a non-deterministic variable you can have three states (or the range of values of the non-deterministic variable can be classifed into one of three states):
      True
      Not Known
      False

    In that case the usual truth table is
    True and True --> True
    True and Not Known --> False
    True and False --> False
    Not Known and NotKnown -->False
    False and Not Known --> False
    False and False -->False

    but other arrangements are possible:
    True And True --> True
    True And Not Known --> True
    True and Flase --> False
    Not Known and Not Known --> False
    False And Not Known --> False
    False and False --> False

    If different truth tables are applied for the '=' and '<>' operators then it is possible to create a comparison in which '=' and '<>' return the same result.  For VB, that would break the logical rules of the language.

    Whatever truth table is applied, the same table must be applied for the VB operators '=' and '<>' in order to preserve the logical rules of the language. Both '=' and '<>' can never return the same result for the same comparison of values.

    It is possible to create a trinary boolean system, which is usually described as
      True
      Indeterminate
      False

    and the truth table is
      True and True --> True
      True and Indeterminate --> Indeterminate
      True and False --> False
      Indeterminate and Indeterminate --> Indeterminate
      False and Indeterminate --> False
      False and False --> False

    which is an important part of fuzzy logic.

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:48 PM
    Sunday, March 24, 2013 10:37 AM
  • Hi,

     I would put the reason down to this,

    "COMPUTERS ARE DUMB MACHINES"

    They need to be programmed with operators in order that they can work correctly.

    It is like trying to tell a child an ORANGE is similar to another ORANGE

    but an ORANGE is NOT an APPLE.

    How else would you get a program to return TRUE when one thing is NOT EQUAL
    to another thing and
    return FALSE when they are equal for the NOT EQUAL operator?

    Additionally your definition of NOT EQUAL
    for two objects may differ to that from someone else so you may not want to
    RETURN NOT a = b

    Consider two red Ferrari cars. You may say they are equal.

    Others may say they are not as they are not the same object.

    You may want to consider a triple state for objects when two objects are similar.

    EQUAL, NOT EQUAL or SIMILAR.

    Now there is something else to think about perhaps?

    The trouble is though, computers are binary, ones and zeroes, TRUE or FALSE.

    So we need to be more definite with our definitions.
     I'm not sure if a tri-state computer has been invented yet!!


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.


    • Edited by John Anthony Oliver Friday, March 22, 2013 10:34 PM
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:52 PM
    Friday, March 22, 2013 10:19 PM
  • Hi John. It is certainly possible for the compiler to decide that if the "=" comparison operator has been overridden (with a function that returns a Boolean) that the "<>" operator should be interpreted as returning the opposite of the "=" operator.  

    I can only assume that Microsoft want to leave open the possibility that you might want "<>" to mean something other than Not "=".  However I agree with Acamar that it would be bad practice to take advantage of that possibility.

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:42 PM
    Saturday, March 23, 2013 12:56 AM
  •  =  and <>  are deterministic state,

    Then, when comparing 2 process, if they are = then it means that the outcome of the 2 process is the same, and if they are <> then it means that the outcome is not the same.

    however, when working with outcome that are base on probability, the outcome are often not deterministic and there are a region of possible outcome where the = or <> is in an indermined state.

    therefore "<>"  is then not equal to "Not =" on a process where the outcome is base on probability of a certain outcome.

    If the VB compiler was implementing <> for you as being "Not =" then the operator would becomes unusable in such situation



    • Edited by Crazypennie Saturday, March 23, 2013 2:05 PM
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:47 PM
    Saturday, March 23, 2013 2:01 PM

All replies

  • Hi,

     I would put the reason down to this,

    "COMPUTERS ARE DUMB MACHINES"

    They need to be programmed with operators in order that they can work correctly.

    It is like trying to tell a child an ORANGE is similar to another ORANGE

    but an ORANGE is NOT an APPLE.

    How else would you get a program to return TRUE when one thing is NOT EQUAL
    to another thing and
    return FALSE when they are equal for the NOT EQUAL operator?

    Additionally your definition of NOT EQUAL
    for two objects may differ to that from someone else so you may not want to
    RETURN NOT a = b

    Consider two red Ferrari cars. You may say they are equal.

    Others may say they are not as they are not the same object.

    You may want to consider a triple state for objects when two objects are similar.

    EQUAL, NOT EQUAL or SIMILAR.

    Now there is something else to think about perhaps?

    The trouble is though, computers are binary, ones and zeroes, TRUE or FALSE.

    So we need to be more definite with our definitions.
     I'm not sure if a tri-state computer has been invented yet!!


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.


    • Edited by John Anthony Oliver Friday, March 22, 2013 10:34 PM
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:52 PM
    Friday, March 22, 2013 10:19 PM
  • OP's point is that the <> operator should never be defined as anything other than Not A=B.  Individual definitions for the two operators creates a risk of inconsistency that would break the language definition, so why should it even be possible to define both separately?
    Friday, March 22, 2013 10:42 PM
  • OP's point is that the <> operator should never be defined as anything other than Not A=B.  Individual definitions for the two operators creates a risk of inconsistency that would break the language definition, so why should it even be possible to define both separately?

    Hi Acamar,

     I get what you are saying but how is a computer going to test for "NOT EQUAL"

    when you only type the following lines

    If a <> b Then

    'Some code here.

    End If

    'A computer will fail as the operator <> would not be understood by the underlying code.

    'I guess the I.D.E. adds the <> operator in order to maintain consistency.

    '

    'Not all coders are going to write

    If Not ( a = b ) Then

    'Some code here.

    End If

    'or even

    If ( a = b ) = TRUE Then

    'Some code here.

    End If

    'or even

    If ( a = b ) = FALSE Then

    'Some code here.

    End If


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.

    Saturday, March 23, 2013 12:21 AM
  • I get what you are saying but how is a computer going to test for "NOT EQUAL"

    No-one is suggesting that it's not necessary to actually implement the <> operator.  The point is that it should not be up to the developer to do it, because it should never be defined as anything other than 'Not A = B'.  If the operator can only ever be defined as 'Not A = B' then the compiler should force that definition, and not leave it up to the developer to create it.

    Saturday, March 23, 2013 12:48 AM
  • Hi John. It is certainly possible for the compiler to decide that if the "=" comparison operator has been overridden (with a function that returns a Boolean) that the "<>" operator should be interpreted as returning the opposite of the "=" operator.  

    I can only assume that Microsoft want to leave open the possibility that you might want "<>" to mean something other than Not "=".  However I agree with Acamar that it would be bad practice to take advantage of that possibility.

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:42 PM
    Saturday, March 23, 2013 12:56 AM
  • No-one is suggesting that it's not necessary to actually implement the <> operator.  The point is that it should not be up to the developer to do it, because it should never be defined as anything other than 'Not A = B'.  If the operator can only ever be defined as 'Not A = B' then the compiler should force that definition, and not leave it up to the developer to create it.

    What language supports what you're suggesting?

    Besides...

    Private Function Pointless(ByVal arg1 As Integer, _ ByVal arg2 As Integer) _ As Boolean ' If arg1 = arg2 Then Return True Else Return False End If ' End Function

    Is that really too much to ask the developer to do?

    Please call me Frank :)

    Saturday, March 23, 2013 1:03 AM
  • BGQQ,

    My other point aside, if you're comparing two classes then you're going about it incorrectly. If you want to compare certain properties or fields in the class, then your syntax is wrong; if you want to literally see if the two instances are the same (the same reference), then use the "Is" and/or "IsNot", not a mathematical operator.


    Please call me Frank :)

    • Proposed as answer by John Anthony Oliver Saturday, March 23, 2013 1:52 AM
    • Unproposed as answer by BGQQ Saturday, March 23, 2013 3:31 PM
    Saturday, March 23, 2013 1:11 AM
  • Hi ALL,

    What about two identical objects then?

    Would you say they are EQUAL or SIMILAR?

    Object A and Object B are identical but

    Object A <> Object B

    Object A is not Object B ( therefore Object B is not Object A ).

    What then?

    You have to then think about what you want from your own code I guess.

    I code put 10 Buttons all called Button1 on a Form but they would not be the same object.

    >>

    Imports System.Drawing.Color
    Public Class Form1
    
        Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    
            Me.WindowState = FormWindowState.Maximized
            Dim colors() As Color = New Color() {Red, Orange, Yellow, Green, Blue, Indigo, Violet, Pink, Goldenrod, Salmon}
    
            Dim btn As Button = Nothing
            For index As Integer = 0 To 9
                btn = New Button
                btn.BackColor = colors(index)
                btn.Text = "Button1"
                btn.Name = "Button1"
                btn.Size = New Size(100, 25)
                btn.Location = New Point(100, index * 30 + 5)
                Me.Controls.Add(btn)
            Next
    
        End Sub
    End Class


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.


    Saturday, March 23, 2013 1:52 AM
  • My other point aside, if you're comparing two classes then you're going about it incorrectly.

    Defining (or overloading) the various equality operators for a class is the correct way to allow value comparisons of two instances of that class.    The '=' operator is not a mathematical operator - it is a logical operator that evaluates to either True or False.

    It is quite proper, and very common, to define the '=' operator for a class with multiple properties.  Without it, the class does not have a value comparison.   The developer needs to decide which properties must match for two instances to be declared equal, and, if those properties are themselves objects, whether that equality is value equality or reference equality.  The meaning of '=' is specific to a class and does not necessarily mean that the two instances are identical in all respects.

    Microsoft says " You do generally need to overload the logical operators in pairs. These paired cases include = and <>, ..."  The point that OP is making is that since the only valid definition for '<>' is 'Not A = B' why does the developer need to do this - surely the compiler can work it out.  Or, at least, it should not be required for the developer to define it, but it should default.

    Ref: http://msdn.microsoft.com/en-us/library/ms379613(v=vs.80).aspx


    • Edited by Acamar Saturday, March 23, 2013 2:15 AM sp
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:42 PM
    Saturday, March 23, 2013 2:10 AM
  • What language supports what you're suggesting?

    Visual Basic does, and I think that's common across all the framework languages.  Operator overloading appered with VS2005.

    Saturday, March 23, 2013 2:14 AM
  • I don't have to decide if the objects are equal or similar. I understand that there can be several ways of defining equality. The programmer who codes the function that overrides the "=" operator decides what equality is. What I am saying is that once the programmer has made that decision then he or she should not make a different decision when creating the function that overrides the "<>" operator, and in that case, I don't see why "<>" should not be automatically defined as Not "=".
    Saturday, March 23, 2013 2:17 AM
  • ... there can be several ways of defining equality.

    That seems to be the only thing that everyone in this thread agrees with. :-)

    *****

    I'll leave it to the pro's - g'night all. :)


    Please call me Frank :)

    Saturday, March 23, 2013 2:31 AM
  • ... there can be several ways of defining equality.

    That seems to be the only thing that everyone in this thread agrees with. :-)

    *****

    I'll leave it to the pro's - g'night all. :)


    Please call me Frank :)

    Goodnight Frank.  I think the reason this thread is running on is that there seems to be a misunderstanding. I don't think anyone disagrees that there can be different ways of deciding whether one object "equals" another. Microsoft allows for that by letting the programmer override the "=" operator for a particular class. The point that some of us are trying to make is that once the programmer has decided what "=" means, then "<>" should logically always mean the opposite. 
    Saturday, March 23, 2013 2:52 AM
  • Hi BGQQ,

    To overrload an operator such as "=" in VB.NET——Yes, "=" is really having nothing to do with "<>", but:

    1) For struct comparation, "=" will compare values.

    2) For class comparation, the default "=" means to compare class instances' memory address (this means two instances will NEVER equal to each other). And maybe this isn't what we want actually in some very special situations;)

    Bcoz considering the main two reasons, Microsoft should force u to define a pair of operators' symbols to include all the situations to tell CLR what a customer wanna do.


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats

    Saturday, March 23, 2013 3:17 AM
  • For class comparation, the default "=" means to compare class instances' memory address (this means two instances will NEVER equal to each other). And maybe this isn't what we want actually in some very special situations;)

    "very special situations"? I don't think so.  It is very common to do value comparisons of class instances.    String is an example that would occur fairly often in a typical application.

    Saturday, March 23, 2013 4:02 AM
  • Acamar,

    What I mean is:

    Generally speaking, "=" will compare the instance of classes' addresses in default, but we usually don't do so for special situations, we wanna compare with properties.


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats

    Saturday, March 23, 2013 4:05 AM
  • I find it surprising that somebody wants to compare a reference type with the operator = or <>

    What do you think you are comparing?

    I'm more surprised that you can in this situation compare reference type objects with = (whatever it will return). Like John Oliver already wrote is for that the IsEqual method. 

    Beside that would it in my perception crazy if you use the defined overloaded Operator in itself. What should it then take in your situation. The overloaded or the non overloaded or maybe once the overloaded and sometimes the not overloaded one?


    Success
    Cor

    Saturday, March 23, 2013 8:32 AM
  • @Cor Ligther,

    Look at OP's codes:

     Public Shared Operator <>(ByVal a As TestClass, ByVal b As TestClass) As Boolean
                Return Not a = b
            End Operator

    If he/she doesn't rewrite the operator "=", the result will be ALWAYS False, if he/she tries to compare two different kinds of instances.....So I suspect from the codes that OP will try to use the default "=", which is to compare instance's referrance in default.


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats

    Saturday, March 23, 2013 9:04 AM
  • I find it surprising that somebody wants to compare a reference type with the operator = or <>

    If you are not creating value comparisons for you classes you are writing a lot of unnecessary code.  You are probably writing lines such as

        If A.Property1 = B.Property1 AndAlso A.Property2 = B.Property2 AndAlso A.Property3 = B.Property3 Then ...

    which a) is far more wordy than it needs to be and b) should be part of the class definition, not part of the application code.

    Saturday, March 23, 2013 9:52 AM
  • @ProgrammingVolunteer

    This is what I wanted to say in code without Operator overloading.

    That you use operator overloading should not mean that you can do more than normal things.

    Public Class TestClassA
        Public Function CompareMe(A As TestClassA, B As TestClassA) As Boolean
            If A = B Then Return False 'wont compile gives an error
            Return True
        End Function
    End Class
    Public Class TestClassB
        Public Function CompareMe(A As TestClassB, B As TestClassB) As Boolean
            If A.Equals(B) Then Return False 'normal way to compare classes
            Return True
        End Function
        'The bellow one looks weird to me it would never return'
        ' something sensefull probably it even goes in a recursive loop
        Public Function CompareMe2(A As TestClassB, B As TestClassB) As Boolean
            If Not CompareMe2(A, B) Then Return False
            Return True
        End Function
    End Class


    Success
    Cor


    Saturday, March 23, 2013 11:00 AM
  • Cor Lighthert,

    U are quite right, very sorry I've confused that with C#;)

    In C#, "==" is to used to check whether two reference instances refers the same place or not. But in VB.NET, it equals to "Is"; Compared with this, VB.NET "=" is used to do comparation with real struct type only instead of comparation between two reference type. So the codes below will raise compiling error:

    Module Module1
        Public Class A
     
        End Class
        Public Class B
     
        End Class
        Sub Main()
            Dim a As New A
            Dim b As New B
            Console.WriteLine(a = b) 'This is wrong in compilation!!!!!!!!
        End Sub
     
    End Module

    So u must define "=" in VB.NET to compare two values for instances;)


    If you think one reply solves your problem, please mark it as An Answer, if you think someone's reply helps you, please mark it as a Proposed Answer

    Help by clicking:
    Click here to donate your rice to the poor
    Click to Donate
    Click to feed Dogs & Cats

    Saturday, March 23, 2013 12:54 PM
  •  =  and <>  are deterministic state,

    Then, when comparing 2 process, if they are = then it means that the outcome of the 2 process is the same, and if they are <> then it means that the outcome is not the same.

    however, when working with outcome that are base on probability, the outcome are often not deterministic and there are a region of possible outcome where the = or <> is in an indermined state.

    therefore "<>"  is then not equal to "Not =" on a process where the outcome is base on probability of a certain outcome.

    If the VB compiler was implementing <> for you as being "Not =" then the operator would becomes unusable in such situation



    • Edited by Crazypennie Saturday, March 23, 2013 2:05 PM
    • Marked as answer by BGQQ Sunday, March 24, 2013 8:47 PM
    Saturday, March 23, 2013 2:01 PM

  • Microsoft says " You do generally need to overload the logical operators in pairs. These paired cases include = and <>, ..."  The point that OP is making is that since the only valid definition for '<>' is 'Not A = B' why does the developer need to do this - surely the compiler can work it out.  Or, at least, it should not be required for the developer to define it, but it should default.

    Ref: http://msdn.microsoft.com/en-us/library/ms379613(v=vs.80).aspx


    Yes this is exactly my point, thanks for clarification.
    Saturday, March 23, 2013 3:25 PM
  •  =  and <>  are deterministic state,

    Then, when comparing 2 process, if they are = then it means that the outcome of the 2 process is the same, and if they are <> then it means that the outcome is not the same.

    however, when working with outcome that are base on probability, the outcome are often not deterministic and there are a region of possible outcome where the = or <> is in an indermined state.

    therefore "<>"  is then not equal to "Not =" on a process where the outcome is base on probability of a certain outcome.

    If the VB compiler was implementing <> for you as being "Not =" then the operator would becomes unusable in such situation



    This seems to be pretty good, but I can't think of any example .Can you please give an example where (a<>b) is not simply (Not a=b) (if possible)?

    I think it very difficult to have such situation because it requires that a<>b and a=b are both true or both false. These expressions after all are not probabilities.

    • Edited by BGQQ Saturday, March 23, 2013 3:29 PM
    Saturday, March 23, 2013 3:27 PM

  • 'I guess the I.D.E. adds the <> operator in order to maintain consistency.

    Here is the point, so why it is allowed for the developer to implement it if the compiler can interpret it in terms = operator
    Saturday, March 23, 2013 3:40 PM
  • BGQQ,

    My other point aside, if you're comparing two classes then you're going about it incorrectly. If you want to compare certain properties or fields in the class, then your syntax is wrong; if you want to literally see if the two instances are the same (the same reference), then use the "Is" and/or "IsNot", not a mathematical operator.


    Please call me Frank :)

    That's true, but it works! Maybe the compiler is clever enough to deal with it, here is my simple example:

    Option Strict On
    
    Public Class Form1
    
        Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
            Dim a As New AB
            Dim b As New AB
            Dim c As New AB
            a.x = 2
            b.x = 2
            c.x = 3
            Me.Text = (a = b).ToString & " --- " & (a = c).ToString
        End Sub
    
        Public Class AB
            Public x As Double
            Public Shared Operator =(ByVal a As AB, ByVal b As AB) As Boolean
                Return a.x = b.x
            End Operator
    
            Public Shared Operator <>(ByVal a As AB, ByVal b As AB) As Boolean
                Return Not a = b
            End Operator
        End Class
    
    End Class
    Mmmmmm, this really baffled me, it should not work, but it works! I have tried different variations, and the compiler seems to be able to handle correctly. Maybe I have to study it more, and if I didn't get it, then it is possible to post it in another thread. Anyway thanks to the notification.


    • Edited by BGQQ Saturday, March 23, 2013 4:06 PM
    Saturday, March 23, 2013 3:42 PM

  • I can only assume that Microsoft want to leave open the possibility that you might want "<>" to mean something other than Not "=".  However I agree with Acamar that it would be bad practice to take advantage of that possibility.

    The problem is that it obliges the developer to do so!
    Saturday, March 23, 2013 3:46 PM
  • I would agree that it would be nice if the IDE generated a stub for <> that was

    Return not (a = b)

    but it doesn't. 

    However there is a code Snippet that supplies stubs for = and <>.  You could modify the snippet so that it did the default action you are suggesting.  Here is the modified snippet


        Public Shared Operator =(ByVal left As Example, ByVal right As Example) As Boolean

        End Operator

        Public Shared Operator <>(ByVal left As Example, ByVal right As Example) As Boolean
            Return Not (left = right)
        End Operator

    "Those who use Application.DoEvents() have no idea what it does and those who know what it does never use it." JohnWein



    • Edited by dbasnett Saturday, March 23, 2013 3:54 PM
    Saturday, March 23, 2013 3:52 PM

  • I think it very difficult to have such situation because it requires that a<>b and a=b are both true or both false. These expressions after all are not probabilities.

    Hi,

    Take two identical objects.

    E.G:

    2 Black Lamborghini Diablo cars.>>

    Black Lamborghini Diablo Car

    Black Lamborghini Diablo Car

    They are both equal in that they look identical but they are

    different objects ( therefore not entirely equal )

    as they do not occupy the same space ( even in this reply post ).  :-D

    You have to decide in your code, when creating objects when two objects ( via references or otherwise ) are equal or not.


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.

    Saturday, March 23, 2013 3:59 PM
  •  

    This seems to be pretty good, but I can't think of any example .Can you please give an example where (a<>b) is not simply (Not a=b) (if possible)?

    I think it very difficult to have such situation because it requires that a<>b and a=b are both true or both false. These expressions after all are not probabilities.

    When dealing with undeterministic state, an object can be in an know state or unknow state.

    Usualy, "True" will be used as the known state, so when = or <> return True, the object will be considered to in the specified state.

    if false, then the object is in an unknown state

    This situation is quite frequent when working with Statistic

    But, Let take a simple example, ... a patient in a hepatitis clinic

    then if

    patient = New InfectedPatient

    return true, we know that the patient is infected : True is deterministic

    but if return false, it doesn't means that he is not infected, it can be because the "Test_Are_Conclusive" property is false or because the property "HasPassTheTest" is false

    The same way, if

    patient <> new notInfectedPatient

    return true, it is deterministic, we know thet he is not an Not infected patient, but if it return false, it doesn't means that he is infected, for that same reason as before

    <> is not (Not = )

    Public Class Form1
    
        Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    
            Dim Patient1 As New Patient With {.HasPass_HepatiA_Test = True,
                                              .IsInfected = True}
    
            Dim Patient2 As New Patient With {.HasPass_HepatiA_Test = False}
    
            Dim Dum
            Dum = (Patient1 = New InfectedPatient) ' True : it is deterministic
    
            Dum = (Patient1 <> New NonInfectedPatient) ' True :  it is deterministic
    
            Dum = (Patient2 = New InfectedPatient) ' return false :  But any false result is not deterministic -- patient2 may be infected
    
        End Sub
    End Class
    
    
    Interface IPatient
        Property HasPass_HepatiA_Test As Boolean
        Property IsInfected As Boolean
    End Interface
    
    
    Class Patient : Implements IPatient
        Public Property PatientID As String
        Public Property HasPass_HepatiA_Test As Boolean Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean Implements IPatient.IsInfected
        Public Shared Operator =(ByVal PatientA As Patient, ByVal PatientB As IPatient) As Boolean
            If PatientA.HasPass_HepatiA_Test Then
                If PatientA.IsInfected = PatientB.IsInfected Then
                    Return True
                End If
            End If
            Return False
        End Operator
    
        Public Shared Operator <>(ByVal PatientA As Patient, ByVal PatientB As IPatient) As Boolean
            If PatientA.HasPass_HepatiA_Test Then
                If PatientA.IsInfected <> PatientB.IsInfected Then
                    Return True
                End If
            End If
            Return False
        End Operator
    End Class
    
    
    Class InfectedPatient : Implements IPatient
        Public Property HasPass_HepatiA_Test As Boolean = True _
              Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean = True _
               Implements IPatient.IsInfected
    End Class
    
    
    Class NonInfectedPatient : Implements IPatient
        Public Property HasPass_HepatiA_Test As Boolean = True _
              Implements IPatient.HasPass_HepatiA_Test
        Public Property IsInfected As Boolean = False _
               Implements IPatient.IsInfected
    End Class

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:38 PM
    Saturday, March 23, 2013 5:11 PM
  • You have to decide in your code, when creating objects when two objects ( via references or otherwise ) are equal or not.

    Only for value comparisons - reference comparisons cannot be overridden.   Value comparisons for complex objects will always involve less than the full set of properties of the two objects. 

    But note that has nothing to so with the point that OP is making - it would apply to an override of reference comparisons as much as it does to value comparisons. 

    Saturday, March 23, 2013 8:22 PM
  • @ John

    Nice example..... and nice Diablo cars :)

    But when we decide to compare by value or by reference both <> and = will be of the same type. We can't use = to compare by value and <> to compare by reference...this will create inconsistencies.


    • Edited by BGQQ Sunday, March 24, 2013 8:49 AM
    Sunday, March 24, 2013 8:48 AM

  • @ CrazyPennie

    This is what I have understood:

    "There are cases that a Boolean expression is not well known whether it is true or false; there is only probability of each; in these cases both = and <> should return false"

    Is that true? 


    • Edited by BGQQ Sunday, March 24, 2013 8:53 AM
    Sunday, March 24, 2013 8:53 AM
  • "There are cases that a Boolean expression is not well known whether it is true or false; there is only probability of each; in these cases both = and <> should return false"

    Is that true? 

    'Proabalistic' is just a different way of calculating True and False, and does not affect the VB requirement that 'Not =' must be the same as '<>'.

    With a non-deterministic variable you can have three states (or the range of values of the non-deterministic variable can be classifed into one of three states):
      True
      Not Known
      False

    In that case the usual truth table is
    True and True --> True
    True and Not Known --> False
    True and False --> False
    Not Known and NotKnown -->False
    False and Not Known --> False
    False and False -->False

    but other arrangements are possible:
    True And True --> True
    True And Not Known --> True
    True and Flase --> False
    Not Known and Not Known --> False
    False And Not Known --> False
    False and False --> False

    If different truth tables are applied for the '=' and '<>' operators then it is possible to create a comparison in which '=' and '<>' return the same result.  For VB, that would break the logical rules of the language.

    Whatever truth table is applied, the same table must be applied for the VB operators '=' and '<>' in order to preserve the logical rules of the language. Both '=' and '<>' can never return the same result for the same comparison of values.

    It is possible to create a trinary boolean system, which is usually described as
      True
      Indeterminate
      False

    and the truth table is
      True and True --> True
      True and Indeterminate --> Indeterminate
      True and False --> False
      Indeterminate and Indeterminate --> Indeterminate
      False and Indeterminate --> False
      False and False --> False

    which is an important part of fuzzy logic.

    • Marked as answer by BGQQ Sunday, March 24, 2013 8:48 PM
    Sunday, March 24, 2013 10:37 AM
  • @ Acamar

         when working with statistics, = and <> can never both return True for the same comparison, but they sure can both return False

    the = will usually return true for any case over the 95th or 98th upper percentile and false for the rest of the normal curve

    the <> will usually return true for any case under the 95th or 98th lower percentile and false for the rest of the normal curve

    since, a sample cannot be both over the 95th or 98th upper percentile and under the 95th or 98th lower percentile, then = and <> can never return both True 

    but for all samples that are not into those upper and lower range of the normal curve, = and <> can both return false for a same comparison.

    True means that  a certain degree of confidence has been reach as far as taking or rejecting an hypothesis. False just means that the samples falls somewhere else in our space

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

    Sunday, March 24, 2013 12:14 PM
  • Hi ALL,

    I am liking this thread as the replies here seem to be getting a little complex.  :-D

    @Crazypennie, I've not looked into statistics that much. LOL!!

    @Acamar, I like your post regarding "Not known" / "Indeterminate",

    it reminds me of the case of

    Schrödingers Cat.

    >>

    http://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat


    Regards,

    profile for John Anthony Oliver at Stack Overflow, Q&A for professional and enthusiast programmers

    Click this link to see the NEW way of how to insert a picture into a forum post.

    Installing VB6 on Windows 7

    App Hub for Windows Phone & XBOX 360 developers.


    Sunday, March 24, 2013 3:02 PM
  • Hi

    Thank you all for your replies.

    If we combine all these replies together, I think we reach the following conclusion:

    Visual Basic is a very flexible language that allows you to do much of things even if they may lead to inconsistencies; defining "=" and "<>" is an example. The language makes the developer free to define them as he wants; yet, if "<>" is not defined as "not =", this may lead to difficulty in interpreting the code later for debugging or improvement (breaking the logic rules of the language). Anyway, if the programmer finds it useful in some situations (maybe in cases of probabilities) to change the rule, the language does not deter him.

    IMO, in the cases of probabilities I think it is better to define methods such as GetState, which may return enumeration composed of "True", "False", and "Indeterminate". I think this may be clearer than interpreting the "<>" as not "not =".

    Sunday, March 24, 2013 8:37 PM
  • it reminds me of the case of Schrödingers Cat.

    This description of a trinary logic system actually includes the comment "the UNKNOWN state can be metaphorically thought of as a sealed box containing either an unambiguously TRUE or unambiguously FALSE value."

    Sunday, March 24, 2013 9:45 PM