The Big Programming Thread - Page 10

On July 13 2010 00:00 Adeny wrote:
However in C# I'm sitting on two arraylists (whatever the hell that is)]

On July 13 2010 00:00 Adeny wrote:
C# question time!
in C++ i would do this: if (a[i] == b[ii]). However in C# I'm sitting on two arraylists (whatever the hell that is), and I want to loop through both of them the way you'd solved one of the bike-locks with codes... 001, 002, 003 etc. which I'd usually do by nesting for loops, i < 9, ii < 9 and so on... I don't know if I'm making any sense. Let's try again, what I'm looking for is a replacement to this, but with arraylists;

for (int i = 0; i < 9; i++)
{
    for (int ii = 0; ii < 9; ii++)
    {
        if (arrayA[i] == arrayB[ii])
            return true;
    }
}

List<int> list1 = new List<int>();
List<int> list2 = new List<int>();

//add whatever you want to lists i.e. list1.add(3)

foreach (int i in list1) {

    foreach (int y in list2) {
        
        if (i == y) {
            return true;
        }
    }

}

On July 13 2010 00:57 Schamus wrote:
So, I figured I would share.

VBA Excel Macro coding...is the devil.

On July 13 2010 00:27 Adeny wrote:
Oh, the code I showed wasn't supposed to be C#, just how I'd do it in C/++. I thought about this;

foreach (int i in arrayA)
{
    foreach (int ii in arrayB)
    {
        if (i == ii)
            return true;
    }
}

But it would seem natural for i and ii to be the indexes rather than the values. Maybe I'm too used to references in C++. arrayA[i] would make more sense, y'know?

About this:

return arrayA.Intersect(arrayB).Count()>0

You're saying I can't Console.WriteLine(function()) if function returns the above code? The result has to be stored in a buffer first, is that what you mean by "doesn't support early out"?

On July 13 2010 00:29 sluggaslamoo wrote:



An ArrayList is a list which uses a backing array (as opposed to a non-array backed list, such as a linked list). There are many types of list which have the same functionality but are handled it in a completely different way. All lists are self expanding, they can be iterated through, and their indexes manually accessed and modified, much like an array.

In OOP you should always try to hide as much information as possible (use encapsulation), in order to reduce side-effects, de-couple and simplify your code. With the case of the ArrayList, when you instantiate an ArrayList, you should use a List variable (as MasterOfChaos said). You can do this by type-casting (down casts such as ArrayList->List are automatic), it part of a principle of OOP called polymorphism.

This means other programmers won't know whether it is a LinkedList or an ArrayList, which means he/she can't make assumptions on its functionality. This is good because it means you can switch from a LinkedList to an ArrayList without any problems if you need to later on.

return arrayA.Intersect(arrayB).Take(1).Count()>0

On July 13 2010 02:11 MasterOfChaos wrote:


Both ArrayList and List are backed by arrays, and neither derives from the other. The main difference is that List<T> is generic and ArrayList isn't. So List<object> is pretty much the same as ArrayList. IMO ArrayList is obsolete since .net 2.0.

You can hide information by using IList, ICollection or IEnumerable. But a typical linked list wouldn't implement IList either, since indexed access is O(n) for linked list.



And I there is an easy way to give my linq statement early out behavior:

return arrayA.Intersect(arrayB).Limit(1).Count()>0

It probably evaluates one of the sides, puts it in a hashtable and then lazily evaluates the other side. So the average case runtime is something like O(arrayA.Count+arrayB.Count) provided the hashes are evenly distributed. Your code on the other hand is O(arrayA.Count*arrayB.Count), which is much slower for large lists.

On July 13 2010 01:54 TanGeng wrote:


An "early out" is a fast termination sequence without having to brute force through the entire for loop (worst case). When you don't have an "early out" you completely go through your loops.

In your code, the worst case is when you have no matches - the code goes through both for loops completely. The best cases is when the first member of A matches the first member of B - it only looks at one comparison before terminating with an answer.

On July 13 2010 02:18 Catch]22 wrote:


Lists in Java and C# arent backed by arrays, they are objects with references to the next object.

On July 13 2010 02:18 Catch]22 wrote:


Lists in Java and C# arent backed by arrays, they are objects with references to the next object.

Resizable-array implementation of the List interface.

The List(Of T) class is the generic equivalent of the ArrayList class. It implements the IList(Of T) generic interface using an array whose size is dynamically increased as required.

On July 13 2010 02:11 MasterOfChaos wrote:


Both ArrayList and List are backed by arrays, and neither derives from the other. The main difference is that List<T> is generic and ArrayList isn't. So List<object> is pretty much the same as ArrayList. IMO ArrayList is obsolete since .net 2.0.

You can hide information by using IList, ICollection or IEnumerable. But a typical linked list wouldn't implement IList either, since indexed access is O(n) for linked list.



And I there is an easy way to give my linq statement early out behavior:

return arrayA.Intersect(arrayB).Limit(1).Count()>0

It probably evaluates one of the sides, puts it in a hashtable and then lazily evaluates the other side. So the average case runtime is something like O(arrayA.Count+arrayB.Count) provided the hashes are evenly distributed. Your code on the other hand is O(arrayA.Count*arrayB.Count), which is much slower for large lists.

On July 13 2010 12:56 catamorphist wrote:
I see your point of view, but I have to disagree. I think that a valuable piece of information communicated by your return type (or your parameter type) is what "kind" of thing you are returning, in a general sense. If I am returning an IList, which implements an indexer, that really implies that the indexer is going to be constant time, because that's the example set by all the other IList implementations. Similarly, if you have an ISet, you expect Contains to be at least better than linear. I don't think there's anything wrong with having conventions like that, and it helps communicate things that you would have to put in a comment otherwise.