Informatische Bildung mit Mobiltelefonen — Lehrerfortbildung am 8. August 2009

An der Universität Wuppertal wird am Samstag, 8. August 2009, von 10 bis 16 Uhr eine Lehrerfortbildung stattfinden.

Auf einem Infoblatt sind alle notwendigen Details festgehalten. Um Anmeldung wird gebeten spätestens 1. August 2009 unter der E-Mail-Adresse m.heming@uni-wuppertal.de.  Bei Interesse an der Durchführung des Unterrichts mit Mobiltelefonen an Ihrer Schule, bitte umgehend bei mir melden, es steht ein Klassensatz entsprechender Geräte zum Verleih zur Verfügung.

Beschreibung aus dem Infoblatt:

Die technischen Möglichkeiten im Umgang mit Informatiksystemen ändern sich fortwährend. Um der Allgegenwärtigkeit von Informatiksystemen in der Realität und vor allem in der Lebenswirklichkeit von Schülerinnen und Schülern gerecht zu werden, müssen immer wieder neue gesellschaftliche Anknüpfungspunkte für den Informatikunterricht gefunden werden.

Daher betrachtet diese Fortbildungsmaßnahme den im ersten Moment ungewöhnlichen Ansatz, den Computer im Informatikunterricht gänzlich außer Acht zu lassen und ihn gegen Mobiltelefone auszutauschen. Anhand vorliegender Unterrichtsvorschläge ist das Ziel, den Informatikunterricht einer elften Klasse für das kommende Schuljahr 2009/2010 nur mit Mobiltelefonen zu gestalten.

Für die Umsetzung von Programmieraufgaben sind Mobiltelefone mit Symbian S60 Betriebssystem erforderlich. Über die Fortbildung für Lehrkräfte hinaus wird ein Satz von Mobiltelefonen für die Umsetzung im 11. Jahrgang mit einer Lerngruppe im Regelunterricht zur Verfügung gestellt. Der Einsatz der Geräte im Unterricht wird wissenschaftlich begleitet, um die Erkenntnisse eines Pilotprojektes an der Willy-Brandt-Gesamtschule Bergkamen zu ergänzen. Es sollen so die theoretischen Überlegungen zu den geänderten Möglichkeiten durch die konkrete Nutzung der Mobiltelefone zur Gestaltung des Unterrichts auf eine breitere empirische Basis gestellt werden.

Stifte, Mäuse und Vektorgrafiken Version 2.2

Sooo, habe endlich ein paar Testläufe durchgeführt und die gröbsten Fehler beseitigt.
Nähere Infos zu dem Paket hier. Download der neuen Version hier.
Update: Fehlerhafte Datei hochgeladen, nun korrigiert.

Update: Ich kann mich eines gewissen Stolzes nicht verwehren, dass ich an dieser Stelle SuM mit PyObjVG für PyS60 veröffentlichen kann. Ich freue mich über Rückmeldungen, die es mir ermöglichen, das Paket nicht nur auf dem mir vorliegenden Nokia 5500 zu testen.

Stifte und Mäuse — PyObjVG — Version 2.1

Aus der Versionsgeschichte von PyObjVG.py:
Version 2.1 vom 22. Januar 2009:

  • Zeichenroutinen hinzugefuegt. Das Zeichenobjekt, welches
    als Parameter uebergeben werden muss, muss die jeweiligen
    in der Dokumentation der Funktion angegebenen Methoden
    unterstuetzen.
  • Klasse Farbe: gibSUMFarbe weggelassen, dafuer den Zugriff
    auf die RGB-Werte ueber __getitem__ ergmoeglicht.
    Damit kann eine Farbe ebenfalls als 3-Tupel (wie in Stifte
    und Maeuse) interpretiert werden.
  • BUGFIX: Gruppe sendet bei aktivierten Signalen ebenfalls,
    wenn ein weiteres Objekt zur Gruppe hinzugefuegt wurde.
  • Zusaetzliche import-Anweisung zur Nutzung von
    xml.etree.cElementTree, falls vorhanden.

