[C#] Sets

[Dax]

Hi Leute :)

Mir war langweilig, also hab ich mal eine C#-Implementation der aus Delphi bekannten Mengen/Sets versucht. Natürlich ohne Boxung/Unboxing der Elemente, sondern einfach über Generics :) (Ich war so frech und hab die Sets gleich in den System.Collections.Generic-Namespace getan^^) Deswegen brauchen die Sets auch .net 2 ;)

An Operatoren gibts alles was man aus Delphi kennt: +, -, *, <=, >=, != und ==. Zusätzlich hab ich noch XOR als ^ eingefügt :) Natürlich sind die Sets IEnumerable und IEnumerable<T> sowie ICloneable. IEquatable<Set<T>> nicht zu vergessen :mrgreen:

Also alles in allem viel Wind um nichts, wie bei allen meinen Codes :lol:

Wenn jemand eine Idee hat, wie man das ganze verbessern könnte - immer her damit :)

PS: Ihr könntet langsam mal cs als Endung erlauben :zwinker:

Edit: IEquatable sollte ja auf Set<T> sein, nicht <T> :oops:

[r2c2]

Och menno... stell dir vor: Bin grad am C# lernen und hatte grad vor zur Übung Sets in C# zu implementieren. SharpDevelop is schon gestartet, guck grad nochmal in der DP rund und was seh ich da: Mal wieder jemand schneller... :twisted:

Was solls, hatte sowieso vor zuerst ne .NET 1.1-Version zu basteln und später eine für .NET 2.0. Letzteres hat sich dann ja erübrigt...

Zitat:

Wenn jemand eine Idee hat, wie man das ganze verbessern könnte - immer her damit

Hab mir mal deinen Code angesehen. Richtige "Verbesserungsvorschläge" hab ich nicht, aber trotzdem noch n paar Anmerkungen. Folgendes is mir noch unklar:
- warum hast du Reset() 2 mal implementiert?
- für was n leeres Dispose()?
- < und > könnte man noch überladen
- die Listen-Klasse, die du zur internen Speicherung verwendest, gibts unter .NET 1.1 noch nicht, oder hab ich die irgendwo übersehen?
- wäre es nicht ne Überlegung wert die Sets als Wertetypen(d.h. als struct, statt class) zu implementieren
- wir wärs noch mit [Serializable]

Ansonsten: Klasse Klassen! :thumb:

mfg

Christian

[Dax]

Hi r2d2 :) ;)

Tut mir Leid wenn ich dir damit zuvorgekommen bin ^^

Zitat:

Zitat von r2c2

- warum hast du Reset() 2 mal implementiert?

Einmal für IEnumerable und einmal für IEnumerable<T>. Anders gings nicht ;)

Zitat:

Zitat von r2c2

- für was n leeres Dispose()?

IEnumerator schließt IDisposable ein, deswegen hab ich das Dispose hingetan, aber leergelassen...

Zitat:

Zitat von r2c2

- < und > könnte man noch überladen

Hm, und mit welcher Funktion? :)

Zitat:

Zitat von r2c2

- die Listen-Klasse, die du zur internen Speicherung verwendest, gibts unter .NET 1.1 noch nicht, oder hab ich die irgendwo übersehen?

Nein ;) List<T> wurde erst mit den Generics (also .net 2) eingeführt.

Zitat:

Zitat von r2c2

- wäre es nicht ne Überlegung wert die Sets als Wertetypen(d.h. als struct, statt class) zu implementieren

Das wird nix... structs dürfen keine Parameterlosen Konstruktoren haben, und Feldinitialisatoren auch nicht.

Zitat:

Zitat von r2c2

- wir wärs noch mit [Serializable]

:oops: Vergessen. Ist jetzt drinne :)

Zitat:

Zitat von r2c2

Ansonsten: Klasse Klassen! :thumb:

Danke, sowas hört man immer gern :)

bis dann,
Dax

[phXql]

Öhm, im zip ist nur eine .proj-datei...

[DGL-luke]

