Im Jahre 1999 war GeoPress Thema des großen BAFH-SUMMER-QUIZ.
In guter, alter Tradition gibt's auch dieses Jahr wieder ein gehirnwindungsverdrehendes BAfH-Quiz!
Die letzten beiden findet ihr zusammen mit dem epoche-machenden BAfH-Limerick-Contest auf den Bastard Pages. Nach dem letzten Quiz ('Stochastik' gegen 'gesunden Menschenverstand') sind übrigens 7 (in Worten: sieben) Statistik-Professoren freiwillig in den vorzeitigen Ruhestand gegangen. Mit ein bisschen Glück sollten wir diesen Rekord noch übertreffen ... Diesmal hat sich nämlich ein echter BPfH ('Bastard Professor from Hell') bereit erklärt, die Bastard-Quizfrage zu stellen!
Ok, jetzt geht's aber los! Bitte anschnallen und die Aspirinpillen bereit halten!
Ihr geht jetzt alle SOFORT in euren Browser und schaut euch folgende Page an:
https://m-server.fk5.hs-bremen.de/geopress/geopress.html
Dort beschreibt unser geschätzter BPfH sein neues Datenkompressionsverfahren Geopress, welches alle unsere Speicherprobleme für alle Zeiten vom Tisch fegen wird: Mit rekursiver Anwendung seiner 'konkavexen Autorotation geometrischer Subdatenäquivalente' ist es nämlich problemlos möglich, praktisch unendliche Datenmengen, z.B. Doom-Szenarien, auf wenige KB zu reduzieren! Die Beweisführung ist absolut überzeugend und selbst mit Ausdrucken und Ausschnipseln konnte ich keinen Fehler in seiner Argumentation entdecken. Trotzdem weigert sich das Europäische Patentamt ohne Angabe von Gründen bis dato, ein Patent zu erteilen ...
WARUM? WO LIEGT DER FEHLER?
Die schnellste richtige Antwort, die in meiner Mailbox klingelt, gewinnt ein BAfH-Buch (wahlweise B.A.f.H. oder B.A.g.O.)! Was eine richtige Antwort ist, entscheiden ausschließlich wir selber (d.h. der BPfH und ich).
Aus Fairnessgründen sind alle Leser ausgeschlossen, die die Lösung bereits woanders gehört haben, mir oder dem BPfH über die Schulter geguckt haben oder deren Großmutter den Namen Ludmilla trägt. Ferner nicht teilnehmen können leider alle Angestellten des österreichischen Bundes-Statistik-Amtes sowie die Mitglieder des 'Vereins zur Erhaltung der reinrassigen mathematischen Traditionen' in Vorderbuxtehude.
Ok, ok, ok ... ihr könnt jetzt wieder aufhören, mir quengelige mails wegen des BAfH Summer Quiz zu schicken: Ich WEISS, dass ich eine Antwort versprochen hatte; ich bin zwar schon ein älteres Semester, aber schließlich noch kein Pflegefall (noch nicht!). Zwei Leser sind sogar nach München gefahren, haben mir auf der Treppe zur Cafeteria aufgelauert und mich zwei Stunden lang mit Fragen gelöchert; drei andere überschütten mich mit GIFs und anderem Schweinskrams, alles voll mit grell bunten Dreiecken ...
Gut. Also, da ihr alle so geil auf die richtige Lösung des BAfH Summer Quiz seid, habe ich mich entschlossen, einfach eine Auswahl der besten eingesandten Lösungen an euch weiter zu geben. Schließlich gibt's zu jeder Frage beliebig viele Antworten (man schaue sich nur die Lösungsvorschläge der Politiker zur Arbeitslosigkeit vor und nach den Wahlen an!), und ihr könnt euch dann die heraussuchen, die euch am besten gefällt und damit eure Freundin beeindrucken. (Oder euren Freund. Obwohl ich ehrlich gesagt glaube, dass sich Jungs eher mit ganz anderen Sachen wild machen lassen! Das war ein Tip, Mädels. Schreibt ihn euch auf!)
Ich gestatte mir nur noch anzumerken, dass immerhin fünf (!) Leser der Meinung waren, das Betriebssystem Windoofs sei an allem schuld. Bezeichnend, nicht wahr?
Also, hier kommen sie:
DIE BESTEN LÖSUNGEN DES BAFH SUMMER QUIZ
(Kommentare in [Klammern])
ich habs, ich habs, ich habs!!!
dea fehla ist nämlich dea, dass
das gar keine "millibytes" gibt,
weil die viel zu klein wären um durch bits dargestellt zu werden...
... jedenfalls glaub ich, dass der fehler das "millibyte" ist!
### geschwafel...! ###
(ein millibyte müsstä ja nach dem heutigen stand der technik
somit (8bit/1000 ?) also ca. einem speichervolumen von 8m(illi)bit
entsprechen...
und da 8mbit ja schon ewig viel is (man denke an eine schöne 2mbit
standleitung)
könnte eine entdeckung wie diese das raum-zeit gefüge und vieles andere so
durcheinander bringen, dass der neu entdeckte ausdruck somit ad absurdum
geführt werden würde...
(hää?)
### geschwafel ende..! ###
ich finds cool, was du imma so von dia gibts!
[ich auch]
Sehr heftig ;-)
Gesamtfläche = 5*13/2 = 32,5
Einzelflächen = 5 (gelb) + 7 (grün) + 8 (rot) + 12 (blau) = 32
Summe der Einzelflächen bei beiden gleich.
Summe der Gesamtfläche bei Abb. 2 = 32,5 (s.o.) - 1 (weiß) = 31,5
Im Schnitt stimmts dann wieder: 31,5 + 32,5 /2 = 32 = Summe Einzelflächen
(obwohl ichs immer noch nicht ganz verstehe)
[tja ...]
Der Fehler liegt an einer klitzekleinen Ungenauigkeit, die in der Grafik
nicht auffällt und die geschickt ausgenutzt wird.
Wenn man sich die obere Begrenzungslinie der Gesamtfläche als Gerade
vorstellt, die durch (0;5) und (13;0) geht, so wird diese beschrieben durch
die Funktion f(x)= - (5/13)*x + 5
Der Punkt an der Stelle 5 ist also nicht, wie es die Grafik vermuten lässt,
(5;3), sondern (5;(3 1/13)).
Wir nehmen an, dass die rote Teilfläche im Bereich 0 bis 3 die
Höhe 2, im Bereich 3 bis 5 die Höhe 1 hat und die Eckpunkte der grünen
Fläche (0;(3 1/13)), (5;(3 1/13)), (5;1), (3;1), (3;2) und (0;2) sind. Somit
ergeben sich für die
Flächeninhalte der Teilflächen folgende Werte:
Rot: 2*3 + 1*2 = 6 + 2 = 8
Grün: 3* (1 1/13) + 2* (2 1/13) = (7 5/13)
Gelb: 5* (1 12/13) * (1/2) = (4 21/26)
Blau: 8* (3 1/13) * (1/2) = (12 4/13)
Addiert man diese Flächen, so ergibt sich für die Gesamtfläche (32 1/2).
Diesen Wert erhält man auch, wenn man die Kantenlängen des großen Dreiecks
für die Berechnung benutzt: 5 * 13 * (1/2) = (32 1/2).
Ordent man die Teilflächen nun wie beschrieben anders an, so kommt es zu
Überdeckungen, die in der Grafik nicht zu erkennen sind.
Das gelbe Dreieck passt in der neuen Anordnung genau, da es 5 Einheiten
breit und (1 12/13) hoch ist ( f(8)= (1 12/13) ). Das blaue Dreieck ist ja
(3 1/13) Einheiten hoch, reicht also bis (1 12/13) hinunter. Die rote Fläche
ist aber genau 2 Einheiten hoch, es gibt also im Bereich von 0 bis 3 eine
Überdeckung um U1=3*(1/13)=(3/13). Die grüne Fläche reicht bis (2 1/13),
überdeckt also im Bereich von 3-8 die blaue um U2=5*(2/13)=(10/13).
Die Summe der Überdeckungen U1 und U2 ergibt U=(3/13)+(10/13)=1, welches
genau der Größe der weißen Fläche entspricht.
[stöhn]
Blödsinn! Die Beweisführung ist völlig korrekt, das Verfahren funktioniert einwandfrei!!! Getestet habe ich es mit einem 1280x1024-Picture "Neger im zugeschütteten schwarzen Tunnel um 00:42 Uhr nach Ende des Universums" bei 16.7 Mio Farben. Nach Komprimierung betrug die Dateilänge exakt 1 Byte, wofür dann das FAT-Dateisystem 32KB (2 GB Partition) Speicherplatz benötigte. Dies ist unter der genannten Testumgebung das physikalische Minimum. Eine probeweise Übertragung dieser Datei über die serielle Schnittstelle ergab - bereinigt vom Protokollüberhang - eine im Rahmen der Messgenauigkeit - nicht mehr feststellbare Übertragungsdauer. Das Konvertieren in den Originalzustand (zugegebenermaßen sehr mühsam...) ergab exakt die gleiche Bildinformation. Zur Sicherheit werde ich eine Sounddatei erzeugen (1 Stunde Digital Null) und mittels geeigneter Tools den Vorgang wiederholen. Dieser Versuch läuft nächste Nacht automatisch ab, ich bin jedoch sicher dass die Ergebnisse vergleichbar sind. Im übrigen lässt sich durch Induktion beweisen, daß dieses Verfahren bei jeder Art von Daten funktioniert. Gebt's zu - ES WAR EINE FANGFRAGE!!! [aber sicher (prust)]
Tatsache, der Fehler in der Datenkomprimierung liegt meiner Meinung nach darin, das ein roter datenblock verschwindet. das ist nicht so gut, finde ich. Vorallem weil dann der gesparte Platz 1 zu eins mit den verlorenen Daten steht. Naja vielleicht ist das auch quatsch und der hase liegt ganz anders. evtl muss man seinen THC faktor um ein paar gramm erhöhen um das zu raffen. [genau, Genosse!]
dann wollen wir mal... Betrachten wir die Abbildungen 1 und 2 die rote Fläche besteht aus einem 3 x 2 Rechteck, sowie einem 2 x 1 Rechteck. Macht eine Fläche von 8. die grüne Fläche besteht aus einem 2x2 Rechteck und einem 1x3 Rechteck. Macht eine Fläche von 7. Das gelbe Dreieck hat eine Länge von 5 und eine Höhe von 2 macht nach g*h/2 eine Fläche von 5 Das blaue Dreieck hat eine Länge von 8 und eine Höhe von 3. Macht eine Fläche von 12. Wenn wir die Flächen zusammenzählen ergibt das 32. Das gesammte Dreieck hat eine Länge von 13 und eine Höhe von 5, macht eine Fläche von 32,5. Das heißt, in der ersten Abbildung haben wir 1/2 Fläche zu wenig und in der zweiten 1/2 Fläche zuviel. Ich glaub, du hast einen Bug in der Geometrie entdeckt. ;-) Die Lösung lautet also: Die Mathematik ist nicht in allen Fällen genau, da sie eine Annäherung an die Wirklichkeit ist und nicht die Wirklichkeit selber. Das ist ein Fall, wo die Näherung nicht hinhaut. Ich hoff ich liege nicht total verkehrt? [doch]
... P.S. Ich könnte hier natürlich noch einen langen mathematischen Beweis anführen, möchte Sie aber nicht mit Details langweilen, die Ihnen bei Ihrem IQ sowieso trivial erscheinen müssen. [(tröpfel)]
... aber die einzelnen Stückchers bleiben nichtsdestodennochtrotz gleich groß und nix is gespart... Könnte ja sagen, dass es mir furchtbar leid tut, für den BPfH, aber ihr wisst ja, dass das eine Lüge wäre. Sind wir nicht alle ein bisschen Bastard? [na hoffentlich!]
... mir scheint unsere komprimierten daten sind danach genauso groß wie zuvor...mit dem unterschied, dass ein weißes loch dazwischen liegt. so etwas dürfte auf einem windoofs rechner aber gar nicht auffallen, da dort sowieso jede menge fake-hoaxes rumliegen. [(lach)]
... Ich überlege mir übrigens grade schon wen ich alles mit diesem Rätsel quälen kann. Hehehe... [Der Kandidat hat 1000 Punkte! Weiter so!]
Es ist immer wieder überraschend, welch ein eklatanter Mangel an Bildung und Fähigkeiten heute bei den Professoren vorausgesetzt wird. So würde mich sehr interessieren, an welchen Instituten die Doktoren Body und Known studiert haben. Dort wäre es bestimmt sogar für mich ein leichtes, meinen Doktor oder Magister zu machen. ... Ich hoffe, ich konnte den Fehler ausreichend erklähren. Bei solchen wissenschaftlichen Methoden kann ich verstehen, dass sich Dr. McCoy nicht in seine Atome auflösen und durch das All beamen lassen möchte. [Aber mit Windoofs fahren, wie?]
Tja, das war wirklich 'ne harte Nuss, aber ich denke, dass ich eine
mögliche richtige Antwort gefunden habe:
[ZITAT ON]
Einem internationalen Forscherteam, bestehend aus den amerikanischen
Kompressionsexperten Dr. N. O. Body MSc (Stanford University), Prof. U. N.
Known (Massachusetts Institute of Technology) und zwei Wissenschaftlern der
Hochschule Bremen ist es erstmalig gelungen, beliebig große Datenmengen auf
wenige MilliByte zu komprimieren.
[ZITAT OFF]
Nun ist es schon arg verdächtig, dass die beiden amerikanischen Profs solch
eigenartige Namen tragen (Nobody? Unknown?). Angesichts der Tatsache, dass
solche Namen recht selten sind, kann man davon ausgehen, dass die
Wahrscheinlichkeit einer Zusammenarbeit zweier Personen mit solch
merkwürdigen Namen gegen Null tendiert. Da ich kein Mathematiker bin,
musste ich die Wahrscheinlichkeit mit Hilfe einer geworfenen Münze und
eines Schreibblocks nebst Bleistift errechnen. So haben wir das in der
Schule gelernt, also kann es nicht ganz so falsch sein.
Das Ergebnis meiner Bemühungen, neben einer verkrampften Hand vom
Münzenwerfen (immerhin musste ich jeden einzelnen Vor- und Zunamen eines
jeden menschlichen Mitglieds der Gesamtbevölkerung der Erde
berücksichtigen), ist folgendes:
NICHTS
Jawohl, meine Berechnungen führten zu rein gar nichts. Und da nichts = 0
ergibt, ist die Wahrscheinlichkeit einer Zusammenarbeit zweier Personen mit
solch seltsamen Namen gleich Null.
Nun mag man vielleicht denken, dass die durchgeführten Berechnungen
vielleicht falsch sein mögen, aber ich halte dagegen, dass mein
Lösungsansatz ebenso richtig ist wie der Autorotationsalgorithmus falsch
ist.
Formel dafür:
Lösungsansatz richtig = TRUE = 1
Autorotationsalgorithmus falsch = FALSE = 0
Die Aussage "Mein Lösungsansatz ist richtig UND der
Autorotationsalgorithmus ist falsch" führt zu folgender Formel:
1 + 0 = 1
Das Ergebnis ist eins, also ist die Aussage RICHTIG.
Gegenprobe:
Angenommen, mein Lösungsansatz ist falsch und der Autorotationsalgorithmus
wäre kein Blödsinn.
Lösungsansatz falsch = FALSE = 0
Autorotationsalgorithmus echt = TRUE = 1
Formel aus der Aussage "Mein Lösungsansatz ist falsch UND der
Autorotationsalgorithmus ist kein Blödsinn": 0 + 1 = 1
Auch hier ist das Ergebnis wieder eins, auch diese Aussage ist RICHTIG.
Da es im Sommer Quiz darum geht, den Autorotationsalgorithmus als falsch zu
entlarven, kann man beruhigt davon ausgehen, dass der
Autorotationsalgorithmus auch wirklich falsch ist. Die Gegenprobe diente
somit nur zur Bekräftigung meiner ersten Aussage und kann ebenso wieder
vergessen werden. Wir können also davon ausgehen, dass der
Autorotationsalgorithmus falsch ist. Was wäre nun, wenn Lösungsansatz und
Algorithmus beide falsch wären? Das führt uns zu meiner nächsten Formel:
Autorotationsalgorithmus ist definitiv falsch = FALSE = 0
Lösungsansatz ist auch falsch = FALSE = 0
Die Aussage "Der Autorotationsalgorithmus ist völliger Blödsinn UND mein
Lösungsansatz ist ebensolcher Quatsch" führt zu folgender Formel:
0 + 0 = 0
Die obige Aussage ist also FALSCH.
Autorotationsalgorithmus und mein
Lösungsansatz können nicht gleichzeitig falsch sein! Da hundertprozentig
davon ausgegangen werden muss, dass der Autorotationsalgorithmus definitiv
falsch ist (wofür sonst das ganze Quiz?), muss also mein Lösungsansatz
richtig sein.
Lange Rede, kurzer Sinn: Die genannten Professoren können niemals gemeinsam
diesen Algorithmus entwickelt haben. Daraus können wir schließen, dass es
diesen Algorithmus gar nicht gibt. Was es nicht gibt, lässt sich auch nicht
beim Europäischen Patentamt anmelden (sind die überhaupt zuständig?).
Sollte tatsächlich ein Patent für einen nicht vorhandenen Algorithmus
beantragt worden sein, so war dies ein großer Fehler. Und nach einem Fehler
wurde ja schließlich gefragt. ;-)
...und außerdem:
[ZITAT ON]
Dieses nach seinen beiden Entdeckern benannte Fake-Hoax-Verfahren bildet das
Kernstück der geometrischen Kompression.
[ZITAT OFF]
Wer sind denn Fake und Hoax? Müsste es nicht Body-Known-Verfahren oder
Known-Body-Verfahren heißen? Sehr verdächtig! Da hätte ich mir die
Münzenwerferei auch sparen können.
[{TRUE = FALSE && FALSE = TRUE} == TRUE ?]
Sehr geehrter BAfH, das als "bidirektionale schnelle THC-Transformation" beschriebene Verfahren benutzt einen "konkavexen Autorotationsalgorithmus" um die Daten in Ihr "geometrisches Subdatenäquivalent" umzuwandeln. Dieses verfahren ist nicht nach ISO 9001 zertifiziert. Nach den neuen Richtlinien des Europäischen Patentamtes dürfen nur zertifizierte Autorotationsalgorithen für solche Verfahren gewählt werden. Zum zertifizieren müssen die Formulare 37A-555-6 bis 22-y3-2000-w ausgefüllt werden. Dieser Vorgang dauert aber in der Regel zwischen 10 und 20 Jahren ( hängt von der Motivation der Patentamtangestellten ab ). Ein schnellerer Weg wäre es direkt 200.000 Euro auf das Konto des Leiters des Patentamtressorts "Datenalgorithmik und Einweg-Pet-Flaschen" zu überweisen. Der Hauptgrund der Ablehnung war jedoch, dass nur rote und keine blauen selbstähnliche Dreiecke für Datenkompression verwendet werden dürfen. [siehe Pauschal-Kommentar 34-g5-2300-# 'EU-Richtlinien zur Beantwortung von Bullshit']
aus dem Bauch heras fallen mir die außergewöhnlichen Namen auf ("Dr. N.O.Body", "Prof. U.N.Known", "Fake-Hoax-Verfahren"). Der eigentliche Haken an der Sache dürfte aber der sein, dass nach einigen "Geopress-Durchläufen" nicht mal mehr was übrigbleibt, um den exakten Ursprungszustand wiederherstellen zu können. Byteweise gesehen - wie soll man aus einer Kette von z.B. 10 Nullbytes ein 3 MB großes MP3-File zurück-errechnen? Aber der eigentliche Fehler dürfte im Begriff "MilliByte" liegen. Schließlich besteht ein Byte aus *acht Bit* und nicht aus tausend MilliBytes. [1 Byte = 1000 mByte = 8000 mBit; alles klar?]
Hallo Florian, ich habe einige Tage überlegen müssen (Zeitkompression), bis ich auf die Lösung kam. Die kann nur heißen: alle Entdeckungen, die am 01.04. gemacht werden, können nicht zum Patent angemeldet werden. Ich wünsche Dir weiterhinschöne Einfälle in unser aller Interesse. Wann erscheint eigentlich der erste Krimi ??? [in drei Wochen]
Der BPjH hat zu wenig Geld/Macht. KEINE Einzelperson hat die Chance, sein Patent weder in Deutschland noch in der Eurpäischen Union anzumelden, das schaffen leider bisher nur Großkonzerne MONEY RULEZ [RAIT!]
der FEHLER IST DAS WINDOWS-BETRIEBSSYSTEM [(lachlach)]
das Problem bei dem Geopressverfahren sind wandernde Datenmengen. Die Daten haben in den sogenannten "Weißen Löchern" keinen geeigneten Untergrund, um dauerhaft abgespeichert zu werden. Wahrscheinlich wurden die Datenträger bisher mit äußerster Sorgfalt behandelt und keiner groben Gewalt ausgesetzt. Selbst leichte Erschütterungen lösen nämlich schon eine zaghafte Wanderbewegung unter der Datenmenge aus. Eine erste Abhilfe gegen dieses Problem wäre zum Beispiel direkt neben dem weißen Loch ein Fotos eines Biergartens in hellem Sonnenschein mit einem frisch gezapften Bier abzuspeichern. Dadurch könnten die Daten von dem ersten aufkommenden Wandertrieb abgelenkt werden. Sollte jedoch der Datenträger aus Unachtsamkeit vom Tisch fallen, so werden die Datenmengen in diesem "Weißen Loch" durcheinandergewirbelt und lassen sich später nicht mehr abrufen. Wahrscheinlich weigert sich das Europäische Patentamt aus diesem Grund ein Patent zu erteilen. [ich höre immer nur: Biergarten ...]
2:3 != 3:8 != 5:13 [TRUE]
ich würde jetzt einfach mal behaupten, dass sich durch den Autorotationsalgorithmus bei der 'THC'-Transformation bei den amerikanischen 'Gehirnwindungs'-Kompressionsspezialisten Dr. Niemand und und Prof. Unbekannt ein 'weißes Loch' in ihren Subdatenobjekte (gelbes Dreieck im Gehirn) gebildet hat. Und nach Deutsch-Bürokratischen Vorschriften (es gab bestimmt eine, wenn nicht, dann gibt es sie jetzt!) dürfen die Mitarbeiter des Deutschen Patentamtes kein Patent an bekiffte unbekannte verteilen, die zudem noch von weißen Löchern träumen und gelbe Dreiecke im Hirn haben =8) [vor allem nicht an Bekiffte ...]
Ich habe schon 3 Festplatten von Windoofs-Benutzern mit dieser Methode ausgestattet und noch weitere Anfragen. Sie (die Benutzer) freuten sich über den Wahnsinnigen Speicherplatz auf Ihren Platten. Ich freue mich über Deren (die Benutzer) Geschenke an mich (Ich geh jetzt einmal Einkaufen). P.S. Das Kompressionsverfahren habe ich umbenannt, es wird mit "deltree *.* " (Abk.: Delta (von Dreieck); tree von Triple (3) also Dreidimensional) oder mit rm *.* aufgerufen. [Können Windoofs-Benutzer denn überhaupt noch tippen?]
b) Selbst bei angenommener Richtigkeit hätte dieser wahnsinnige Durchbruch in der Kompressionsfähigkeit keinerlei Chance auf Verbreitung. Die starke Lobby der Massenspeicherproduzenten wird aus ihrem Bielefelder Headquarter (http://www.informatik.uni-kiel.de/~ach/bielefeld.html) verhindern, dass solch bahnbrechende Entdeckungen public werden. Ferner scheinen SIE mit Mirc*s*ft unter einer Decke zu stecken. Solch ausgetüftelte Verfahren würden die abgesprochenen, stetik steigenden Resourcenanforderungen der WIntel-Allianz ad absurdum führen. [tadaaah!]
Dadurch dass die verwendeten Farben nicht 100 % zueinander kompatibel sind, wird das Gesamtbild verzerrt. Ich erläutere: Es ist ja allgemein bekannt dass rot und blau sich nicht vertragen, gelb und grün sich ja geradezu lieben. Das ist also auch der Grund weshalb es nicht so richtig klappt. Der Punkt (8, 2) wird auf Bild 1 nicht vom "Dreieck" berührt, das "Dreieck" auf Bild 2 diesen Punkt jedoch berührt. Grund dafür ist dass sowohl gelb, in der Zuneigung zu grün, sehr stark nach links drückt und sich deshalb dem Punkt (8, 2) nähert. Auch blau zieht es zu diesem Punkt, ist es doch so möglich, wenn auch nur geringfügig, sich von rot zu entfernen. Es ist bemerkenswert dass Farben so stark die Flächen beeinflussen. Da man aber für die Datenkompression nicht Farben komprimiert, ist das Prinzip 'Flächenbeeinflussung durch Farben' leider nicht anwendbar (übrigens ist es seit heute zum Patent angemeldet...). Eine andere, allerdings nicht zufriedenstellende, Erklärung ist dass die Linie (von (0, 5) auf (13, 0)) auf beiden Bildern einen leichten Knacks hat. Somit ergibt es sich dass die Gesamtfläche (rot, blau, grün, gelb und, auf dem zweiten Bild, das weiße Loch) verschieden sind. Die beknackte Linie entsteht durch die verschiedenen 'Gefälle' der blauen und gelben Dreiecke. [... und ich fühl mich auch schon ganz blau ...]
Nach einigem Nachdenken bin ich spontan zu der Überzeugung gekommen, dass Nachdenken nicht zum Ergbenis führen wird.... ... [kann ma nix zu sagen ...]
willst Du uns verscheißern? Leute, die den Bastard lesen, sind zwar offenbar geistig unterbelichtet, aber nicht unbedingt auch blind. Da lassen wir uns doch eine Kante mit Knick nicht als Gerade verkaufen! Schick den Prof mal in die Zeichenstunde! Der "Dreidimensionale Sierpinsky-Pfeil" gibt aber immerhin einen netten Bildschirmhintergrund ab. [da sind wir aber froh ...]
ist doch klar wo der fehler liegt ! das ganze basiert auf windoof system (wie im artikel beschrieben) also kann es gar nicht funktionieren ! [(lachlachlach)]
übrigens gibt es eine ganz einfache Möglichkeit, Plattenplatz zu sparen: Man schickt seine Daten einfach auf eine Rundreise ins Internet. Und da das ganze Netz dadurch immer langsamer wird, dauert es immer länger, bis die Daten wieder da sind und neu verschickt werden müssen. D.h. aber, dass man, je länger die Daten unterwegs sind, immer mehr Daten auf die Reise schicken kann. Die Kapazität nimmt sozusagen zu, je mehr das Netz belastet ist :-) [hmmm ... irgendwie kommt mir das doch bekannt vor: funktioniert nicht genauso die wachstumsorientierte Marktwirtschaft?]
Zitat: "Aufgrund der Fensterwirkung der "Weißen Löcher" eignet sich hierzu besonders ein Windows-Betriebssystem.". qed (Was sich für Windows _besonders eignet_, würd ich auch nicht patentieren wollen) P.S.: Falls diese Antwort falsch ist, lautet die Antwort "Metzgerei Harsmann, Plech". [(lachlachlachlach)]
Die Lösung ist doch ganz einfach: Das Patent-Amt verwendet Winblöd 98 [(lachlachlach ... usw)]
Ich dagegen arbeite derzeit an einem wirklich revolutionärem Kompressionsverfahren: Ein Algorithmus zerlegt in einer beliebigen Datei alle Einsen und Nullen und sortiert sie aufsteigend, also erst alle Nullen, dann alle Einsen. Diese Temporäre Datei ist zwar zunächst noch genauso groß wie die Ausgangsdatei, lässt sich jedoch von jedem beliebigen Packprogramm auf Größen von wenigen Bytes bringen. Mit dem Expansions- algorithmus habe ich derzeit noch etwas Schwierigkeiten, aber auch die werden irgendwann gelöst sein. [man kann nicht alles auf einmal lösen!]
Alles klar! Die Datenkompression kann ja so gar nicht funktionieren. Schon im ersten Absatz liegt der Fehler! "MilliByte"! Soll das eine andere Schreibweise für "Bit" sein. Oder die neue Größenordnung für Mini-Computer? Auf jeden Fall hat sich der Autor hier schon in einem Wiederspruch in sich verrannt und deshalb können die nachfolgenden Ausführungen nicht realistisch oder durchführbar sein. Außer vielleicht in der Scheibenwelt. Aber das ist ein anderes Thema. [(gähn!)]