Lösungsversuch Miniklausur


Gut erkannt. Zeigt, zumindest meiner Meinung nach, aber trotzdem, dass man nicht genau nachgedacht hat, was der Code macht und deswegen einen Methodenaufruf zu viel macht. Daher: [m]>=[/m].


Stimmt nicht ganz, du übersiehst hier einen Randfall.

Davon abgesehen eine kurze Anmerkung zu schönem Code: Übermäßig lange Blöcke sind nicht schön und unübersichtlicher.
So wäre das ganze besser lesbar (aber wie gesagt, nicht ganz korrekt):

if (toAdd == null) {
       return;
}
while (cur != head) {
        if (cur.element <= toAdd.element) {
		drag = cur;
		cur = cur.next;
	} else {
		drag.next = toAdd;
		toAdd.next = cur;
		return;
	}
}

Danke für den Hinweis!

if (toAdd == null) {
       return;
}
while (cur != head) {
    if (cur.element <= toAdd.element) {
        drag = cur;
        cur = cur.next;
    } else {
        drag.next = toAdd;
        toAdd.next = cur;
        return;
    }
}
// wenn to Add.element größer als jedes bisherige element in der Liste (cur == head), d.h. wird am Ende der Liste angefügt
drag.next = toAdd;
toAdd.next = head;

Fast 12 Jahr später arbeite ich momentan die Altminiklausuren durch :slight_smile:

@Volschlaf / Necronomecon: Was war der von Volschlaf angesprochene Randfall?

Hier ist mein Lösungsversuch, welcher (bis auf den Nullcheck von toAdd) identisch zu der Version von Necronomecon sein müsste:

[code=java]while (toAdd.element >= cur.element) {
cur = cur.next;
drag = drag.next;

if (cur == head) {
break;
}
}

drag.next = toAdd;
toAdd.next = cur;[/code]

Beide Codes fügen neue Elemente jeweils nach gleichen Elementen ein, sofern es diese gibt. Das war nicht in der Aufgabenstellung spezifiziert, also hätte man es auch anders machen können, oder?

Zu der ADT-Aufgabe:

[quote=Aktueller Lösungsversuch]create: T → AA
get: int x AA → T
set: int x T x AA → AA
delete: int x AA → AA
size: AA → int[/quote]

Bei create sollte kein T stehen. Auf den WS 15/16 Vorlesungsfolien 10-33 ist es auch nicht so!

Da scheint das erste x ein Tippfehler zu sein. Davon abgesehen denke ich, dass „1 + size(aa)“ auf der rechten Seite reicht, denn Null-Werte können erst gar nicht im AssociativeArray vorkommen laut Angabe („[…] mit einem Wert != null aktualisieren“).


[quote=Marcel[Inf]]
Fast 12 Jahr später arbeite ich momentan die Altminiklausuren durch :slight_smile:

@Volschlaf / Necronomecon: Was war der von Volschlaf angesprochene Randfall?
[/quote]

[quote=Marcel[Inf]]

Da scheint das erste x ein Tippfehler zu sein. Davon abgesehen denke ich, dass „1 + size(aa)“ auf der rechten Seite reicht, denn Null-Werte können erst gar nicht im AssociativeArray vorkommen laut Angabe („[…] mit einem Wert != null aktualisieren“).
[/quote]


[quote=Volschaf][quote=Marcel[Inf]]

Da scheint das erste x ein Tippfehler zu sein. Davon abgesehen denke ich, dass „1 + size(aa)“ auf der rechten Seite reicht, denn Null-Werte können erst gar nicht im AssociativeArray vorkommen laut Angabe („[…] mit einem Wert != null aktualisieren“).
[/quote]

[quote=Aufgabenstellung]
Lesende Zugriffe auf unbelegte/gelöschte Indizes liefern null.
[/quote][/quote]

Gelöschte Indizes dürften hier nicht auftauchen, da man bei den Axiomen doch nur von der kanonischen Darstellung mit Primärkonstruktoren ausgeht. D. h. alle per set gesetzten Elemente müssten existieren und von null verschieden sein. Oder liege ich in dieser Annahme falsch?

Gehen wir von Folgendes aus

size(set(x, e, aa)) = size (aa) wenn get(x, aa) = null sonst …

So schreibt set einen nicht-null Wert an Position x, sodass get(x, aa) immer != null sein müsste. Daraus folgt auch, dass e ein belegter Wert sein muss.