Informatiklehrer
-
Hallo,
spätestens wenn ich in einem Team arbeite und ich nicht in einer perfekten Welt lebe, in der sich jedes Team rund um die Uhr an einem gemeinsamen Ort befindet, benötige ich imo auf jeden Fall eine gewisse Form der Planung.
Erstmal müssen die Teammitglieder in Sachen Ziel übereinstimmen.
Ansonsten löst jeder lustig ein anderes Problem.
Das heißt natürlich nicht, dass meine Use Cases oder Szenarios in Stein gemeißelt sind. Natürlich können die sich im Laufe der Zeit ändern. Eine Änderung kann man imo aber nur feststellen und diskutieren, wenn man sie gegen etwas anderes vergleichen kann. Allein deshalb brauche ich imo eine Menge von Basis Use-Cases. Das macht sich auch im Zuge eine evolutionären Entwicklung ganz gut. Ich kann mir eine Menge von Use Cases raussuchen, und so Schritt für Schritt von Release zu Release wandern. Ohne Festlegung von Funktionalität habe ich keinen möglichkeit meinen Fortschritt zu messen.Will ich dazu Aufgaben verteilen, dann setzt das voraus, dass ich zuvor eine Zerlegung meines Problems erstelle. Die kann ja von mir aus sehr grob und informell sein, sie muss aber dennoch existieren. Will ich allerdings ein Problem zerlegen, so muss ich vorher zumindest wissen, was mein Problem überhaupt ist.
Und es geht ja auch nicht immer nur um Softwareneuentwicklung. Manchmal muss vorhandene Software ja auch gewartet werden (habe ich mir sagen lassen). Oder neue Teammitglieder müssen integriert werden und müssen sich deshalb in vorhandene Software einarbeiten. Oder man möchte ein neues Framework einsetzen. Oder unterschiedliche Teammitglieder haben ein unterschiedliches Verständnis bzw. einen unterschiedlichen Wissensstand.
Hier hat UML (oder eine alternative Methode) clever eingesetzt imo große Kommunikationsvorteile. Natürlich kommt man nicht drum rum sich zu einem gegebenen Zeitpunkt mit dem Quellcode auseinanderzusetzen, aber wenn man vorher auf einer abstrakteren Ebene schon mal die Grobzusammenhänger verstanden hat, fällt das Codelesen deutlich leichter (guter Code sollte natürlich eigentlich alle notwendigen Informationen enthalten. Allerdings ist Code häufig viel zu genau - er muss ja schließlich auch von so einem Hirni wie dem Compiler verarbeitet werden können). Warum soll ich mich z.B. durch tausende Zeilen Code wühlen um die Verarbeitung eines CORBA-RPCs zu verstehen, wenn ich das mit einem Diagramm und ein paar Worten viel schneller erklären kann?Ich denke also alles in Allem sehe ich das wohl so ähnlich wie Marcus.
-
wir haben an unserer schule ein projekt gestartet, bei dem 3 programmierer mitgearbeitet haben. wir haben uns morgens immer getroffen und haben eine kurze team/tages besprechung abgehalten und dann hat jeder für sich drauf los programmiert. das hat am ende dazu geführt, das jeder für seine schnittstelle eine wrapper klasse schreiben musste, damit alles zusammen gepasst hat. das hat uns nochmal einen halben tag gekostet... wir haben daraus gelernt, dass wir am anfang eine einhaitliche schnittstelle definieren, auf die jeder aufbauen kann. wenn etwas an der schnittstelle geändert werden muss, dann wurde das bei der besprechung besprochen
das hat beim zweiten sehr gut geklappt und unser lehrer hat die schnittstellen deffinition bei anderen klassen benutzt.am wichtigsten ist jedoch der ständige austausch zwischen den programmierern. da an sonsten missverständnisse programmiert werden, die schwer zu beseitigen sind.
-
Marc++us schrieb:
@AJ:
Hm, da hast Du was falsch verstanden - sein Weg ist der schwere Weg.
Nein denke ich nicht (das mit dem falsch verstehen). Im Job möchte ich nicht ohne Grobkonzept auskommen müssen. Dass volkards Weg der schwerere ist, weiß ich. Ich mach es ja daheim privat so wie er und hab schon öffter was umprogrammiert, weil mir mittendrin noch eine Verbesserung eingefallen ist, die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte. Allerdings sehe ich es privat nicht so schlimm, da ich ja trotzdem meine Übung hab. In der Geschäftswelt (wie schon gesagt) kann man sich sowas eigentlich nicht leisten. Da ist es notwendig Konzepte zu erstellen.
-
AJ schrieb:
Ich mach es ja daheim privat so wie er und hab schon öffter was umprogrammiert, weil mir mittendrin noch eine Verbesserung eingefallen ist,
das mache ich immer. der "wirklich gute weg" ist vom start aus nicht sichtbar. aber was soll's? man baut ja die ersteb beiden versionen zum wegschmeißen.
die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte.
und hier zweifle ich, daß das immer geht.
Allerdings sehe ich es privat nicht so schlimm, da ich ja trotzdem meine Übung hab. In der Geschäftswelt (wie schon gesagt) kann man sich sowas eigentlich nicht leisten. Da ist es notwendig Konzepte zu erstellen.
in der geschäftswelt wird viel zu wenig weggeschmissen. es ist doch dauernd so, daß man an nem falschen ansatz hängt und viele mannjahre hereingewurstelt hat. und jedes weitere feature wird teuer erkämpft, weil es sich nur widerwillig in diesen codeverhau reinpuzzlen läßt. und ne reimplementierung würde recht flott gehen und danach würde jedes weitere feature in einem zehntel der zeit reinkommen können.
-
volkard schrieb:
die mir allerdings sicher auch schon vorher einfallen hätte können, wenn ich genauer darüber nachgedacht hätte und ein Konzept erstellt hätte.
und hier zweifle ich, daß das immer geht.
Und da bin ich 100%tig deiner Meinung. Aber nur weil ein Plan nie 100% aufgeht, heißt das imo nicht, dass man gleich ganz ohne Plan loslegen sollte.
in der geschäftswelt wird viel zu wenig weggeschmissen. es ist doch dauernd so, daß man an nem falschen ansatz hängt und viele mannjahre hereingewurstelt hat. und jedes weitere feature wird teuer erkämpft, weil es sich nur widerwillig in diesen codeverhau reinpuzzlen läßt. und ne reimplementierung würde recht flott gehen und danach würde jedes weitere feature in einem zehntel der zeit reinkommen können.
Dazu fällt mir spontan folgender Text ein:
http://www.joelonsoftware.com/articles/fog0000000069.html
-
@HumeSikkins
ACK@volkard
Leider geht das nicht immer, dass man den Code einfach so wieder verwirft. Wenn bestimmte Dinge mal implementiert sind und auch ausgeliefert(!), dann kann man das nicht so ohne weiteres ändern. Auf jeden Fall nicht ohne sich den Zorn von Kunden zuzuziehen und das ist immer schlecht.Ich vermute mal, dass du in Individual-Software-Entwicklung tätig bist. Da mag es ja noch ohne größere Probleme möglich sein, aber in der Standard-Software-Entwicklung hat man mit dem Vorgehen riesige Probleme.
-
AJ schrieb:
Leider geht das nicht immer, dass man den Code einfach so wieder verwirft. Wenn bestimmte Dinge mal implementiert sind und auch ausgeliefert(!), dann kann man das nicht so ohne weiteres ändern. Auf jeden Fall nicht ohne sich den Zorn von Kunden zuzuziehen und das ist immer schlecht.
was kümmern mich die randbedingungen? ich sage, daß durch wegschmeißen der code oft besser wird und die weitere entwicklung stark beschleunigt, wenn nicht gar erst ermöglicht.
daß man sich trotzdem überlegen sollte, was man tut, ist klar.und wenn ich sagte, "wasser ist gesund", kommt ihr mit dem argument, daß schonmal einer im wasser ersoffen ist. viel mehr leute ersaufen im wasser als im bier. na, und?
auf jeden fall hat euer "think once, debug ever"-stil nix in der lehre bei programmieranfängern zu suchen. die kids sollen explorativ proggen. fesseln kriegen sie früh genug.
-
HumeSikkins schrieb:
Dazu fällt mir spontan folgender Text ein:
http://www.joelonsoftware.com/articles/fog0000000069.htmlYes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
und er propagiert solchen code? naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
-
volkard schrieb:
daß man sich trotzdem überlegen sollte, was man tut, ist klar.
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
-
volkard schrieb:
und wenn ich sagte, "wasser ist gesund", kommt ihr mit dem argument, daß schonmal einer im wasser ersoffen ist. viel mehr leute ersaufen im wasser als im bier. na, und?
auf jeden fall hat euer "think once, debug ever"-stil nix in der lehre bei programmieranfängern zu suchen. die kids sollen explorativ proggen. fesseln kriegen sie früh genug.Findest du nicht, dass du jetzt etwas zu sehr verallgemeinerst? Ich kann mich gar nicht erinnern, dass ich irgendeinen "think once, debug ever"-Stil propagiert habe oder irgendeinen anderen Stil. Ich habe nicht mal behauptet, dass mein Stil der Richtige und deiner der Falsche ist. Ich habe lediglich gesagt, dass ich deinen Stil nicht verstehe und zusätzlich meine Erfahrungen wiedergegeben (deshalb auch die vielen imos).
Die Wasser-Aussage kapiere ich btw. schon mal garnicht.und er propagiert solchen code?
Nö. Er weißt auf die Existenz hin. Und er sagt, dass die Existenz solchen Codes häufig auch einen Grund hat, der von Inkompetenz der anderen Programmierer verschieden ist.
naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
Klar. Damit verliert sein Wort natürlich gleich an Gewicht. Verstehe. Was muss man für Software verkaufen, damit man sich mit dir auf einer Ebene unterhalten darf?
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
-
HumeSikkins schrieb:
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
sorry. kann sein, daß zu viel ignoranz mich umgab. ich hab mir so viel mühe gegeben, darzulegen, daß frühe festlegungen den code verschlechtern und daß exploratives programmieren den code verbessert. ich lass mich ja auch von euch überzeugen, daß es oft im team randbedingungen gibt, die vorheriges planen (wenigstens ein wenig) nötig machen.
und dann krieg ich so nen hammer:Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
sie sollen doch gar nicht vorher drüber nachdenken.
"think once, debug ever" ist nur das, wo man landen muß, wenn man das vorher-planen und nicht-wegschmeißen ernst nimmt.
die wasser-aussage spielt auf nen bestimmten diskssionsverlauf an, der sich leicht einstellt, wenn einer ne ungewöhnliche these hat.
es ist fast so, als sagte ich "wasser ist gesund" und jemand antwortete "aber im wasser ersoff mal einer". jedes verhamlosen von mir wie "aber da ersaufen doch nur selten leute" wird sicher sofort erwidert mit "aber mein schwager seine frau auch!" oder so. bis irgendwann jeder von seiner tante was beigetragen hat und ich für viele wie ein idiot dastehe.aber nach ajs letztem posting vergeht mir eh die lust an diesem thread. am wochendende werd ich noch den verlauf vom wpc112 posten.
-
AJ schrieb:
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
kannst du dich überhaupt daran erinnern, wie es damals als anfänger war?
-
aber nach ajs letztem posting vergeht mir eh die lust an diesem thread
Die hatte ich für meinen Teil sowieso ignoriert
(keine Böswilligkeit. Erklärung steht weiter unten.)
Ich wollte dir erst noch meinen Standpunkt klar machen um dann besser mit dir diskutieren zu können. Wie du ja weißt, habe ich immer Schwierigkeiten damit mich auf mehrere Dinge gleichzeitig zu konzentrieren.Naja, vielleicht sollten wir das Thema auf das nächste Forumtreffen verschieben. Das Instabilität des Forums zur Zeit macht ein ernstes Gespräch imo sowieso viel zu anstrengend.
-
@volkard
Ja kann ich, da es ja noch nicht all zu lange her ist (ca. 5 1/2 Jahren hats angefangen). Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.@volkard & humesikkins
Was war denn bitte so schlimm an meinem letzten Posting??
-
Hi Volkard,
ich verdiene mein Geld mit der Entwicklung/Design von Software, wohl genau wie du.
Ich habe in diesem Formu schon viele gute Beiträge von dir gelesen und habe mir
gedacht der hat ordenlich was auf dem Kasten.
Wenn ich jedoch so lese was du in diesem Beitrag alles zum Besten gibst, hoffe ich
nur das du dich überwiegend ironisch oder zumindestens überspitzt ausgedrückt hast.
Ansonsten hätte sich meine Meinung über dich erheblich geändert.
Du gibst Sachen von dir, die ich von einem Entwickler der im Team Projekte mittlerer
bis grosser Grösse entwickelt nicht erwartet habe.z.B.
"DER PLAN" muss beim coden entstehen.
Da ich als Teamleiter auch für die Einbeziehung von Freelancern zuständig bin, muss
ich dir sagen das ich jemanden mit dieser Vorstellung von einer professionellen Projektwicklung,
weder als freien und noch viel weniger als ständigen Mitarbeiter gebrauchen kann. Da du
offentsichlich sowohl von C++ als vom Design wirklich Ahnung hast finde ich das wirklich
ziemlich schade.
Für mich bist du damit der Prototyp eines "genialen" Hackers bzw. Einzelkämpfers mit
ausserordenlich viel Sachverstand, jedoch ungeeignet zur planvollen und kontinuierlichen
Entwicklung grosser Software-Projekte. Einsetzbar überall dort wo plötzlich Probleme und
Fehler auftreten, die mit keiner noch so guten Planung verhindert werden können, richtig !!Das mit dem wegschmeissen sehe ich übrigens genauso
mfg JJ
-
AJ schrieb:
Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.
Ich habe den Sinn von Struktogrammen nie gesehen.
Mein Vater steht zwar auch drauf, aber er mag ja auch Pascal am liebsten - insofern kann ich ihn nicht immer ernst nehmen.
-
volkard schrieb:
am wochendende werd ich noch den verlauf vom wpc112 posten.
Es ist Wochenende
-
John Doe schrieb:
...oder zumindestens überspitzt ausgedrückt hast
das kann schon sein. das mache ich doch immer.
evtl muss erwähnt werden, daß "spät planen" und "gar keinen plan haben" durchaus unterschiedliche sachen sind.
[quote="John Doe"]Das mit dem wegschmeissen sehe ich übrigens genauso[quote]
aha. da hab ich doch schon mal nen ansatzpunkt. machmal kippt software um. sie wird unwartbar und unerweiterbar (manche schafft es sogar, während der entwickling umzukippen). das ist immer folge eines schlechten planes. das phänomen kennste sicherlich und es ist eigentlich genau das, was nicht passieren darf.mir passiert das seltener. weil ich normalerweise nen guten plan habe. und warum ist mein plan gut? weil er erst spät aus den wirren versuchen und überlegungen kondensiert. alleine dauert's meist 1/3 der gesamten entwicklngszeit, bis der plan fest steht. nicht fest im sinne von "verankert", sondern im sinne von "stabil", er braucht nicht mehr verbessert zu werden.
im team oder wenn randbedingungen ne suboptimale lösung erfordern, muss man auch festlegen, bevor der plan von selber stabil ist. aber auch da könnte ich mir nur unter schmerzen weniger als ein bis zwei wochen geben, um nen plan reifen zu lassen, der wenigstens so stabil erscheint, daß auch laien ihn ausprogrammieren können.
was ich aber nicht machen würde, gegebenenfalls durch kündigung unterstützt, ist am esten tag nen plan zu fassen. das hat einfach keinen sinn und der frühe plan stirbt sicher.
Für mich bist du damit der Prototyp eines "genialen" Hackers bzw. Einzelkämpfers mit ausserordenlich viel Sachverstand, jedoch ungeeignet zur planvollen und kontinuierlichen Entwicklung grosser Software-Projekte.
es kann sein, daß ich noch 15 jahre warten muss, bis die zeit für meinen stil reif ist.
-
wie es weiter ging nach dem
while(das while( hatte augenblicklich die tendenz, zu einem insetion sort
heranzuwachsen. zuerst die segmente sortieren und dann in einem linearen
rutsch auswerten.
(plan1: sortieren und dann in linearer zeit auswerten)und insertion sort ist bei so kleinen arrays gut. dann sah ich, daß kein
sort im eigentlichen sinne optimal ist, sondern ne abwandlung, wobei
segmente, die sich überschneiden, sofort zusammengefasst werden.
(plan2: ein beliebiges sortierverfahren dahingehend abwandeln, dass
sich schneidende segmente beim sortieren zusammengefasst werden)und sortieren tut nicht not. wenn eh jedes segment mit jedem anderen verglichen
wird, kann ich auch nur zusammenfassen und nix sortieren.
(plan3: plan2 ohne sortieren)hab auf papier diese abwandlung von insertion sort geprobt
(plan4: insertion sort nehmen)
(war nicht elegant).dann von heap sort
(plan5: heap sort)
(war nicht geeignet abwandelbar).(plan6: wieder insertion sort)
insertion sort hatte beim implementieren schluckauf. so viele sonderfälle
und nacharbeiten, daß es unspaßig wurde (>100% gepfuschte nacharbeiten).(plan 7: selection sort)
selection sort (in place, ohne lokale kopie des keys) aber war dann angenehm.
(plan 8: selection sort mit zusammenfassen ohne sortieren. der plan hat (zufällig?)
bis zum ende gehalten.)ich hab viele formale ersetzungen auf code-level gemacht.
so sachen wiea; while(b){ c; d; }wird zu
for(a;b;d) c;(deswegen isses auch nicht schlimm, wenn ich mit while anfange. der code wird eh
umgebastelt und es bleibt nur code stehen, den ich "hübsch" finde.)eine ersetzung sei besonders erwähnt:
int x=0; for(i=0;i<KONST;++i) for(...) if(...) ... goto outercontinue; ++x; ouerconftinue:; return x;war ein wenig unfein.
mit ner standard-transformation führte ich über in:int x=KONST; for(i=0;i<KONST;++i) for(...) if(...) ... --x; goto outercontinue; outercontiune:; return x;(x=KONST;...;--x;...;return x; führt erfahrungsgemäß zu besserem code als das
von der konkurrenz lieber genommene x=0;...;++x;...;return KONST-x;)
und das zerfällt am freien sauerstoff sofort zuint x=KONST; for(i=0;i<KONST;++i) for(...) if(...) ... --x; break; return x;dann begann ich intensiv zu testen und bekam ausnahmefälle, die ich mit bis zu zehn zeilen
code vorher rausfischte (oh, wieder 100%). hab die dann auch eher formal in die hauptschleife
geknäult (drei zeilen). und dann saß ich in nem lokalen maximum. keine offensichtliche
transformation kann den code mehr verbessern. und da der code sich bereits recht gut anfühlt,
strebe ich nicht nach anderem, sonder sollte mal kapieren, was da passiert ist.übrigens hätte ich den afänglichen code (mit goto und so) kaum richtig kapieren können.
nach den transformationen klappt's aber. und kapieren ist recht hilfreich, wenn's um
glaubwürdige fehlerfreiheit geht und kapieren ist notwendig für ale nichttrivialen
optimierungen.und dann erst hab ich mir beim kommentieren bedeutungen überlegt!
und siehe, es war gut.int wpc112(int *start, int *end, int n) { (1)int result=n;//think of n distinct line segments (3)for(int s=n-1;s>=0;--s){//source runs from last entry to first entry (2) if(start[s]==end[s]){//if source is a bad entry (2) --result;//ignore it qickly if it were never there (2) continue; (2) } for(int t=s-1;t>=0;--t){//the targets are all entries above the source if(start[s]<=end[t] && end[s]>=start[t]){//if the source meets a target if(start[s]<start[t])//join them by updating the target to start[t]=start[s];//the smaller start if(end[s]>end[t])//and the greater end end[t]=end[s]; (1) --result;//these line segments were not distinct (1) break;//source vanished by joining with target, we can go to next source } } //nota bene: if no target joined with this source, it's safe to forget this source //there is no way to join it with any combination of targets } (1)return result; }(1)die oben erwähnte transformation führte zu kürzerem code und mehr noch,
die bedeutung ist klarer, als die des langen codes. kurzer code ist oft auch
einfacher code.
(2)die langen vorarbeiten, die bad entrys zu löschen, kann man sich fein sparen,
wenn man sie in der hauptschleife ignoriert. man könnte sich das sogar inhaltlich
überlegt gehabt haben, aber wozu so kompliziert, wenn es auch von selber kommt?
(3)durch den trick (2) musste die schleife statt >0 jetzt >=0 fragen, um beim
ersten element im bad-fall auch --result zu machen. auch nicht überlegt, sondern
debuggt.
(1)es ist GUT, daß --result passiert, wenn gejoined wird. ich zahle fürs zählen
genau dann, wenn der algo durch joinen ne verbesserung für nachfolgende schleifen
erzielt. die kosten werden toll überkompensiert.
und wenn nix zu joinen ist, wird trocken durchgerast. damit sollte mich kein trocken
durchrasender konkurrent schlagen, denn das kann ich auch. und bei den optimierenden
konkurrenten gehe ich davon aus, daß sie umständlichen code bauen und mir ne faire chance
lassen.
mal grenzfälle betrachten. je mit 10 entries.
wenn lauter bad entries da sind, passieren 10 vergleiche (außer der schleifensteuerung)
10 lokale dekrementierungen und fertig. schlicht optimal, würde ich sagen.
wenn lauter disjunkte etries da sind, passieren 10 vergleiche und 45 doppelvergleiche
und schluss.
die sortierende zunft, würde nach dem sortieren nur 10 vergleiche haben, aber beim
sortieren 55 vergleiche und etliche nichtlokale doppelswaps (vierfachzuweisungen)!
die alternative, ein schnelleres verfahren als O(n^2) zu nehmen, fällt bei 10 entries
flach, es wäre noch teurer.
bei lauter gleichen good entries, passieren 10 vergleiche, 9 doppelvergleiche und noch
18 vergleiche und 9 lokale dekrementierungen. da hat der sorterende noch gar nicht
angefangen. hätte einer gegen lauter gleiche nen sonderfallchecker davor, brächte der
vermutlich zu große fixkosten.
mir scheint, ich brauche mich vor sonderfallsammlern nicht sehr zu füchten und vor
sortieren auch nicht sehr. und das sind die beiden einzigen nichtverwandten gegner,
würde ich sagen.
und die verwandten? also gegner, die auch die entries gegeneinander vergleichen und joinen?
merge-sort als rumpf zum könnte stärker sein, aber vermutlich wird die verwaltung viel
zu teuer, entweder viele datenstrukturen oder rekursion. unter den O(n^2)-sorts
kann ich keine luft mehr sehen, wie man nen vergleich oder ne zuweisung sparen könnte.
ob es jemand schafft, lokalere zuweisungen zu bekommen, riskiere ich. (später
umentschieden.)ich halte es für unmöglich, auch nur ansatzweise im vorhinein abchecken zu können, wie
sich solch ein algo genau entwickeln wird. und jeder versuch, den algo vorher auf papier
zu bannen, ist grober unfug.
die papierarbeit war auch kein bannen, sondern nur sowas wie münzenschieben. sofort nach
der schiebung ist die aufgezeichnete information wertlos. sie hat NICHT den charakter
von struktogrammen oder uml-diagrammen oder automatentabellen, die danach in code
übersetzt werden sollen.dann kam raus, daß bad entries gar nicht weg müssen. naja, weg mit den 3 zeilen dafür.
dann wurde im forum ne lösung gepostet, die fast gleich zu meiner war. die schleifen laufen
andersrum. und er läuft mit zeigern und macht lokale kopien, um schneller zu sein.
an zeiger glaub ich nicht mehr. ich konnte nicht durch messungen bestätigen, daß die schneller
als indexzugriffe sind. und in diesem fall hat man mit start, end und i weniger variablen zu
brauchen als mit start, end, ps, pe. das zahlt sich gerne aus durch mehr register-variablen.hab wohl mit plan 8 gut getroffen. jetzt noch ein paar mikro-optimerungen.
alles wieder transformationen, die kaum der rede wert sind.int wpc112(int *start, int *end, int n) { int result=n;//think of n distinct line segments for(int& s=n;--s;){//(s is an other name für n) while there are line segments left int t=0;//target starts at 0 do{//and runs till just before n if(end[s]>=start[t]){//if the source ... int start_s=start[s];//(start_s is an other (faster) name for start[s]) if(start_s<=end[t]){//...meets a target --result;//the source will vanish if(start[t]>start_s)//join source and target by updating the target to start[t]=start_s;//the smaller start if(end[t]<end[s])//and the greater end end[t]=end[s]; break;//source vanished by joining with target, we can go to next source } } }while(++t<s); }; return result; }mal sehen, was die konkurrenz sich ausdent und ob ich was wesentliches übersehen hab.
die sachen auf papier waren tests, keine pläne.
[url="http://volkard.de/plan2.tif"]
[url="http://volkard.de/plan1.tif"]---
am freitag ging ich in die stadtbücherei. und da lächelte mich ein buch an und
sagte "lies mich". es heißt "Logik der Programmierung".
drinnen lernt man allerhand.
unter anderem, daß man programme mit struktogrammen planen muss, bevor man sie
eintippt.
auf seite 5-05 findet sich ne aufgabe "es ist eine liste der mitarbeiter
der unernehmung xyz auszudrucken. auf jeder seite dieser liste steht eine
überschriftenzeile, es schließt sich eine leerzeile an, und dann erfolgt
zeile für zeile eine auflistung der mitarbeiter. [...]Pro Seite dürfen nicht
mehr als 30 Zeilen gedruckt werden.[...]"
der autor ist auch nett und gibt eine musterlösung an.
[url="http://volkard.de/plan3.tif"]
ich übersetze mal in pseudocode:dateien ein_dat und aus_dat öffnen zeile1_flag=true zeilen_zaehler=0 zeile von ein_dat lesen solange nicht eof(ein_dat) wenn zeile1_flag==true ueberschrift ausgeben (inc zeilen_zaehler+=2, zeile1_flag=false) mitarbeiterzeile ausgeben (inc zeile1_zaehler+=1) wenn zeilen_zaehler>29 zeile1_flag=true zeilen_zaehler=0 zeile von ein_dat lesen dateien ein_dat und aus_dat schließenfällt euch daran was auf?
.
.
.
.
--spoiler
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
es sollte folgendes auffalen: die variable zeile1_flag ist komplett
nutzlos. das programm sollte zerfallen indateien ein_dat und aus_dat öffnen zeilen_zaehler=0 zeile von ein_dat lesen solange nicht eof(ein_dat) wenn zeilen_zaehler==0 ueberschrift ausgeben (inc zeilen_zaehler+=2) mitarbeiterzeile ausgeben (inc zeile1_zaehler+=1) wenn zeilen_zaehler>29 zeilen_zaehler=0 zeile von ein_dat lesen dateien ein_dat und aus_dat schließendas weghauen einer unfugs-variablen ist eigentlich ne planabweichung.
-
Deine Bilder tun nciht.