Passend dazu ist der Grafikzeichner des Stifte und Mäuse Paketes aktualisiert worden.
Version 2.1 vom 22. Januar 2009:

  • Es findet keine Objekterkennung mehr statt, statt dessen
    wird im Grafikzeichner eine abstrahierte Zeichenschnittstelle
    dargeboten, ueber die sich die Objekte sich selbst zeichnen.
    Damit ist die Integration von extern hergestellten
    Klassen vereinfacht. Diese muessen nur eine einzige Methode
    „zeichne(…)“ zur Verfuegung stellen und koennen dann
    auf die vom Grafikzeichner abstrahierte Schnittstelle zugreifen.
  • Automatikmodus wird jetzt ueberall klein geschrieben,
    z.B. in der Methode gibAutomatikmodusStatus.
    Die Methode „setzeAutomatikModus“ heisst jetzt „setzeAutomatikmodusStatus“.

Download: Stifte und Mäuse Bibliothek Version 2.1

Iterative Verfahren mit dünnbesetzten Matrizen

Im Rahmen eines Seminarvortrages habe ich einen Artikel zu iterativen Verfahren auf dünnbesetzten Matrizen ausgearbeitet. Die Einleitung sei hier zitiert:

Im Rahmen des Seminars Schwachbesetzte Systeme soll die vorliegende Arbeit einen groben
Überblick über verschiedene iterative Methoden zur Lösung linearer Gleichungssysteme
bieten. Dabei wird zwischen stationären und nicht stationären Verfahrensweisen unter-
schieden. Als Beispiel für stationäre Verfahren werden das Jacobi- und Gauss-Seidel-
Verfahren vorgestellt, ohne jedoch auf Details zum Konvergenznachweis einzugehen.
Um den Bezug zu Sparse-Matrizen herzustellen, wurde der Algorithmus des Jacobi-
Verfahren in zwei verschiedenen Codevarianten in Matlab implementiert. Je nach Schreib-
weise werden matlabintern verschiedenen Methoden verwendet, die eine starke Optimie-
rung bei der Rechnung mit dünn besetzten Matrizen ermöglichen.
Als Beispiel für ein nicht stationäres Verfahren wird das Verfahren der konjugierten
Gradienten (CG) näher erläutert. Die Verfahren Steepest Decent und Conjugate Directi-
ons werden dabei erklärt, um ein besonders intuitives Verständnis des CG-Verfahrens zu
ermöglichen (Shewchuk (1994)). Anhand des Implementierungsbeispiels soll o????ensichtlich
werden, dass eine Optimierung für Sparse-Matrizen nicht notwendig ist, da diese implizit
durch Anwendung von Matrix-Vektor-Multiplikationen realisiert wird.
Auf verschiedene andere Verfahren, die keine speziellen Vorbedingungen wie das CG-
Verfahren benötigen, wird nur im Rahmen einer zitierten Aufzählung mit minimaler
Beschreibung eingegangen.

Die Vortragsunterlagen inklusive Artikel und LaTeX-Quelltexte können hier heruntergeladen werden. Die m-Files von Matlab, die die angesprochenen Verfahren implementieren, stehen hier zum Download.

Stifte und Mäuse unter Creative Commons Lizenz

Dank der Erlaubnis von Ingo Linkweiler ist es mir nun möglich, dass Stifte-und-Mäuse-Paket für Python unter der Creative Commons Lizenz by-nc-sa zu veröffentlichen. Damit schnüre ich hier nun ein Paket zusammen, welches zum einen die Orginial SuM-Dateien (mit neuem Lizesierungshinweis), als auch die Grafikzeichnererweiterung inklusive PyObjVG-Modul enthält. Während die genannten Bausteine alle unter der Creative Commons Lizenz veröffentlicht sind, wird der SVG-Import durch das ElementTree-Toolkit mit gesonderten Lizenzbedingungen zur Verfügung gestellt.

Download.

PyObjVG Version 2.0

Im Rahmen eines universitären Projektes habe ich ein Python-Modul entworfen, welches Schülerinnen und Schülern ermöglicht, mit Hilfe von Python Vektorgrafiken zu erstellen. Dabei wurde keine grafische Benutzungsschnittstelle erzeugt, wie sie Vektorgrafikprogramme wie Inkscape benutzen, sondern ein Klassenkonzept zum Erzeugen von grafischen Primitiven, welche nur über passende Python-Befehle gesteuert wird.

Schülerinnen und Schüler müssen also beim Erzeugen eines Bildes Kenntnisse von den Attributen und Methoden der verschiedenen Klassen haben, als auch die syntaktischen Regeln der Programmiersprache Python einhalten.

