Re: Array comparison

From: Nicolai Hansen (nic_at_aub.dk)
Date: 10/08/04 

Date: 7 Oct 2004 23:36:52 -0700

> Nicolai Hansen wrote:
> >>Apply the "=" operator to each of the array's elements.
> >
> > And if the element is an object, you compare addresses, but if its an
> > integer you compare values?
>
> Yes. The same as what already happens when you compare two non-array
> variables. The following code should always be compilable, no matter the
> value of T:
>
> var
> X, Y: T;
> begin
> X := Y;
> Y := X;
> if X = Y then ;
> end;

It is, if T is a Delphi native type, or a descendant of TObject ;)

> OK, "no matter the value" is a little strong. I haven't given much
> thought to whether comparisons should be allowed for Delphi's native
> "file" types. They're not assignable, so I'm less inclined to say they
> should be comparable. (Aside: Does *any* operator work on file types?)

I'm not much into file types in Delphi; but iirc the + operator is
supposed to work on the file variable.

> > My reasoning is as follows:
> >
> > *You cannot compare arrays.
>
> You're begging the question. That's the point you're supposed to be
> arguing, so it's no fair to start your reasoning with that premise.

No, I am stating the obvious. You can _not_ compare "arrays". Arrays
_in general_. Array of string[200]=array of TObject ?

> And I don't want the focus to shift from static arrays to dynamic
> arrays. The compiler already knows how to compare dynamic arrays, so
> within this message, when I talk about "arrays," I'm talking exclusively
> about static arrays.

Fair enough. Array[0..1] of Byte can't be compared to Array[0..1] of
Byte unless its declared a type. Thats my point. You can only compare
them if they are declared as types.

> > *You could then compare your types, but how on earth could you make
> > something logical that can compare two types if they can compare only
> > array types, and not record types?
>
> That's a good point. I thought I'd mentioned records already, but maybe
> I didn't. I want records to be comparable, too. It's hard to argue for
> one without the other.

Yes, and I see, as I explain, a big reason for records not to be
comparable.

> > *What to do with all other types?
>
> You mean like Integer, Double, Variant, and IUnknown? The compiler
> already knows how to compare those.

No, I meant user defined types in general.

> > Deep or shallow comparison?
>
> Shallow. (Read on for details.)

Deep and recursive. You want to see if they are equal, don't you?

> > Deep and
> > recursive comparison (fear the cross references!)? Who is to tell me
> > how my records should be compared?
>
> You can't have cross references in static arrays or records, so there's
> nothing to fear on that front.

No, but if we were to allow general comparison between any type, we
also need to be able to compare objects.

> Why shouldn't your records be compared field-to-field? What other
> meaningful comparison is possible? If all the fields of one record are
> not identical to the corresponding fields of another record, then I
> would not consider the records to be equal in the first place. If you
> want to compare for "almost equal," then it begins to look like what
> happens when comparing two floating-point values -- you need to come up
> with your own routine to decide *how* equal the values need to be.

My records and classes should be compared field by field. But all
pointers should have the objects on which they point compared. Deep
comparison, and recursive. How else would you want ^integer to be
compared? By address?

> > The fun part here is that IIRC two identical types can be compared
> > according to the Pascal ISO.
>
> Are you saying that the ISO calls for the same thing I'm calling for?

Yes, but standard Pascal does not include classes. So "type" has a
whole other meaning.

> >> Untyped pointers are very easy to compare. People do it all the time.
> >>
> >> var
> >> a, b: Pointer;
> >>
> >> if a = b then ...
> >
> > Yes, it is easy to compare the value of the pointers. IE compare them
> > as if they were integers... But this might not be what was wanted.
>
> That's OK with me. The compiler should perform as shallow a comparison
> as possible. It's easy to write your own routine to go deeper when
> necessary. If the default comparison is deep, though, it's harder to
> write your own routine to do a shallow or mid-depth compare. The problem
> is that arrays and records have *no* comparison.

if integer(a)=integer(b)? whats hard about that?

> The compiler already performs an element-wise copy for arrays; why not
> an element-wise compare? If you're going to argue against comparing
> arrays, then I think you also need to argue against assigning arrays.

Does it really copy element wise? Doesn't it just use a memcopy
function for this?

> >> Whatever the reasons for disallowing "=" on static arrays and records,
> >> technical difficulty is not one of them -- not nowadays, anyway. I'm
> >> more inclined to say the reason is lack of customer demand for the feature.
> >
> > I never said it was a technical difficulty in comparing arrays;
>
> Well, you did make claims about what the Pascal compiler is capable of
> doing.

I made claims about what a user could do himself with the Pascal
compiler (if you think about the statements on generic programming).

> > I stated that it was plain easy to write your own compare methods. My
> > point was that I see reason in it NOT being allowed, due to confusion
> > about which types can and can not be compared.
>
> I see more confusion in the status quo. I'm looking for fewer exceptions
> to the rule that you can use the "=" operator to compare two variables.
> Having fewer exceptions leaves less room for confusion.
>
> It is indeed easy to write your own comparison operations. It's also
> tedious -- something a compiler is perfectly suited to doing.

Think about the confusion about comparing open arrays of chars;
null-terminated strings returned from API calls etc etc etc.
'abcdef'#0'a' _is_ equal to 'abcdef'#0'b' when returned from the
API...

Also, think about a variant record.

TTest=record
  case bit16: Boolean of
    True: (w: word);
    False: (b: array[0..1] of byte);
end;

You can easily assign two instances of this record to eachother. But
how would you compare two of those? This would be "comparing apples to
oranges" which simply is not possible.

I'm not saying that its not possible to compare two arrays; not even
dynamic arrays. I'm just stating that it would (imo) be wrong to
implement comparison of some user defined types, but not all. And also
that it might cause some unwanted trouble.

I agree that it is a bit confusing that you can copy arrays but not
compare them. But you can also copy records to eachother; yet
comparing them might prove difficulties.

Relevant Pages

  • Re: Array comparison
    ... And how do you compare two classes? ... does not explain why it can't compare two like-typed arrays. ... Free Pascal supports operator overloading. ... more inclined to say the reason is lack of customer demand for the feature. ...
    (alt.comp.lang.borland-delphi)
  • Re: Option Compare Statement
    ... both arrays are always the same type. ... compare text,. ... Your first post regarding this in the vb.controls newsgroup was, ... strings, let's say A and B. Then I want to compare their values. ...
    (microsoft.public.vb.general.discussion)
  • Re: Similarity searching
    ... a factor of N*log, if the arrays are big you won't in general have to compare to the last element so I don't see the factor of L**2, and I don't see where that C**2 factor is coming from at all. ... There are also sorting algorithms which don't compare each item to every other item, yet still generate a sorted result. ... If electricity comes from electrons, ...
    (comp.lang.fortran)
  • Re: Hashtable Contains() - byte arrays as keys -
    ... > But that would again mean he will have to iterate and compare each entries ... Assuming I understand his problem (that he needs the byte arrays to ... entries of the arrays. ... The hashcode might be cacheable if the byte arrays are not changed once ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Similarity searching
    ... a factor of N*log, if the arrays are big you won't in general have to compare to the last element so I don't see the factor of L**2, and I don't see where that C**2 factor is coming from at all. ... There are also sorting algorithms which don't compare each item to every other item, yet still generate a sorted result. ... Similarity searching is still an active science, but there are a lot of useful algorithms out there now. ...
    (comp.lang.fortran)