Also ich würde vorschlagen, A < B ist "A ist teilmenge von B", A > B ist "A ist Obermenge von B". :)

EDIT: der rote kasten funktioniert! :)

[Dax]

Zitat:

Zitat von phXql

Öhm, im zip ist nur eine .proj-datei...

'tschuldigung, hab das gezippt was besser aussieht :oops:

Zitat:

Zitat von DGL-luke

Also ich würde vorschlagen, A < B ist "A ist teilmenge von B", A > B ist "A ist Obermenge von B". :)

Also gleichheit der beiden Mengen ausgeschlossen? Eingebaut :)

[r2c2]

Hallo :hi:

Zitat:

Zitat von Dax

Tut mir Leid wenn ich dir damit zuvorgekommen bin ^^

Ich habs überlebt... :mrgreen:

Zitat:

Einmal für IEnumerable und einmal für IEnumerable<T>. Anders gings nicht

:gruebel: Hm... interessant. Eigentlich sollte das doch gehen, indem du einfach kein Interface vorher angibtst. Damit sollten sich doch beide Interfaces zufrieden geben. Versteh also momentan noch nicht warums nicht geht. Wenn ich mich erst mal mit Generics befasst hab(hab momentan noch .NET 1.1 am Laufen), wird sich das wahrscheinlich klären...

Zitat:

Das wird nix... structs dürfen keine Parameterlosen Konstruktoren haben, und Feldinitialisatoren auch nicht.

Stört aber doch nicht. Nimm einfach den anderen Parameter und lass auch null zu. Und die Felder kann man auch im Konstruktor initialisieren... Bin gerade dabei Sets für .NET 1.1 zu implementieren(wenn du willst, kann ichs, wenns fertig is, ja mal anhängen) und nehm dafür structs. Hab bisher damit keine Probleme.

Wärend dessen is mir noch n bisschen was aufgefallen:
- sollte als Enumerator nicht

Code:

public IEnumerator GetEnumerator()
{
  return inner.GetEnumerator();
}

reichen? Oder geht das wegen der Generics nicht?

- Wie wärs mit m implicit operator; bei mir(ohne generics) funktioniert das nicht, da ich object als implicit-Parameter nehmen müsste und set ja von object abgeleitet ist; bei deiner Version könnts aber klappen

- Leider kann man "in" nicht überladen. Hab dafür also einfach "%" genommen. Sieht zwar nicht so toll aus, funktioniert aber...

Ah und nochwas is mir aufgefallen:

Code:

public static Set<T> operator +(Set<T> left, Set<T> right)
{
  Set<T> result = new Set<T>();
  result.inner.AddRange(left.inner);
  result.Include(right);
  return result;
}

Warum benutzt du einmal AddRange und einmal Include. Du könntest du für beides Include verwenden...

mfg

Christian

[Dax]

Heya :)

Zitat:

Zitat von r2c2

Ich habs überlebt... :mrgreen:

*gg* Schön zu hören :)

Zitat:

Zitat von r2c2

:gruebel: Hm... interessant. Eigentlich sollte das doch gehen, indem du einfach kein Interface vorher angibtst. Damit sollten sich doch beide Interfaces zufrieden geben. Versteh also momentan noch nicht warums nicht geht. Wenn ich mich erst mal mit Generics befasst hab(hab momentan noch .NET 1.1 am Laufen), wird sich das wahrscheinlich klären...

Ne, geht nicht ;) Beide Interfaces wollen eine Methode mit gleicher Signatur, aber anderem Rückgabewert.

Zitat:

Zitat von r2c2

Stört aber doch nicht. Nimm einfach den anderen Parameter und lass auch null zu. Und die Felder kann man auch im Konstruktor initialisieren... Bin gerade dabei Sets für .NET 1.1 zu implementieren(wenn du willst, kann ichs, wenns fertig is, ja mal anhängen) und nehm dafür structs. Hab bisher damit keine Probleme.

Ja, das ginge natürlich auch. Aber so ists mit irgendwie lieber ^^

