WPC... geht weiter! -> wpc12

d-f-g

Mathematische Betrachtungen, Nummer 2:
Bitmuster der Länge 3n

... sind immer auf 0 reduzierbar.

Beweis durch vollst. Induktion:

Für n=1 ist die Behauptung wahr.

Nun schliesse ich von n auf n+1:

Das Teilmuster von Bit 1 bis 3n lässt sich nach Induktionsvoraussetzung auf lauter Nullen bringen. Wir erhalten 0{3n}(0|1){3}
Für (0|1){3} = 000 | 111 | 011 | 100 sind wir schnell durch betätigen der letzten 2 Schalter fertig.

Die Fälle (0|1){3} = 001 | 010 | 101 | 110 reduzieren wir durch die letzten 2 Schalter auf 001 und erhalten: 0{3n+2}1

(000)(000)(000)..., (110)(000)(000)..., (001)(000)(000)..., (000)(110)(000)...

So kommt man irgendwann bei (000)(000)(000)...(111) an. Fertig.

Jetzt sind wohl alle sehr beeindruckt.

Ich habe mal noch ein weiteres Geschwindigkeitstestprogramm gebastelt (gestützt auf Michaels Version und d-f-gs Ausführung, dass Ketten der Länge 3n immer lösbar sind), das vielleicht auch noch das ein oder andere interessante Ergebnis liefern könnte. Ob es sich für den eigenen Compiler und Plattform eignet, hängt hauptsächlich davon ab, wie präzise clock() arbeitet

#include <vector>
#include <iostream>
#include <ctime>
#include <cstdio>
#include <cstdlib>

typedef std::vector<char> Chain;
typedef std::vector<size_t> Moves;

Moves wpc12(Chain& state1, Chain& state2);

Chain createRndChain(size_t size)
{
  Chain res;
  res.reserve(size);
  for (size_t i = 0; i < size; ++i)
    res.push_back(rndBool());
  return res;
}

void testAlgorithm(size_t size, size_t loops)
{
  typedef unsigned long long big_uint;
  std::cout << "Kettengroesse: " << size << "; Anzahl Durchlaeufe: " << loops << std::endl;
  big_uint whole = 0;
  size_t min = static_cast<size_t>(-1);
  for (size_t i = 0; i < loops; ++i)
  {
    Chain testStart = createRndChain(size);
    Chain testEnd(testStart.size());
    std::clock_t start = std::clock();
    Moves moves = wpc12(testStart, testEnd);
    std::clock_t end = std::clock();
    whole += (end-start);
    if (end-start < min)
      min = end-start;
    if (i % (loops / 50) == 0)
      std::cout << '#' << std::flush;
  }
  std::cout << " fertig\n";
  size_t avg = whole / loops;
  std::cout << "Durchschnitt: " << avg / (CLOCKS_PER_SEC/1000) << " ms (" << avg << " ticks)\n";
  std::cout << "Minimum: " << min / (CLOCKS_PER_SEC/1000) << " ms (" << min << " ticks)\n";
  std::cout << std::endl;
}

int main( int argc, char * argv[] )
{
  size_t startSize = 1;
  size_t numTests = 7;
  size_t numLoops = 1000;
  for (size_t i = 0; i < numTests; ++i, startSize*=10)
  {
    testAlgorithm(startSize+2, numLoops);
  }
  return 0;
}

Einfach die eigene wpc12 Funktion dazulinken, müsste funktionieren, hoffe ich. Auf Windows-Plattformen den typedef von big_uint auf __int64 anpassen!

Hier noch meine Ergebnisse:

