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

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

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

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

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...

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!

mfg

Christian

Hi r2d2

Tut mir Leid wenn ich dir damit zuvorgekommen bin ^^

Zitat von r2c2:

- warum hast du Reset() 2 mal implementiert?

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

Zitat von r2c2:

- für was n leeres Dispose()?

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

Zitat von r2c2:

- < und > könnte man noch überladen

Hm, und mit welcher Funktion?

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 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 von r2c2:

- wir wärs noch mit [Serializable]

Vergessen. Ist jetzt drinne

Zitat von r2c2:

Ansonsten: Klasse Klassen!

Danke, sowas hört man immer gern

bis dann,
Dax

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

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!

Zitat von phXql:

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

'tschuldigung, hab das gezippt was besser aussieht

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

Hallo

Zitat von Dax:

Tut mir Leid wenn ich dir damit zuvorgekommen bin ^^

Ich habs überlebt...

Zitat:

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

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

markieren

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:

markieren

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

Heya

Zitat von r2c2:

Ich habs überlebt...

*gg* Schön zu hören

Zitat von r2c2:

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 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 von r2c2:

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

markieren

Code:

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

reichen? Oder geht das wegen der Generics nicht?

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

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 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 von r2c2:

Ah und nochwas is mir aufgefallen:

markieren

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

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 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.

Zitat von Dax:

Zitat von r2c2:

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 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:

markieren

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 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:

markieren

Code:

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

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 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