Zitat:

Zitat von r2c2

Wärend dessen is mir noch n bisschen was aufgefallen:
- sollte als Enumerator nicht

Code:

public IEnumerator GetEnumerator()
{
  return inner.GetEnumerator();
}

reichen? Oder geht das wegen der Generics nicht?

Hm, jetzt wo du es sagst :gruebel: Seh ich mir mal an..

Zitat:

Zitat von r2c2

- Wie wärs mit m implicit operator; bei mir(ohne generics) funktioniert das nicht, da ich object als implicit-Parameter nehmen müsste und set ja von object abgeleitet ist; bei deiner Version könnts aber klappen

Von woher wölltest du denn konvertieren? Bin grad bisschen verwirrt :?

Zitat:

Zitat von r2c2

- Leider kann man "in" nicht überladen. Hab dafür also einfach "%" genommen. Sieht zwar nicht so toll aus, funktioniert aber...

Dafür hab ich .Contains(T), aber ein eigener Operator dafür wäre natürlich auch toll. Habs aber gelassen, weil ich persönlich .Contains(T) besser lesbar finde als T % Set, weil % ja normalerweise was ganz anderes ist :)

Zitat:

Zitat von r2c2

Ah und nochwas is mir aufgefallen:

Code:

public static Set<T> operator +(Set<T> left, Set<T> right)
{
  Set<T> result = new Set<T>();
  result.inner.AddRange(left.inner);
  result.Include(right);
  return result;
}

Warum benutzt du einmal AddRange und einmal Include. Du könntest du für beides Include verwenden...

He, stimmt ja^^ Is mir garnicht aufgefallen :)

[DGL-luke]

Ich weiss nicht, ob bei zwei gleichen Mengen A und B die Aussage "A ist Teilmenge von B" bzw. "A ist Obermenge von B" stimmen...
Vielleicht steht das ja in der Formelsammlung...

AHA!

Zitat:

Zitat von Barth, Mühlbauer, Nikol, Wörle ("Mathematische Formeln und Definitionen", J.Lindauer Verlag)

Teilmengenrelation A [Teilmenge] B *)

Eine Menge A heisst Teilmenge einer Menge B, wenn jedes Element von A auch Element von B ist.
S o n d e r f a l l: Eine Menge A heisst eigentliche oder echte Teilmenge einer Menge B, wenn A Teilmenge von B ist und wenn A != B.

Die leere Menge ist Teilmenge einer jeden Menge.

--
* Gleichwertig ist auch die Schreibweise A [Teilmenge oder gleich] B

[Unterstreichungen durch den Autor]
[Nicht darstellbare Gleichungszeichen durch [Ausdruck] ersetzt]

Rein mathematisch ist somit klar, (A < B) = (A = B).
Rein praktisch sollte aber aufgrund des Vorhandenseins des Operators "<=" der Ausdruck A < B als "A echte Teilmenge von B" interpretiert werden.

Im übrigen gibt es mathematisch keine "Obermenge" (zumindest meine Formelsammlung kennt das nicht); A > B sollte somit als B < A definiert werden.

[r2c2]

Zitat:

Zitat von Dax

Zitat:

Zitat von r2c2

:gruebel: Hm... interessant. Eigentlich sollte das doch gehen, indem du einfach kein Interface vorher angibtst. Damit sollten sich doch beide Interfaces zufrieden geben. Versteh also momentan noch nicht warums nicht geht. Wenn ich mich erst mal mit Generics befasst hab(hab momentan noch .NET 1.1 am Laufen), wird sich das wahrscheinlich klären...

Ne, geht nicht ;) Beide Interfaces wollen eine Methode mit gleicher Signatur, aber anderem Rückgabewert.

Hm.. also ich seh da 2 mal void...

Zitat:

Zitat:

Zitat von r2c2

- Wie wärs mit m implicit operator; bei mir(ohne generics) funktioniert das nicht, da ich object als implicit-Parameter nehmen müsste und set ja von object abgeleitet ist; bei deiner Version könnts aber klappen

