Comparing UDTs with same structure

[norbert doerre]

There exist two UDT constructs with each 288 items to be compared to each other. As soon as the first result (tf) becomes true, the function should end.
The "Do Until" statement below is only to show my intention. In fact, it does not stop the code execution if tf becomes %True.
I simply don't know the syntax of PB to manage this. A direct compare such as "if CurrentDim = DbaseDim then" fails.

Function CompareDim(CurrentDim as DimSett, DbaseDim as DimSett) as long
local tf as long
Do Until tf = %True 'this line shows my intention
tf = CurrentDim.angle <> DbaseDim.angle
tf = CurrentDim.angleFormat <> DbaseDim.angleFormat
tf = CurrentDim.Arrow = DbaseDim.Arrow
tf = CurrentDim.ArrowAngle <> DbaseDim.ArrowAngle
tf = CurrentDim.ArrowMode <> DbaseDim.ArrowMode
tf = CurrentDim.ArrowSize <> DbaseDim.ArrowSize
tf = CurrentDim.aspect <> DbaseDim.aspect
tf = CurrentDim.bold <> DbaseDim.bold
tf = CurrentDim.charSpace <> DbaseDim.charSpace
....
....
....

[Michael Mattias]

>A direct compare such as "if CurrentDim = DbaseDim then" fails.

That should succeed. Show failing code.

But there's an option:

FUNCTION CompareDim (C AS DimSet, D AS DimSet) AS LONG 
 LOCAL pC AS BYTE PTR, pD  AS BYTE PTR 
 LOCAL L as long, I as long

  L   = SIZEOF(C) 
  pC = VARPTR(C) 
  pD = VARPTR(D) 
  FOR I  = 1 TO L 
     IF  (@pc XOR @pD)    THEN    ' XOR==> 0 if equal
       FUNCTION = %FALSE   ' UDTs not equal
       EXIT FUNCTION
    ELSE 
      INCR pC
      INCR pD 
   END IF 
  NEXT 

  FUNCTION = %TRUE  ' UDTs are equal 

END FUNCTION

MCM

[Chris Holbrook]

There exist two UDT constructs with each 288 items to be compared to each other. As soon as the first result (tf) becomes true, the function should end.

Provided that each string or asciz component was zero-, or some other conventional value- filled before being populated, you could just compare the two UDTs as blocks of memory which could be done very efficiently.

[norbert doerre]

Question with sub-UDTs

Michael, I omitted that the UDT contains three small sub-UDTs. Perhaps this is the reason why it fails comparing them? Should i 'explode' the items of the sub UDTs completely into the main UDT?

[Paul Squires]

I agree with Chris that you should be able to just compare the two blocks of memory. It doesn't matter if there are 2 or 200 subtypes in the type. If you want a simple Yes/No that the Types are the same then simply compare them. If you want to know exactly where they differ then the exercise becomes more involved.

#Compile Exe
#Dim All


Type SubType
   x As Long
   y As Integer
   z As Byte
End Type

Type DimSett
  a As Asciiz * 100
  b As Long
  c As Byte
  TheSub As SubType
End Type



Function PBMain() As Long

   Local CurrentDim As DimSett
   Local dBaseDim   As dimSett
   
   CurrentDim.a = "Paul Squires"
   CurrentDim.b = 500
   CurrentDim.c = 1
   CurrentDim.TheSub.z = 100
   
   dBaseDim.a   = "Paul Squires"
   dBaseDim.b   = 500
   dBaseDim.c   = 1
   dBaseDim.TheSub.z = 100
   
   
   If CurrentDim = dBaseDim Then
      ? "Types are equal"
   Else
      ? "Types are different"
   End If      

End Function

[Michael Mattias]

>Perhaps this is the reason why it fails comparing them?

===> [email protected]. Include failing source code and compiler version.

[Chris Holbrook]

I agree with Chris

Hurrah!

If you want to know exactly where they differ then the exercise becomes more involved.