Kettengroesse: 3; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (0 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 12; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (0 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 102; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (20 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 1002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (90 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 10002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (970 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 100002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 10 ms (10940 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 1000002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 109 ms (109570 ticks)
Minimum: 100 ms (100000 ticks)

Ob die jetzt gut sind, sei dahingestellt - Testplattform war ein Athlon64 3200+ auf einem 64bit-Linux, insofern...

Zum Vergleich mal das Resultat, wenn ich statt vector<bool> vector<char> verwende:

Kettengroesse: 3; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (0 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 12; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (0 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 102; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (0 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 1002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (20 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 10002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 0 ms (160 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 100002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 2 ms (2450 ticks)
Minimum: 0 ms (0 ticks)

Kettengroesse: 1000002; Anzahl Durchlaeufe: 1000
################################################## fertig
Durchschnitt: 27 ms (27710 ticks)
Minimum: 10 ms (10000 ticks)

Schon ein gewisser Unterschied...

TomasRiker

Ich bin mittlerweile bei 47 ms für eine Million Glühbirnen angelangt (AthlonXP 3000+). Komischerweise hat es aber keinen Einfluss auf die Geschwindigkeit, wenn ich vector<bool> in vector<char> umändere.
Ob das am Compiler (Visual C++.NET 2002) liegt?

Dann hat die deinem Compiler beiliegende Implementierung der STL möglicherweise die Spezialisierung von vector für bool nicht, was hieße, dass sich dein vector<bool> wie vector<char> bei mir verhalten würde. Könnte man wahrscheinlich testen, wenn man gezielt die Schwächen der Spezialisierung von vector<bool> missbrauchen würde...

Habe mein Testprogramm übrigens gerade mal auf meinem Router (PII/266Mhz) ausprobiert, und das Ding ist ungefähr 10x langsamer als mein Athlon. Finde ich jetzt irgendwie ein bisschen wenig, ich hätte mit einem größeren Faktor gerechnet, aber nun gut

Jester

kwaart schrieb:

Das ist das, was ich meine. vector<bool> ist weder ein Container, noch ist er ein vector. Er ist ein fehlgeschlagenes Experiment...
In dieser Aufgabe funktioniert er trotzdem, aber er ist auf Größe, nicht auf Geschwindigkeit optimiert. Der Geschwindigkeitsunterschied zwischen vector<bool> und vector<char> bei dieser Aufgabe hängt aber von der STL-Implementierung ab, deswegen habe ich interessehalber mal gefragt

Ich denke ich werde meine Dev-Cpp Entwicklungsumgebung nutzen, da ist ein gcc dabei.

Ich habe mich für vector<bool> entschieden, da die Aufgabe ja doch irgendwann gewissen Speichermengen benötigt. Wenn ich das recht sehe kann der Container auf 2^32-Elemente anwachsen. Das wäre bei chars dann 4GB. Die kann ich leider nicht performant zur Verfügung stellen. Ich möchte ja auch Eure Algos benchmarken und nicht meine Platte beim swappen. 4GB/8 also 512MB ist zwar auch noch knapp (wir brauchen ja 2 Eingaben) aber das geht gerade noch so.

Achja, mein System auf dem ich laufen lasse ist entweder ein Celeron 433@475Mhz mit 640MB Speicher oder ein P3 650Mhz mit 256MB RAM.

Wem das zu lahm ist, der kann mir gerne nen schnelleren Rechner schenken.

Hm, an 4 Mrd. Lichtern dürften so ziemlich alle Algorithmen hier ziemlich lange zu knabbern haben. Allerdings legt meiner weitere Vektoren der gleichen Länge an, also wird er wahrscheinlich bei Speicherknappheit selbst mit vector<bool> in dieser Riege bei dir nicht konkurrieren können

TomasRiker

* hat sich erledigt *

d-f-g

Mathematische Betrachtungen, Nummer 3:
Bitmuster der Länge 3n+1

... sind immer auf 0 reduzierbar.

Wie schon bewiesen, kann man die ersten 3n Bit auf 0 reduzieren.
Man kommt hier an:
0{3n}(0|1)
Ist (0|1) = 0 sind wir fertig. Bei (0|1) = 1 geht man wieder so vor:

(000)(000)(000)..., (110)(000)(000)..., (001)(000)(000)..., (000)(110)(000)...

und kommt irgendwann hier an: ...(000)...(000)(110)1, was man durch 2 Schalter leicht lösen kann. Fertig.

d-f-g

Mathematische Betrachtungen, Nummer 4:
Bitmuster der Länge 3n+2

... sind NICHT immer auf 0 reduzierbar.

Wie schon bewiesen, kann man die ersten 3n+1 Bit auf 0 reduzieren.
Man kommt hier an:
0{3n+1}(0|1)
Ist (0|1) = 0 sind wir fertig. Bei (0|1) = 1 sind wie in dieser Position:

...(000)...(000)(000)01

Diese Kombination lässt sich nicht auf 0 reduzieren. Warum? Weil es eigentlich nur einen Ansatz (bzw. 2 Ansätze) gibt, das zu lösen. Und der führt nicht zum Ziel.

Ein wichtiges Ergebnis

Die Bitmuster, die man nicht auf 0 reduzieren kann, lassen sich alle auf diese Form bringen:

0{3n}01 - also 3n+1 Nullen und eine 1 am Ende.

Entsprechend kann man aus dieser Form durch Umlegen von Schaltern alle Bitmuster erhalten, die sich nicht auf 0 reduzieren lassen.

volkard

d-f-g schrieb:

Mathematische Betrachtungen, Nummer 4:
Bitmuster der Länge 3n+2
... sind NICHT immer auf 0 reduzierbar.

sie sind genau dann reduzierbar, wenn die anzahl der bits an positionen (bei 1 beginnend), die nicht durch 3 teilbar sind, gerade ist, oder?

d-f-g

Wenn das stimmt, dann natürlich nur für die Bitketten der Länge 3n+2. Das überprüfe ich morgen. Bin jetzt zu müde.

Jester

volkard schrieb:

sie sind genau dann reduzierbar, wenn die anzahl der bits an positionen (bei 1 beginnend), die nicht durch 3 teilbar sind, gerade ist, oder?

Ah, jetzt kommen die neuen Sachen... das hatte ich mir nicht mehr überlegt.

Btw.: Kann schon jemand was über die Anzahl der möglichen Lösungen aussagen? (mit Beweis )

volkard

d-f-g schrieb:

Wenn das stimmt, dann natürlich nur für die Bitketten der Länge 3n+2. Das überprüfe ich morgen. Bin jetzt zu müde.

es sagt aber auch voraus, welcher der beiden linearen läufe bei 3n+1 zum ziel führen wird. danach suchten wird doch?

mir schwant fast, daß man die beiden pseudobits jenseits des randes miteinrechnen darf und ein muster geht genau nach obiger regel auf.

allerdings ist bei 3*n sowas zu sehen
(p==pseudobit, *==beliebiges bit, -==irrelevantes bit)
-|* * -|p

bei 3*n+1 sowas
-|* * - *|p

bei 3*n+2 sowas
-|* * - * *|-

also bei 3*n und 3n+1 kann man stets die parität selber bestimmen, weil das linke pseudobit bei der zählung irrelevant ist aber das rechte relevant ist. aber bei 3*n+2 ist man in den popo ekniffen, weil beide pseudobis irrelevant sind. dann geht's halt auf oder nicht.

und ich sehe leider keinen ansatz, im vorhinein zu sehen, welche der beiden folgen bei 3*n+2 die kürzere ist.

noch ne frage: die schalter, die zu den relevanten bitpositionen gehören, sind ja so verteilt, daß genau entweder zur einen oder zur anderen lösung gehören. gibt es aussagen über die schalter an den irrelevanten bitpositionen (vor allem: schalten sie dort schlicht abwechselnd?). das würde nämlich erlauben, wenn man die schalteranzahl einer lösung hat, die schalteranzahl der gegenlösung zu bestimmen.

volkard

Jester schrieb:

Btw.: Kann schon jemand was über die Anzahl der möglichen Lösungen aussagen? (mit Beweis )

keine beweise. aber die these von

TomasRiker schrieb:

Wenn die Zeichenkettenlänge 3*n+2 ist, dann gibt es entweder zwei Lösungen oder keine. Der Umkehrschluss (Wenn die Zeichenlänge nicht 3*n+2 ist, dann gibt es immer genau eine Lösung) scheint auch zu stimmen.

unterstütze ich.

Sgt. Nukem

-h

volkard

auch mal was begründen:
auf das muster --**-... (bit, bit, irrelevantes bit, bit, bit, irrelevantes bit, ...)
kam ich, als ich mal untersuchte, was eigentlich genau der unerschied zwischen
0|* * * * ... (pseudobit links ist 0 und dann irgendwas)
und
1| * * * *... (pseudobit links ist 1 und dann irgendwas)
ist.

also um das linke pseudobit durch die ganze reihe zu jagen, muß man die schalter an folgenden positionen drücken:
|1 1 0 1 1 0 ...

damit erklärt sich, daß wenn es bei 3*n+2 zwei lösungen gibt, sich genau an diesen schalterpositionen unterscheiden, denn sie unterscheiden sich ja nur am linken pseudobit.

jetzt könnte man eigenrlich noch schauen, wo das pseudobit am ende landet, also wie das muster am rechnetn ende aussieht. ich vermute, bei 3*n+2 kommt immer am ende ...0 0 0 1 1|0 also ...0 0 0 0 0|1 heraus. also lösbarkeitsirrelevant und paritätsirrelevant.
und bei 3*n+1 wohl immer ...0 0 1 0|0 und bei 3*n immer ...0 0 0 1|0.
klingt fast so, als könnte man sich ne vollstände induktion anziehen und parität und lösbarkeit bewiesen gleichsetzen.

<nachtrag>
mal nochmal 3n+1 angucken.
aus
1|0 0 0...0 0 0|0
wird
-|* * -...* - *|* //relevanz
0|0 0 0...0 1 0|0
und wird
0|0 0 0...0 0 1|1
dabei für die parität egal, wieviele schalter zwischenzeitlich gedrückt wurde. jeder schalter kann nur genau zwei paritärtrelevante lampen umschalten, also ist jeder schalter paritätsirrelevant.
es zeigt sich, daß bei 3n+1 ein durchschieben des pseudobits einen paritätswechsel im kern erzeugt. oder mit einrechnung des nicht irrelevanten rechten pseudobuts zeigt sich eh, daß die parität immer unverändert bleibt.
</nachtrag>

falls das funktioniert, steht "eine lichterkette ist genau dann lösbar, wenn an den positionen 3*n+2 (zählbeginn bei 0) (inclusive der beiden pseudobits) eine gerade anzahl von lichtern brennen" wohl als hauptsatz der lichterketten da. mir scheint, von ihm aus sind faszinierend viele beweise trivial.

beweis für hauptsatz geht wohl so:
jeder schalter ist paritätsirrelevant.

von da aus zu beweisen, daß man für 3*n und 3*n+1 immer eine lösung findet, ist trivial. und zu beweisen, daß es für 3*n+2 nicht immer klappt, isses auch.

Jester schrieb:

Ich hab mich zumindest redlich bemüht eine Aufgabe zu finden, die in ein paar (wenigen) Stunden lösbar ist.

rofl.
*nochmal so durch den Thread querles*

Ponto

Ich hätte nicht gedacht, dass es algorithmisch schneller geht, aber Volkards Ausführungen machen das Ding hier noch 30-40% schneller. Nun ist auch meine Version mit kleinem konstanten Overhead auch schneller als die, welche mehr Speicher spendiert.

volkard

wirklich spannend ist, was die leute, die hier tricks veröffentlichen, in der hinterhand haben. man macht sich ja keine medallie kaputt, indem man einen trick verrät, den man nicht schon als nicht so wichtig abgetan hat.

WPC... geht weiter! -&gt; wpc12

WPC... geht weiter! -> wpc12