Von woher wölltest du denn konvertieren? Bin grad bisschen verwirrt :?

Ich mein sowas:

Code:

public static implicit operator Set(object obj)
{
  Set result = new Set();
  result.Include(obj);
  return result;
}

Is nix weltbewegendes, spart aber n paar Buchstaben...
Ich hab das nachgebaut, indem ich + und - mehrfach überladen hab...

Zitat:

Zitat:

Zitat von r2c2

- Leider kann man "in" nicht überladen. Hab dafür also einfach "%" genommen. Sieht zwar nicht so toll aus, funktioniert aber...

Dafür hab ich .Contains(T), aber ein eigener Operator dafür wäre natürlich auch toll. Habs aber gelassen, weil ich persönlich .Contains(T) besser lesbar finde als T % Set, weil % ja normalerweise was ganz anderes ist :)

Muss dir Recht geben. Werd das % also wahrscheinlich wieder rausnehmen...

Ah und nochwas. Wie wärs mit sowas:

Code:

public Set(params T[] items)
{
  ...
}

Zitat:

Zitat von DGL-luke

Rein mathematisch ist somit klar, (A < B) = (A = B).

Jein. 1. würd ich da kein Gleichheitszeichen dazwischensetzen und 2. sagt meine Formelsammlung da was logischeres:

Zitat:

Zitat von Tafelwerk

<; <= echte Teilmenge von; Teilmenge von

Bitte die < rund denken...
Im Prinzip stört an deiner Formelsammlung also nur das Wort "Gleichwertig"...

Zitat:

Rein praktisch sollte aber aufgrund des Vorhandenseins des Operators "<=" der Ausdruck A < B als "A echte Teilmenge von B" interpretiert werden.

Jo.

Zitat:

Im übrigen gibt es mathematisch keine "Obermenge" (zumindest meine Formelsammlung kennt das nicht);

In meiner Formelsammlung gibts auch keien Obermenge; kann mich aber erinnern, dass mein Lehrer was davon gesagt hat; also nehm ich mal an, dass es das Wort "Obermenge" giobt...

mfg

Christian

[Elvis]

Zitat:

Zitat von r2c2

Hm.. also ich seh da 2 mal void...

Was du da siehst ist einmal die wirkliche Methode, und dann 2 mal die explizite implementierung der Interfaces. Welche nur pass throughs der eigentlichen Methode sind.
Ich habe Dax gestern meine Interpretation des originalen Codes geschickt. Wie es aussieht scheint einiges in der jetzigen Version übernommen worden zu sein. ;)

Wenn es die Ästhetik zuließ wurde das generische Interface durch eine öffentliche Methode implizit implementiert, dort wirst du nur 2 Methoden mit ähnlicher Signatur finden. Wenn selbst die generische Interface methode zu hässlich wäre, wurde sie ebenfalls explizit implementiert. Ich bin zum Beispiel kein Fan davon GetEnmerator öffentlich sichtbar zu machen, foreach braucht nur IEnumerable(<T>) aber diese hässeliche Methode bläht Intellisense IMHO nur unnötig auf...

Zitat:

Ich mein sowas:

Code:

public static implicit operator Set(object obj)
{
  Set result = new Set();
  result.Include(obj);
  return result;
}

Is nix weltbewegendes, spart aber n paar Buchstaben...

Sowas ist ganz böse... Implizite Operatoren können durchaus sinnvoll sein, aber sie können sehr schnell Code sehr unübersichtlich machen.
Ein implicit mit einem object parameter macht das Set plötzlich zuweisbar von allen Typen, wodurch man fast sämtliche Compilerprüfung verlieren würde. :?

Zitat:

Muss dir Recht geben. Werd das % also wahrscheinlich wieder rausnehmen...

Wäre wieder eine Verwendung eines Operators, die absolut nicht eindeutig erichtlich ist.
Wer außer dir wüte was hier passiert?

Zitat:

set3 = set1 % set2;

