Informatik zum Donnerstag
bearbeitet von Rolf BHallo Camping_RIDER,
ok, ich fühlte mich herausgefordert 😀
Mich hat allerdings an der Aufgabe genervt, dass der Typ "Nat" Operatoren als externe Funktionen implementieren soll, was mit sich bringt, dass man ständig Typabfragen machen muss. Das ist nicht objektorientiert. Ich habe die Implementierung daher in Methoden statt Funktionen geändert, delegiere fleißig und kann so Polymorphie statt Typabfragen nutzen.
Allerdings zerstöre ich so wohl jeden Gedanken an eine Tail-Rekursion. Ob die mit einer function-Implementierung eher möglich ist?
Die Funktion from (oder to?), die den numerischen Wert eines Nat ausgibt, hielt ich - weil ja DEBUG - auch nicht für so toll und ich habe den Objekten daher ein Property debugValue gegeben. Und eine Minus-Operation habe ich auch eingebaut - aber die poste ich nicht.
Aufgabe für euch: Baut "Minus", aber bitte ohne Typtests, nur mit Polymorphie.
Dass ich hier eine mögliche rekursive Lösung für Aufgabe 1 poste, sollte wohl ok sein - der induktive Teil ist ja das Kernproblem.
~~~ts
class Zero {
readonly debugValue: number = 0;
plus(m: Nat) : Nat { return m; }
mult(m: Nat) : Nat { return new Zero(); }
fac() : Nat { return new Succ(new Zero()); }
}
class Succ {
readonly pred: Nat;
readonly debugValue: number;
constructor(pred: Nat) {
this.pred = pred;
this.debugValue = pred.debugValue + 1;
}
plus(m: Nat) : Nat { return this.pred.plus(new Succ(m)); }
mult (m: Nat) : Nat { return m.plus(this.pred.mult(m)); }
fac() : Nat { return this.mult(this.pred.fac()); }
}
~~~
Diese Lösung bricht bei `to(9).fac()` ebenfalls ab. Es ist egal, ob man `this.mult(this.pred.fac())` oder `this.pred.fac().mult(this)` rechnet - die auf Addition zurückgeführte Multiplikation bringt beim Berechnen von 40320*9 oder 9*40320 einen Stackoverflow.
Die induktive Lösung muss ich noch anschauen. Ich muss vermutlich erstmal kapieren, was "induktiv" im Gegensatz zu "iterativ" überhaupt bedeuten soll...
_Rolf_
--
sumpsi - posui - obstruxi
Informatik zum Donnerstag
bearbeitet von Rolf BHallo Camping_RIDER,
ok, ich fühlte mich herausgefordert 😀
Mich hat allerdings an der Aufgabe genervt, dass der Typ "Nat" Operatoren als externe Funktionen implementieren soll, was mit sich bringt, dass man ständig Typabfragen machen muss. Das ist nicht objektorientiert. Ich habe die Implementierung daher in Methoden statt Funktionen geändert, delegiere fleißig und kann so Polymorphie statt Typabfragen nutzen.
Die Funktion from (oder to?), die den numerischen Wert eines Nat ausgibt, hielt ich - weil ja DEBUG - auch nicht für so toll und ich habe den Objekten daher ein Property debugValue gegeben. Und eine Minus-Operation habe ich auch eingebaut - aber die poste ich nicht.
Aufgabe für euch: Baut "Minus", aber bitte ohne Typtests, nur mit Polymorphie.
Dass ich hier eine mögliche rekursive Lösung für Aufgabe 1 poste, sollte wohl ok sein - der induktive Teil ist ja das Kernproblem.
~~~ts
class Zero {
readonly debugValue: number = 0;
plus(m: Nat) : Nat { return m; }
mult(m: Nat) : Nat { return new Zero(); }
fac() : Nat { return new Succ(new Zero()); }
}
class Succ {
readonly pred: Nat;
readonly debugValue: number;
constructor(pred: Nat) {
this.pred = pred;
this.debugValue = pred.debugValue + 1;
}
plus(m: Nat) : Nat { return this.pred.plus(new Succ(m)); }
mult (m: Nat) : Nat { return m.plus(this.pred.mult(m)); }
fac() : Nat { return this.mult(this.pred.fac()); }
}
~~~
Diese Lösung bricht bei `to(9).fac()` ebenfalls ab. Es ist egal, ob man `this.mult(this.pred.fac())` oder `this.pred.fac().mult(this)` rechnet - die auf Addition zurückgeführte Multiplikation bringt beim Berechnen von 40320*9 oder 9*40320 einen Stackoverflow.
Die induktive Lösung muss ich noch anschauen. Ich muss vermutlich erstmal kapieren, was "induktiv" im Gegensatz zu "iterativ" überhaupt bedeuten soll...
_Rolf_
--
sumpsi - posui - obstruxi
Informatik zum Donnerstag
bearbeitet von Rolf BHallo Camping_RIDER,
ok, ich fühlte mich herausgefordert 😀
Mich hat allerdings an der Aufgabe genervt, dass der Typ "Nat" Operatoren als externe Funktionen implementieren soll, was mit sich bringt, dass man ständig Typabfragen machen muss. Das ist nicht objektorientiert. Ich habe die Implementierung daher geändert und verwende Polymorphie statt Typabfragen.
Die Funktion from (oder to?), die den numerischen Wert eines Nat ausgibt, hielt ich - weil ja DEBUG - auch nicht für so toll und ich habe den Objekten daher ein Property debugValue gegeben. Und eine Minus-Operation habe ich auch eingebaut - aber die poste ich nicht.
Aufgabe für euch: Baut "Minus", aber bitte ohne Typtests, nur mit Polymorphie.
Dass ich hier eine mögliche rekursive Lösung für Aufgabe 1 poste, sollte wohl ok sein - der induktive Teil ist ja das Kernproblem.
~~~ts
class Zero {
readonly debugValue: number = 0;
plus(m: Nat) : Nat { return m; }
mult(m: Nat) : Nat { return new Zero(); }
fac() : Nat { return new Succ(new Zero()); }
}
class Succ {
readonly pred: Nat;
readonly debugValue: number;
constructor(pred: Nat) {
this.pred = pred;
this.debugValue = pred.debugValue + 1;
}
plus(m: Nat) : Nat { return this.pred.plus(new Succ(m)); }
mult (m: Nat) : Nat { return m.plus(this.pred.mult(m)); }
fac() : Nat { return this.mult(this.pred.fac()); }
}
~~~
Diese Lösung bricht bei `to(9).fac()` ebenfalls ab. Es ist egal, ob man `this.mult(this.pred.fac())` oder `this.pred.fac().mult(this)` rechnet - die auf Addition zurückgeführte Multiplikation bringt beim Berechnen von 40320*9 oder 9*40320 einen Stackoverflow.
Die induktive Lösung muss ich noch anschauen. Ich muss vermutlich erstmal kapieren, was "induktiv" im Gegensatz zu "iterativ" überhaupt bedeuten soll...
_Rolf_
--
sumpsi - posui - obstruxi