by getting the offset of the "point of difference" you can work out which member of the UDT differs without doing a string of comparisons - providing that your comparison routine can run in the same order that the UDT members are declared.

[John Gleason]

Something like this will exit the function immediately with the proper return value:

#COMPILE EXE
#DIM ALL
TYPE dimSett
   angle             AS SINGLE
   angleFormat       AS STRING * 10
   Arrow             AS STRING * 10
   ArrowAngle        AS SINGLE
   ArrowMode         AS LONG
   ArrowSize         AS LONG
   aspect            AS LONG
   BOLD              AS LONG        'is bold reserved word?
   charSpace         AS LONG
END TYPE

FUNCTION PBMAIN () AS LONG
    LOCAL CurrentDim, DbaseDim AS dimSett, returnVal AS LONG
    
    returnVal = compareDim(currentDim, DbaseDim)
    IF returnVal <> 0 THEN
       ? "Comparison was true with a match at member" & STR$(returnVal)
    ELSE
       ? "Comparison was not true"
    END IF

END FUNCTION

FUNCTION CompareDim(CurrentDim AS DimSett, DbaseDim AS DimSett) AS LONG
'local tf as long
'Do Until tf = %True 'this line shows my intention
IF CurrentDim.angle <> DbaseDim.angle             THEN FUNCTION = 1: EXIT FUNCTION
IF CurrentDim.angleFormat <> DbaseDim.angleFormat THEN FUNCTION = 2: EXIT FUNCTION
IF CurrentDim.Arrow = DbaseDim.Arrow              THEN FUNCTION = 3: EXIT FUNCTION
IF CurrentDim.ArrowAngle <> DbaseDim.ArrowAngle   THEN FUNCTION = 4: EXIT FUNCTION
IF CurrentDim.ArrowMode <> DbaseDim.ArrowMode     THEN FUNCTION = 5: EXIT FUNCTION
IF CurrentDim.ArrowSize <> DbaseDim.ArrowSize     THEN FUNCTION = 6: EXIT FUNCTION
IF CurrentDim.aspect <> DbaseDim.aspect           THEN FUNCTION = 7: EXIT FUNCTION
IF CurrentDim.bold <> DbaseDim.bold               THEN FUNCTION = 8: EXIT FUNCTION
IF CurrentDim.charSpace <> DbaseDim.charSpace     THEN FUNCTION = 9: EXIT FUNCTION
'....
'....
'....
END FUNCTION

[norbert doerre]

A floating point number problem with myself

Folks, I found the bugs!
1. Never format floating point numbers in a debug listing limiting them to 3 decs just to see them better.
2. Never do a floating number compare wihout knowing they are correctly rounded.
3. Be shure that dialog user inputs correspond to the defined floating point dec places in your code.

The bug of non comparable UDTs came from just ignoring their validity.
The content of the two UDTs was planned with full range 10^-14 floating point numbers. I'm doing this to be able to campare the numbers by view in my debugger. As long as they are not rounded to 12 decs, there may exist a difference at the last two dec places.
So, I generally round them to 12 places. In this case the numbers are used only for sizing internal graphical dimension items. So, 12 dec places are more than enough. But there exists a dialog, where user can edit these many values manually. In all these cases, a number with three dec places is enough for input. But then, after reading the dialog contents, I have to compare a possibly three dec number with a 12 dec number.....
I think I can ommit the rest of my tale.
The reason why this can happen with PB ist that you cannot dynamically view the progress of running large code with in this case 16 DLLs step by step.

[Michael Mattias]

(Note to self for list of "Top Ten Things Every PB Programmer Should Know": Learn the differences between the available data types and select types for your variables based on requirements to compare, round or perform mathematical operations thereon. Understand the ramifications of overflow, underflow, rounding and the automatic type conversions performed by the compiler, including such overflow, underflow and rounding which may occur in an intermediate value computed within an expression." )