Zitat:

Ah und nochwas. Wie wärs mit sowas:

Code:

public Set(params T[] items)

Schaue dir die jetzige Version an, ich denke diese meiner Änderungen wurde ebenfalls übernommen.



Gibt es eigentlich irgendeinen Grund für dich mit 1.1 festzusitzen? Kann ich wirklich nicht nachvollziehen.
Immer dieses ekelhafte object-Gefriemel. :?

[r2c2]

Hallo Elvis :hi:

Zitat:

Zitat:

Ich mein sowas:

Code:

public static implicit operator Set(object obj)
{
  Set result = new Set();
  result.Include(obj);
  return result;
}

Is nix weltbewegendes, spart aber n paar Buchstaben...

Sowas ist ganz böse... Implizite Operatoren können durchaus sinnvoll sein, aber sie können sehr schnell Code sehr unübersichtlich machen.
Ein implicit mit einem object parameter macht das Set plötzlich zuweisbar von allen Typen, wodurch man fast sämtliche Compilerprüfung verlieren würde. :?

:oops: Sorry, das kommt davon, wenn zwischendurch der Browser abstürzt. Das mit object war meine Implementierung für .NET 1.1(was ja so nicht geklappt hat). Als ich zum ersten Mal den Post geschrieben hab(je der war schon fertig; und bevor ich ihn abschicken konnte, war alles wieder weg... :evil: ), hab ichs glaub ich richtig gehabt, also statt "objet" "T"...
Bei meiner .NET 1.1 implementierung hab ich leider sowieso keine Compiler-Prüfung... Muss also alles zur Laufzeit prüfen... :?

Zitat:

Zitat:

Ah und nochwas. Wie wärs mit sowas:

Code:

public Set(params T[] items)

Schaue dir die jetzige Version an, ich denke diese meiner Änderungen wurde ebenfalls übernommen.

Guck mir die neue Version gleich mal an...

Zitat:

Gibt es eigentlich irgendeinen Grund für dich mit 1.1 festzusitzen? Kann ich wirklich nicht nachvollziehen.
Immer dieses ekelhafte object-Gefriemel. :?

Grund 1: Hab noch kein .NET 2.0
Grund2: Hab noch kein VS(mein Cousin verspricht mir jede Woche VS 2005 Express(hab leider nur ISDN...), nur kommt immer was dazwischen...)
Grund3: bin grad am C# lernen und da wollte ich wenigstens was halbwegs Sinnvolles machen, statt Übungsaufgaben, die nachher sowieso nicht mehr angucke...

mfg

Christian

[phXql]

Wofür VS? Nimm einfach SharpDevelop...

[r2c2]

Zitat:

Zitat von phXql

Wofür VS? Nimm einfach SharpDevelop...

Mach ich auch. Momentan. VS hat aber n paar praktische Features, die #Develop noch nicht hat. Ich muss aber sagen, dass sich #Develop sehr gut entwickelt hat. Hatte mal ne 0.8er Version, mein ich. Die war noch ziemlich buggy. Die jetzige Version ist da schon weitaus besser. Wenn die so weitermachen haben die vielleicht irgendwann VS eingeholt! :thumb: Nur is das momentan eben noch nicht der Fall...

mfg

Christian

[phXql]

Was hat den VS Express, was SD nicht hat?

[Elvis]

Zitat:

Zitat von phXql

Was hat den VS Express, was SD nicht hat?

Der Code editor von C# im neuen VS ist fast so gut wie der den man mit dem ReSharper im alten Studio hatte. Nur kostet C#X rein gar nix. ;)
#d ist IMHO die mit Abstand beste IDE, aber nur vom Kern her. Die AddIns und Sprach bindings sind noch lange nicht da wo sie gerade im VS sind.

[Daniel]

Zitat:

Zitat von phXql

Was hat den VS Express, was SD nicht hat?

Gehört nicht in dieses Thema. ;-) Bleibt bitte beim Ausgangsthema.

[phXql]

mkay, sorry..