Beiträge von Lord Binary

Hmmmm .... schwierig, schwierig.

Impossible Mission I,II (C64)
Space Taxi (C64)
Hexenküche (Cauldron) (C64)
Kaiser (C64)
Oil Imperium (C64)

Zack Mac Kraken (A5)
Day of the Tentacle (A5)
Maniac Mansion (A5)
Discworld (A5)
Monkey Island (A5)
Weired Dreams(A5)
Nitro (A5)
Supremacy (A5)
Stunts (A5)
Ports of Call (A5)
Nuclear war (A5)
Megalomania (A5)

Wolfenstein 3D (PC)
Civ-I-III (PC)
SimCity I-IV (PC)
Battle Isle I-IV (PC)
Siedler I-IV (PC)
Worms (PC)


u.v.m [Blockierte Grafik: http://hades.gothic.at/iforum/images/smilies/biggrin.gif]

Langsam wirds off topic ?

Noe, langsam wirds interessant

Klar ist Postscript stark mit Adobe verbunden, ((Mit)Erfinder=Gründer) Details z.B hier nachlesbar.

Angeblich haben sie ziemlich hohe Lizenzgebühren für ihre PS Interpreter and Fonts verlangt.
Soweit ich das verstanden hab, kann man seinen eigene PS Inpterpreter schreiben, ohne Lizenzgebühren zahlen zu müssen.
Da die Spezifikation öffentlich zugänglich ist, sehe ich das nicht als "unfrei". Man muß ja nicht die Adobe Implementation "kaufen".

Delikates Detail am Rande: Das PS-Bluebook/Cookbook von offizieller Stelle ist nur im PDF Format erhältlich

Das sagt Adobe zu PDF vrs PS.

Auch die PDF-Spezifikation ist frei erhältlich, ebenso ein "reader".
Hier sind halt die "writers" (von Adobe) unfrei.

Wobei, nebenbei, jeder unter frei/unfrei vermutlich etwas anderes versteht.

---------------------------------------------------------------

PDF files besser zum Drucken geeignet als Websites ?
Klar. Aber das sagt noch nix über PS aus.

Zitat

Jetzt bin ich soweit das ich keine zusätzlichen Programme mehr installiere! Solange funktioniert auch Windows.

:rofl: :rofl: :rofl:

Das sfc tool hat nix gebracht ?
Ist ein sfc problem, ergo naheliegend.

versuch mal das.

http://www.hmonitor.com/

Das kann so eine art temperaturabhäniges "Underclocking".
Wenn die Cpu (oder Mainboard) Temperatur > xx, dann "underclocking" bis Temperatur auf yy gesunken. Also nur mit der (Cpu) Leistung runterfahren, wenn's zu heiß wird.
funktioniert super.

Gehäuselüfter sind natürlich unbedingt zu empfehlen.

Laß mich die Frage anders formulieren ..

Was ist an PDF so toll ?
PDF ist eine abgespeckte postscript Version mit properitäten Erweiterungen.

Im Prinzip völlig unnötig.
(Das Dateiformat ist extrem hässlich obendrein).

Zeig mir einen kleinen, resourcensparednen PDF-Viewer.
Acrobat Reader ist definitv bloatware, hasse das Teil

Aber egal, jeder wie meint.

Was ist dabei einen postscript viewer zu installieren, z.B ghostview ?

Seltsam, aber richtig, gcc 3.2 compiliert das tatsächlich.

Hab' hier ne ältere gcc Version, und da kommt die Fehlermeldung die ich eigentlich erwartet hab: (sinngemäß) ich will x und y konstant !!!

Wär interessant, wie das tatäschlich übersetzt wird.
Speicher dynamisch oder statisch anglegt ?
Egal ... hab im AUgenblick keine Lust auf Assemblercode :]

Wirklich gut debuggen kann man sie allerdings IMHO nur wenn man einen Symbolserver (aufgesetzt) hat.
Außerdem haben solche Dumps die dumme Angewohnheit, genau dann wann man sie braucht eben nicht geschrieben zu werden.
Abgeshen davon hilfts das wenig wenn man gar nicht mehr starten kann.

Aber es ist ein guter Tipp, so kann man recht oft den wahren schuldigen (Treiber/Programm) für BODS finden.

Hier noch offizielle Infos von MS über solche STOPs.
Ist halt meist recht wenigsagend.
(Faulty driver oder hardware, harhar)

Mfg, LB

Naja, Dir ist schon bewußt, daß das grob überschlagen ca 10MB Speicher braucht ?

Wenn das Array jetzt z.B am Stack gespeichert wird -> i.A ein bissi zu viel.

int x = 16000;
int y = 180;
float positions[x][y];

funktioniert/compiliert so überigens sicher mit keinem C/C++ Compiler.

Entweder dynamsich anlegen, dann ist es sowieso nicht mehr am Stack gespeichert. Und der Code zum Speicherreservieren für das Array mit malloc bzw new ist entscheidend.
Oder const int x= ...
Oder ist positions gar eine Klasse mit überladenem [] Operator ?
Glaub ich nicht, denn [][] ist recht tricky mit Operator overloading hinzubekommen.