Um der fehlenden Anschaulichkeit dieser Art und Weise der Grafikerzeugung entgegenzuwirken, sind zwei Erweiterungen vorgesehen.

  1. Der Im- und Export von SVG-Dateien
    Dies ist zum einen die einzige Möglichkeit der Speicherung konstruierter Grafiken (neben in Python eingebauten Methoden zu Serialisierung von Objekten), zum anderen ist damit eine Brücke zur Darstellung von Daten mit Hilfe von XML gezeigt. Da gängige Browser einen Großteil der SVG-Spezifikation darstellen können, ist zumindest eine Anschaulichkeit des Konstruktionsergebnis gegeben.
    Während der SVG-Export recht einfach zu Implementieren war, stellt sich der SVG-Import als sehr komplex dar, weil die Möglichkeiten von PyObjVG im Vergleich zu SVG sehr reduziert sind. Der SVG-Import muss daher in weiteren PyObjVG Versionen stark überarbeitet bzw. überprüft werden.
  2. Zeichnen mit Hilfe der Stifte-und-Mäuse-Bibliothek (vgl. Blog-Eintrag)
    Es wurde neben dem PyObjVG-Modul, welches ein in sich geschlossenes System zur Datenrepräsentation darstellt, eine Erweiterung für die Stifte-und-Mäuse-Bibliothek (in der Python-Desktop-Version nach Ingo Linkweiler) implementiert, welches Vektorgrafikobjekte des PyObjVG-Moduls interpretiert und entsprechende Zeichenroutinen aufruft. Diese neue „Grafikzeichner“-Klasse ist angepasst an das Signalweiterleitungskonzept des PyObjVG-Moduls und kann daher zur automatisierten Verfolgung des Aussehen der Vektorgrafik genutzt werden.

Das Projekt ist noch nicht beendet. Neben einer kleinen ToDo-Liste im Speziellen für den SVG-Import wurden noch keine größeren Testläufe durchgeführt. Ein spezieller Punkt für die Zukunft, der hier noch anzumerken ist, ist derjenige, dass ich ebenfalls an einer Schnittstelle für die Stifte-und-Mäuse-Bibliothek auf Mobiltelefonen arbeite. Da zum Jahreswechsel eine erste Version einer Portierung der Pygame-Bibliothek für PyS60 Systeme veröffentlich wurde, werde ich diese vor der Überarbeitung meiner Alpha-Version noch testen, vielleicht bieten sich dort verbesserte Möglichkeiten.

Zur Nutzung von PyObjVG auf Desktopsystemen werden folgende Teile benötigt.
Update:
Nach Änderung der Lizenzbedingungen (vgl. Blog-Eintrag) nun als Paket verfügbar.

  • Das Modul PyObjVG 2.0
  • Das Toolkit ElementTree (nur für SVG-Import benötigt)
  • Sumwrapper, Modifikation der SuM-Bibliothek, notwendig zur Nutzung der Klasse ‚Grafikzeichner‘.
  • Die Klasse Grafikzeichner als Schnittstelle zwischen PyObjVG und SuM

static-Attribute in C++ Klassen

An dieser Stelle soll die Aussage

„Statische Klassenattribute müssen außerhalb der Klassendefinition initialisiert werden.“

ein wenig näher untersucht werden. Betrachtet sei dazu die folgende Klassendefinition:

class KlasseMitStaticElement {
public:
static int anzahl;
KlasseMitStaticElement() {
cout << "Konstruktor aufgerufen" << endl;
KlasseMitStaticElement::anzahl++;
}
};

Geht man nun nach der oben genannten Regel vor, so würde die naive Initialisierung (eigentlich eine Zuweisung, siehe Zusatz unten) so aussehen: KlasseMitStaticElement::anzahl = 0;. Leider resultiert diese Zeile in einen Kompilerfehler, es wird über das undefined symbol „KlasseMitStaticElement::anzahl“ gemeckert. Faszinierenderweise gelingt die Initialisierung aber mit  int KlasseMitStaticElement::anzahl = 0; warum?

Dazu müssen Deklaration, Definition und Initialisierung Begrifflich sauber voneinander getrennt werden. Ich verweise dazu auf ein C++-Forum, in dem von Benjamin Kaufmann folgendes geschrieben ist:

  • Deklaration: Ein Programmausdruck der einen Namen in einen Scope ein- bzw. wiedereinführt.
  • Definition: Eine Deklaration die die Details einer Entität bekannt macht oder, im Fall von Variablen, die dazu führt, dass Speicher für die Entität reserviert wird. Eine Deklaration einer Klasse (struct, class, enum, union) Funktion oder Methode wird zu einer Definition, wenn auf die Deklaration ein in geschweiften Klammern eingeschlossener Block folgt.
    Variablendeklarationen sind immer auch Definitionen es sei denn, der Deklaration ist ein extern vorangestellt.
  • Initialisierung: Eine Definition mit expliziter Anfangswertzuweisung.