Kurzum: Da ist IMHO immer noch zu wenig Code um irgendwas Sinnvolles sagen zu können.

Mfg, LB

Bei mehr als einem Leerzeichen gibt's das selbe "Problem".
(eigentlich feature)
Mehre Leerzeichen im latex source hintereinader ergeben ein Leerzeichen im Output.

Am Wichtigsten ist's IMHO sicherzugehen, daß man versteht, daß Latex eben KEIN visual markup system ist.
(und daß das gut so ist bzw zu verstehen warum das sinnvoll ist)
Und daß man es daher tunlichst vermeiden sollte, höchstes in der definitven-final version ein wenig

Erst dann macht's Sinn zu überlegen, wie man z.b einen nicht default vspace hinkriegt.

Just my 2€ cents.

Würde mal sagen, weder noch
Ist nicht *völlig* daneben/mißverstanden, aber die Zusammenfassung paßt nicht.
(wenn ich's richtig verstanden hab).

Das Programm, daß für alle Programme feststellen soll ob sie terminieren, terminiert immer, per Definition. (wär' sinnlos Termination nicht zu verlangen)
Dh. wenn man es auf sich selbst anwendet liefert es immer "Ja, ich terminiere" zurück.
Damit hat man nicht viel gewonnen.

Deshalb braucht man ein zweites Programm, das dieses Program als Subroutine verwendet, und das zweite Programm wendet man auf sich selbst an.
Aber Selbstreferenz (und die Konstruktion des 2 Programms) ist definitv der Clou bei *diesem* Beweis.

Mfg, LB

Sicherlich, bezweifelt auch keiner, daß (hier schreibende) Informatiker das im Schlaf können

Aber aufstehen zählt weder zum Wach noch Schlaf Zustand.
Das ist ein unangehemner, eigenständiger, metastabiler und manchmal durchaus den halben Tag andauernder Zustand, in dem sowas akzeptabel ist.
Jo!

Mfg, LB.

Naja, die Aussage: Ich habs ned verstanden ist ein bissi unspezifisch.

Aber ok, das selbe nocheimal:
Falls das nicht hilft, spezifisch nachfragen.

Grundidee: Indirekter Beweis, dh die Annhame, daß das HP entscheidbar ist auf einen Widerspruch führen. Schlußfolgerung: Die Annahme ist falsch, dh das HP ist eben nicht entscheidbar.

Annahme: Ein fiktitves Programm
bool hält(X,Y)
existiert.
X: beliebiger Source codes in irgend einer fixen (turing vollständigen) Sprache Z, Y ein Input für X.
Es liefert true zurück falls das Programm X mit Input Y terminiert, ansosnten false.

Dann kann man klarerweise dieses Programm konstruieren:

bool komisch(X) ... X wieder beliebiger source code in Z.

komisch(X)
{
wenn hält(X,X) false liefert print("wahnsinn");
ansonsten endlosschleife;
}

Haaalt ...
hält(X,X) ???

Warum nicht !!!
Für die meisten Programme ist zwar der eigene Quellcode kein sinnvoller Input, aber "hält" muß ja auch für sinnlose Inputs das richtige Ergebnis liefern.

Nun rufen wir komisch mit seinem eigenen source code auf.
Und überlegen was passiert.
dh komisch(X); X=source_code(komisch);

Selbstanwendung ist natürlich auch nicht verboten, jeder beliebige Input ist erlaubt.

Nehmen wir an, komisch(source(komisch)) hält.
Dann muß hält(source(komisch)) falsch sein.
Denn nur für hält(..) false terminiert komisch.
Aber hält(source(komisch)) false bedeutet laut Definition von hält, daß komsich nicht hält.
Widerspruch.
Angenommen komisch(source(komisch)) hält nicht.
Dann muß hält(..) true liefern, anders kann komisch in keine Endlosschleife geraten.
Aber hält(source(komisch)) true heißt laut Definiton, daß hält termiert.
Widerspruch.

Das heißt, komisch terminert genau dann wenn komisch nicht terminiert.
Und das ist ... komisch.

Die Argumentation ist korrekt, dh es kann nur an der Annahme, daß hält existiert liegen.
Daher ist unsere Annhame falsch, hält kann nicht existieren, dh. das HP ist nicht entscheidbar.

Mfg, LB

Ja, das da oben ist der "Standardbeweis", IMHO sehr gut & verständlich erklärt
Ein paar Bemerkungen dazu (die man eher selten explizit irgendwo lesen kann):

a) Widerspruchsbeweise sind natürlich immer - notwendigerweise - hochgradig nichtkonstruktiv.
Versuche mal "hält" - trotz des Wissens das es nicht geht - zu konstruieren.
Zu sehen woran es vermutlich scheitern wird, ist ganz lehrreich.

b) Klarerweise kann man sehr wohl (sehr einfach) eine Semi-Entscheidbare Variante von "Hält" bauen.

c) Man könnte vermuten: Das Programm vom Beweis ist ein extrem konstruierter pathologischer Spezialfall. Kann man das Problem eventuell doch lösen/entscheiden, wenn wir so was ausschliessen, z.B verbieten, daß man autsch mit sich selbst aufrufen kann u.v.m ? Hilft nix, ändert nix. Man kann das auch völlig anders beweisen.
(Das ist jetzt SEHR schwammig formuliert, will nur sagen daß der obige Beweis wenig Einsicht gibt wie tief verwurzelt das Problem wirklich ist bzw mit welchen Modifikationen es eventell doch lösbar ist bzw für welche Spezialfälle es immer noch unetscheidbar ist)

d) Die Historie dieses Problems ist auch recht interessant. Besonders weil es schon bewiesen wurde, BEVOR es die ersten (nicht mechanischen) Rechner gab.

e) Viele andere Unentscheidbarkeitsresultate, z.B (Output)Äquivalenz von 2 Programmen, ergeben sich unmittelbar aus der Unentscheidbarkeit des Halteproblems.

Mfg, LB

Ok, erster Versuch ohne "Formelgedöns".

Ist daher grausam unexakt, bitte nicht schlagen,
aber es hilft vielleicht eine Ahnung zu kriegen, um was es überhaut grob gesehen geht
Und der Zweck heiligt ja bekanntermaßen alle Mittel ...

Endlosschleifen sind in der Praxis recht unangehm, kaum jemand baut sie beabsichtigt ein. Wenn sie zuschlagen, bleibt das Program "hängen". Nicht gut.
Man kann sich in der Regel nie 100% sicher sein, daß es sie nicht doch gibt, gut versteckt, nur für ganz bestimmte Inputs. Passiert jedem (irgendwann), auch den erfahrensten Profis.

Daher der Gedanke: Kann man nicht ein Programm bauen, daß für beliebe andere Programme als Input, überprüft ob es eine Endlosschleife enthält (Nicht hält) oder nicht (hält) ?
Wär' doch wunderbar ...

Aber der Clou ist eben, daß es so was PRINZIPIELL nicht geben KANN. Dh das Halteproblem zu lösen (wollen) ist sozusagen ein informatisches Perpetuum Mobile.
Daß kann man streng mathematisch beweisen.
Um das zu tun, muß man die Aufgabe (Halteproblem entscheiden) formalisieren, dh in Formeln/Formalismen/etc giessen, und dadurch wird's ein bisschen unverständlich/unzugänglich, für die die nicht in dieser Sprache geübt sind.

Zu erklären WARUM das so ist, ganz besodners OHNE "Formelgedöns", das ist etwas challenging, vorallem fehlt mir heut' die Zeit dazu.
Bei Bedarf melden

Mfg, LB

Oder natürlich wenn die MAC Tabelle noch leer ist

Teuere, manageable Switches (z.B mit SNMP) könenn/müssen sehr wohl MAC/IP Addressen haben.
Ein normaler 08/15 Switch hat aber keine.

Hubs können prinzipbedingt keine Adressen haben
(Da Layer1 Ding)

Mfg, LB

Naja, daß das nur "leistbare" Switches können ist nicht richtig.


Hab' zwei billig 8 Port Switches (a 15€) zusammengeschaltet um einen 14 Porter zu bekommen.
Und die "lernen" definitiv die Adressen die hinter dem "Uplink Switch" sind. Also nix broadcast/Hub (außer einmalig).
PC A hängt am Swich 1, PC B an Switch 2, Daten senden von A nach B, es blinkt jeweils (brav) nur in Lichtlein an jedem Switch.

Mfg, LB

Chello anzurufen und Deine neue MAC Adresse bekanntzugeben funktioniert übrigens auch

Ok, das ist die ödeste Variante ...

Mfg, LB

Zitat

aber ich verstehe nicht, warum ich dann den akku rausnehmen sollte, statt einfach das kabel auszustecken (daher auch oben meine annahme, das es anders gemeint war).

Genau das wollte ich eigentlich sagen
(Ein bischen länglicher als geplant)

Es ist eben völlig egal ob der Akku - mit ausgestecktem Kabel - im Laptop ist oder rausgenommen ist.

Voller Akku und Anschluß ans Netz ist nicht *völlig* egal wegen Wärmeentwicklung.

@klwe: Ja, stimmt.
Nennt sich Tiefenentladung und das ist fatal.
Im Gegensatz zur Wärme, die ist nur "Suboptimal".
Klar, jeder Akku hat nur eine begrenzte Anzahl an Lade/Entladezyklen - unabhängig von der "Akkupflege". Danach geht's steil bergab ...
ASFAIK (nicht 100% sicher) zählt die Ladungserhaltung bei schon vollem Akku NICHT als Zyklus.
Aber z.B von 80% auf 100% laden schon.
Allerdings ist's mir zugegebenmaßen zu umständlich, aus Akkupflege eine Wissensachaft zu machen und auf all diese Dinge zu achten

Falls ich meinen Laptop mal für ein paar Tage als Desktop Ersatz brauch' nehm ich den Akku raus.
Ansonsten ist's mir zu mühsam

Michi: Das wär' mir neu ... Kann zwar nicht alle Laptops kennen, aber das machen doch alle ... Akku laden selbst wenn abgeschaltet. Natürlich nur falls an die Stromverorgung angeschlossen. No nah