Nach obigen Versuchen stellen wir also fest, dass auch die Voranstellung von static im Klassenkontext dazu führt, dass eine ursprüngliche Definition nur eine Deklaration darstellt. In dem Beispielprogramm matstatic.zip habe ich als statisches Attribut keinen einfachen Datentyp genutzt, sondern eine Klasse mit Standardkonstruktor verwendet. So kann man sehen, dass die Definition der Variable nach der Klassendefinition dazu führt, dass der Standardkonstruktor aufgerufen wird.

Bezogen auf das obige Beispiel stellt man also fest, dass die explizite Initialisierung (und damit implizite Definition) der Variable anzahl nicht notwendig ist. Eine Definition wie  int KlassenMitStaticElement::anzahl; wäre ausreichend, da die integer-Variable damit automatisch vom Compiler mit 0 initialisiert wird.

Ob die automatische Initialisierung einen allgemeinen C++-Standard oder nur eine Laune meines Compilers darstellt, ist mir zwar nicht bekannt — eventuell kann ohne Anfangszuweisung der Schwachsinn, der vorher an der Speicherstelle der Variable stand, von uns weiter genutzt werden — aber die anfangs erwähnte Aussage muss korrigiert werden.

„Statische Klassenattribute müssen außerhalb der Klassendefinition DEFINIERT werden.“

Zusatz:

Über Initialisierungen zu sprechen, stellt sich als nicht ganz einfach heraus, da das Verhalten des Compilers nicht nur von der Anweisung selbst, sondern auch von ihrer Position im Quelltext abhängt. Eine implizite Initialisierung mit 0 wird für die Anweisung int a; als globale Definition vorgenommen, während die gleiche Anweisung im Funktionskontext einen undefinierten Wert für a behält.

Man könnte nun auf der einen Seite eine implizite und eine explizite Initialisierung unterscheiden (nach der Definition aus dem Forum wäre nur die explizite Initialisierung überhaupt eine Initialisierung), oder man geht dem Problem aus dem Weg, indem man jede Variablendefinition auch gleichzeitig mit einer expliziten Initialisierung im Quelltext versieht. Da nur Variablen mit eindeutig zugewiesenen Werten semantischen Sinn ergeben, kann man die ganz oben genannte Aussage als Merkregel sehr gut für die Praxis verwenden. Doch sollten wir ein wenig verallgemeinern:

„MERKREGEL: Alle Variablen müssen initialisiert werden. Bei statischen Klassenattributen geschieht dies außerhalb der Klassendefinition.“

Lustige Operatorensuche in C++ (Koenig Lookup?)

Bei der Korrektur von Übungsblättern zu einer C++ Vorlesung bin ich auf das folgende, auf den ersten Blick sehr simple Phänomen gestoßen: Da definiert mir doch jemand eine friend Methode innerhalb der Klasse. Wohlgemerkt nicht nur eine Deklaration, sondern eine ganz Implementation. Ausschnittsweise sieht das nun wie folgt aus:

class Koordinaten
{
...
friend ostream& operator<<( ostream& os, const Koordinaten& out );
{
os << "X-Koordinate: " << out.x << endl ;
os << "Y-Koordinate: " << out.y << endl ;
os << "Z-Koordinate: " << out.z << endl ;
return os ;
}
};

Naja, hübsche Idee, das wird definitiv nicht kompilieren — dachte ich mir. Schief gewickelt. Klappt sogar sehr gut. Aber warum?

Bisher dachte ich, nach friend darf gar keine Definition folgen. Gut, deklariert man eine Methode an mehreren Stelle (z.B. Aufteilung in hpp und cpp Dateien), dann könnte es doch eigentlich egal sein, an welcher Stelle die Implementierung steh. Aber ganz ohne Deklaration außerhalb der Klasse hätte ich nicht vermutet, dass C++ diesen Operator überhaupt findet.

Naja, im Rahmen einiger Recherchen zu den verschiedensten C++-Phänomenen bin ich auf die Homepage von Benjamin Kaufmann gestoßen. Er schildert in seiner C++ FAQ in kurzer und knapper Weise das Prinzip des Koenig Lookup und wenn ich mich nicht völlig verdreht habe, dann könnte gerade dieses die Lösung zur Operatorensuche (bzw. zum Phänomen des Findens) sein. Betrachtet man nämlich den zweiten Punkt

ist T eine Instanz einer Klasse/Struktur X, kommen alle Namensräume hinzu, in denen X definiert wird.

dann interpretiere ich mal die Klasse als Namensraum, welcher automatisch durchsucht wird, da als Parameter des Operators ein Objekt dieser Klasse vorkommt.

Neben der Tatsache, dass ich natürlich eine solche Definition nicht gutheiße, da sie ziemlich verwirrend ist, wollte ich meine Erkenntnisse einfach einmal mitteilen, denn bisher dachte ich, dass soetwas abgefahrenes überhaupt nicht möglich sei.

Zusatz:

Habe von Benjamin Kaufmann eine kleine Erklärung bekommen, die meine Gedanken zu der Problematik bestätigt. Es sei hier nur noch der Hinweis angebracht, dass das Koenig Lookup auch argument dependent lookup genannt wird und dazu sogar eine kleine Seite in der Wikipedia existiert (zumindest auf Englisch) http://en.wikipedia.org/wiki/Argument_dependent_lookup

Stifte und Mäuse mit Python unter MacOSX

Die unter Learn-Line angebotene Implementierung der Stifte und Mäuse Bibliothek ist – ganz im Widerspruch zum einleitenden Satz „Sie finden hier die Klassenbibliothek von Stifte und Mäuse für verschiedene Betriebssysteme und Programmiersprachen.“ – nur auf die Programmiersprache Java zugeschnitten. Ingo Linkweiler hat in seiner Diplomarbeit die alternative Programmiersprache Python für den unterrichtlichen Einsatz näher analysiert und in diesem Zusammenhang ebenfalls eine Implementierung der Stifte und Mäuse Bibliothek in eben dieser Sprache erstellt. Leider liegt die Fertigstellung dieser Quellen schon einige Zeit zurück, der Einsatz mit Python 2.5.2 mit meinem Mac stellte sich als nicht ganz so einfach dar. Hier daher eine kurze Beschreibung, wie ich bis zur problemlosen Benutzung vorgegangen bin:

  1. Installation von Python 2.5.2 über http://www.python.org/download/ (Für die vorinstallierte Version funktioniert die Installation von PyGame nicht)
  2. Installation von PyGame über http://rene.f0o.com/~rene/stuff/macosx/ (dabei Hinweis beachten, dass auch pyobjc installiert werden muss)
  3. Download der Stifte und Mäuse Quellen von Ingo Linkweiler. Durch eine Umstellung von Python fehlt jetzt allerdings zu Beginn jeder Quelldatei die Angabe der verwendeten Kodierung. Mit einem kleinen Bash-Script habe ich die verwendete Latin1-Kodierung angegeben.
  4. Das Ausführen der test.py klappte nun leider noch nicht, es ergab folgenden Fehler (Auszug):
    *** Assertion failure in -[SDL_QuartzWindow setTitle:]

    Die Fehlermeldung zeigt schon ein wenig in die Richtung, die ich durch ein wenig herumprobieren gefunden habe. In der Datei sumwrapper.py wird in Zeile 197 die Überschrift für das Bildschirmfenster festgelegt. Der Umlaut „ä“ ist dabei problematisch. Die Änderung in „ae“ hat diese Fehlermeldung beseitigt.

Das Ergebnis kann in der Datei sum.zip heruntergeladen werden.

Die Programmiersprache R

Im Rahmen eines Seminars habe ich mich heute auf die Suche nach Software zur Stochastik gemacht. Als erstes viel mir die Programmiersprache „R“ ein, eine OpenSource Variante der Sprache „S“, von der ich bisher nur wusste, dass sie existiert, nicht, wie man sie nutzen kann.

Eine kleine Einführung in die Statistik (unter Berücksichtigung der Sprache „R“) von Dr. Andreas Handl könnt ihr hier herunterladen. Auf der einen Seite finde ich es didaktisch nicht unbedingt wertvoll, auf welche Art und Weise man hier an die Sprache herangeführt wird, auf der anderen Seite finde ich die Sprache selbst auch nicht gerade ansprechend, für den Einsatz in Schulen – vor allen Dingen in der Unterstufe – in meinen Augen nicht geeignet.

Aber macht euch selbst ein Bild.