Beiträge von Andy

    //EDIT

    UEZ war schneller....so ist das, wenn man die Posts erst Stunden/Tage nach dem Editieren los schickt :Face:





    Hi,

    ich hatte die Idee, dein Programm auf "oldschool"-GDI umzuschreiben.

    Sourcecode ist ca halb so lang, dafür doppelt so schnell^^


    Es wird eine Bitmap in den DC des Fensters erstellt, die Funktion dazu liefert den Pointer auf die Pixel. Über eine DllStruct() an der Position dieser Bitmap kann man nun per DllStructSetData() direkt "Pixel" schreiben.

    Leider gibt es keinen Datentyp "BIT" in der DllStruct(), um eine 1-Bit-Bitmap über die DllStruct() mit Daten füttern zu können, deshalb habe ich eine "normale" 32-Bit-Bitmap (die ist 32x so groß wie eigentlich benötigt wtf) verwendet.



    Und ja, wer noch eine "sehr" (ca. 10 Jahre) alte AutoIt-Version hat, der kann sich über noch mehr Geschwindigkeit freuen, im Zuge der "Weiterentwicklung für PRO-Scripter" hat man nämlich damals sämtliche nativen String- und DllStruct-Funktionen in AutoIt verlangsamt, um die PRO-Funktionen (bspw. RegEx aka PCRE) Geschwindigkeitsmäßig besser aussehen zu lassen.....die entsprechenden Threads dazu hier im Forum sind wie so viele andere im Nirvana verschwunden...

    Der Code ist hammerhart zu interpretieren.

    Naja, ich dachte eigentlich, die Kommentare seien für einen Programmierer gut zu verstehen. Und exzessiv Zeilen eingespart habe ich auch nicht.

    Zugegebenermaßen ist das nichts, was man auf Anhieb durchschaut. Wenn man die Idee dahinter versteht, ist es viel einfacher.

    das ist ja kürzer als das Beispiel zu GUICtrlCreateButton.

    ...ich erinnere nur an den Sudoku-Solver in 62 Bytes. Leider sind die Beiträge dazu wohl für immer im Forums-Nirvana verschollen oder schon ins NUL-Device geschoben worden....

    Hi,

    Nachdem ich nicht jünger werde und die Uhr von Windows recht klein

    hehe, willkommen im Club.....:thumbup:


    Meine Uhr ist ein bissl größer, kommt aber dafür mit weniger als 50 Zeilen Code aus. Und ja, die Erzeugung und Darstellung der Ziffern ist hardcore Scriptporn. Wer das Bitgeplänkel verstehen möchte, sollte sich einige Blätetr Papier und einen Bleistift besorgen und benutzen :o)

    Digitaluhr.zip

    ch verstehe einfach nicht wie die Antivirenhersteller so unfassbar bescheuert sein können

    Wie? Hab ich was verpasst? Antivirenhersteller bescheuert?!


    Was ist denn mit den Leuten, für die diese Software überhaupt gemacht wird?! Wie Leute, die diesen Thread erstellen beispielsweise....und die, die darauf antworten mit derselben "Message":


    *********************************************

    "Na klar hab ich nen Antivirenprogramm, ÜBERALL lauern schliesslich Viren, Ich treib mich schliesslich auf sämtlichsten zwielichtigen Internetseiten rum, doppelklicke jedwegen Link in an mich gerichtete Emails, installiere Software, die ich "umsonst" runtergeladen habe, hab Flash und Javascript im Browser IMMER angeschaltet, weil sonst die schon von mir oben genannten "Alda ich schwör, die Website hier ist GARANTIERT Virenfrei!!!!!"-Programme "natürlich" nicht laufen.

    Dass ich überall im Netz meine sämtlichen persönlichen Daten in alle verfügbaren Anmeldeformulare eintrage, weil es dort einen "Bonus" dafür gibt, ist doch selbstverständlich, machen die anderen doch auch...

    Natürlich benutze ich auch einen Passwortsafe ("gesichert" durch eine 4-stellige PIN) damit ich nicht auf jeder Website irgendwelche esoterischen Passwörter eingeben muss. Für die 478 Websiten, in denen ich angemeldet bin, wäre das auch sonst ziemlich dumm gelaufen!

    Vergessen darf man aber auch nicht die ganze Software auf dem "smarten" Phone, da ist mir auch völlig egal von wem die kommt und welche Rechte die haben darf. Zugriff auf Kamera und Mikrofon für jedwege App?! SELBSTVERSTÄNDLICH, denn passieren kann da sowieso nix, der Betreiber verschlüsselt doch die Daten auf seinem Server und gibt diese Daten sicher an keinen anderen weiter. Sagt er. In Rumänien ist das Pflicht für Hoster. Glaub ich jedenfalls.

    Neulich hab ich sowieso den Hauptgewinn gezogen, ein afrikanischer Anwalt hat mich als den letzten lebenden Hinterbliebenen eines Stammesfürsten ausgemacht. Ich flieg jetzt nach Kenia und hol die Millionen dort ab. Ich soll auch sämtliche Ausweise, Stammbuch , die Rentenversicherungsnummer, Kredit- und Bankzugangskarten und auch sonst noch alles mitnehmen, was mich ausweisen kann. Angst hab ich keine, der Typ der mir die Email geschrieben hat ist schliesslich Anwalt. Steht so in der Mail....

    Zuhause hab ich ja, dank SmartHome, alles gesichert. Die Zugangsdaten für die "smarten" Türschlösser hab ich derweil in einer KOSTENLOSEN rumänischen Sicherheitsapp gespeichert. Und den Schlüssel für die Türen vorsichtshalber unter den Stein neben der Haustür gelegt. Fotos davon sind natürlich in der Cloud.

    Sicher ist schliesslich sicher....

    ***********************************************


    Und ihr beschwert euch über "false positives", die man bei den gängigen Virenprogramm-Herstellern teilweise innerhalb von Stunden "freischalten" kann.

    kann ich gleich in die tonne treten wenn sowas einfaches schon als virus von ALLEM erkannt wird.

    Warum machst du das nicht einfach?! AutoIt in die Tonne treten. Es gibt massig Alternativen. Hier rumquieken, weil du nachgewiesener Maßen nicht mal in der Lage bist, ein "virenfreies" Programm zu schreiben / zu compilieren / zu übersetzen, hilft nicht. Qualifizieren und weiterbilden hilft. Und virenfreie Programme schreiben. Was qualifiziert dich (und viele andere auch) eigentlich zu der Aussage, dass AutoIt per se KEINEN virulenten Code enthält/erstellt.

    Weil ALLE Antivirenwebsites deinen Code als "sauber" kennzeichnen? Schon mal was von Zero-Day-Exploits gehört?

    Google, Microsoft, Apple, Samsung und viele andere Softwarehersteller bezahlen mittlerweile Millionen dafür, "Exploits" in ihrer Software gemeldet zu bekommen. Diese Exploits werden dann weiterverkauft an die Antivirenprogramm-Hersteller. Für Milliarden. DAS ist ein Geschäftsmodell, mit dem man GELD verdient....

    Da du beeindruckend viel Ahnung von dem hast, was du hier von dir gibst, solltest du ggf. in diesem Bereich tätig werden. Und nicht "..sowas einfaches schon als Virus.." programmieren...

    Alternativ ginge es auch mit einem "Wemos D1 mini" (ESP8266). Dann könnte man das auch per Browser (HTML) im WLAN abrufen.

    DAS wäre mein Vorschlag. Letztendlich geht es ja darum, was 1x pro Minute mit dem Messwert gemacht werden soll?! In Datei schreiben, in "irgendine" externe Software reinschreiben (per Autoit), Fragen über Fragen ^^


    Allerdings braucht der dann mehr Strom (in Spitzen bis 200mA).

    Du hattest schon das "billigste" Handy-Netzteil vorgeschlagen...8o

    Da müsste ich mich aber erstmal mit der Kommunikation zu AutoIt intensiver beschäftigen.

    Hab da was....nicht nur über AutoIt, sondern auch per MIT App Inventor 2 https://de.wikipedia.org/wiki/App_Inventor

    Damit frage ich Daten per Smartphone und WLAN vom ESP ab.


    Alternativ direkt zum Einstecken in einen USB-Port am Rechner

    https://www.amazon.de/kcTrade-Digispark-kompatibles-Development-ATtiny85/dp/B07S36D5L5/ref=sr_1_5?__mk_de_DE=ÅMÅŽÕÑ&crid=SGRCPUJRZ43M&keywords=digispark+attiny85&qid=1573061497&sprefix=digispark%2Caps%2C168&sr=8-5



    BugFix, ich würde dir ja nen ESP oder DigiSpark schenken, aber das wäre wirklich der wirtschaftliche Totalschaden. Porto und Verpackung und selbst wenn du den abholen würdest, kostet mehr als der Brocken selbst....:Face:

    Hi,


    die Hilfe hat einen Browser im Hintergrund, man kann also sehr einfach im Quellcode der Seite bspw nach "Dieses Script öffnen" suchen und sehen, was da passieren soll.

    Ein Klick auf diesen Link führt zur Ausführung einer *.au3-Datei.

    Ändere also im Kontextmenü einer au3-Datei im Explorer bei "öffnen mit" und dann "Andere App auswählen" auf deinen Editor (Haken bei "immer diese datei mit blablub-Editor öffnen" nicht vergessen"), und beim nächsten Klick in der Hilfe wird die (Hilfe-)Datei in diesem Editor geöffnet.

    hmmmm,

    Du kannst ja mal in der Original C++ Source reinschauen

    ich bin anhand des Codes in o2cando´s Link davon ausgegangen, dass ebendieser C(++)-Code die Vorlage vom AutoIt-Script war!?

    OpenCL hatte ich bereits nach AutoIt transformiert, es ist lediglich der in C (ohne ++) geschriebene Kernel notwendig.

    Imho "reicht" dann auch GDI um die Pixel mit reichlich FPS auf den Schirm zu bringen.


    btw. AMD-CPU-Besitzer (NICHT GPU!!!) sollten die aktuellen INTEL-CPU-Treiber für OpenCL installieren GetUniqueColors

    Hi mainline,


    bevor du rennst, solltest du erst mal laufen lernen!

    Dein Code ist verbuggt, und als Anmerkung schreibst du dann "... <= klappt wunderbar und sieht gut aus". Was mal deutlich fett gelogen ist, da reihenweise fehler fliegen....

    Neben den Syntaxfehlern ignorierst du auch alpines Hinweise bzgl. der Indizierung von Arrays.


    Hier übrigens das "wunderbar klappende" Script nach Änderungen:


    //EDIT

    ...so ist das, wenn man vor dem abschicken von Posts Kaffee kochen geht^^

    Hi,

    SEHR schön umgesetzt, sowohl die Idee, als auch der Code!:thumbup:

    Ich für meinen Teil halte die erreichte Geschwindigkeit mit AutoIt für TOP!

    - Im Video sieht man so etwas ähnliches wie einen "Pfad" der einzelnen Punkte, was einen coolen Effekt hervorbringt. Dies habe ich auch versucht, indem ich alle Punkte des vorherigen Schrittes in einem Array gespeichert habe, und lediglich Verbindungslinien von "alten" zu "neuen" punkten gezeichnet habe. Jedoch sieht das ziemlich blöd aus und ist ziemlich ineffizient denke ich. Ist der Ansatz mit einem transparenten clearing besser? Wenn ja, wie?

    ja, der Ansatz mit "transparentem clearing" ist besser und frisst (wenn überhaupt) nur unmerklich Performance.


    Im Video sieht es ziemlich flüssig aus. Ich denke dass dies nur mit Assembler möglich ist, oder gibt es da noch einen anderen Weg mein Skript zu beschleunigen?

    Als jemand, der (ich hab gerade festgestellt 40 Jahre) Erfahrung mit Assembler hat kann ich dir nur sagen, LASS ES!

    Abgesehen davon, dass es süchtig macht, wenn man die ersten Ergebnisse erzielt, dauert die Einarbeitung imho heutzutage zu lange.

    Du solltest also zuerst deinen Code profilen um herauszufinden "wo es hängt".

    Im vorliegenden Script hast du leider mehrere "Baustellen".

    Die erste ist die " Berechnung", ja die kann man extrem beschleunigen, allerdings geht das wesentlich "billiger" aka einfacher mit einer per HLL erstellten DLL.

    Da stellt sich dann natürlich die Frage, wieso nicht das komplette Programm in bspw. FreeBasic oder einem beliebigen anderen Compiler schreiben.


    Was direkt zum zweiten "Problem" führt, GDI(+).

    Dessen Langsamkeit kann nur mit einer anderen Grafikbibliothek kompensiert werden. Ob das jetzt OpenGL oder etwas anderes sein muss, ist ehrlich gesagt Geschmacksache.

    "Modern" programmiert man im und für den Browser, also WebGL, letztendlich läuft das auf Webasm (WebAssembly hat wenig zu tun mit Assembler) raus...

    Alternativ bliebe das Schreiben der "Pixel" direkt in den GDI(+) Grafikbuffer, dann sind auch mit GDI locker 300-400FPS drin.


    Dann stellt sich natürlich die Frage, was bedeutet "schnell".

    In einem deiner Links bzw. weiterführender Links wird beschrieben, dass 400.000 "Punkte" berechnet werden, ich gehe davon aus, pro Frame. Das hört sich auf den ersten Blick "viel" an, aber auf einer 4Ghz-Maschine würde bei Verwendung von nur einem Thread der Prozessor 1000 Takte für die Berechnung von EINEM Punkt benötigen. Prozessorlast bei 0,1%. "Schnell" ist also relativ....

    Multithreading wäre eine Lösung, aber der Prozessor ist imho sowieso nur noch Verwaltungswerkzeug, wenn es um Grafik geht, Direkt die Shader programmieren ist State of the Art.


    Du siehst also, Optimierungspotenzial ist reichlich vorhanden.

    Wobei, und das möchte ich ausdrücklich betonen, für mich ist das Programm ausreichend schnell! Und auch sehr schön in AutoIt programmiert!

    Um jetzt in AutoIt weiter zu rocken würde ich direkt auf OpenGL setzen, oder auf OpenCL. Per OpenCL würde der Berechnungsteil direkt auf der Grafikkarte passieren und in einem OpenGL-Fenster dargestellt.

    Aus dem Bauch raus würde ich für diese Kombination eine Beschleunigung um Faktor 100 annehmen (sehr defensiv geschätzt :o) )


    Ja, in etwa auch so läge die erreichbare Geschwindigkeit per Assembler, allerdings mit wesentlich mehr Aufwand!

    Hi,

    Gibt es ein Skript, welches ältere Skripte automatisch auf Zeilen überprüft, die bei Verwendung der aktuellen AutoIt Version entfernt oder umbenannt werden müssen?

    ein Script nicht, das wäre auch unsinnig...


    Aber in Scite hilft die F5-Taste! Die ggf. im Ausgabefenster angezeigten Fehlermeldungen durchlesen, verstehen, die Fehlerzeile im Ausgabefensterdoppelklicken springt zur Fehlerzeile im Script, dort Script lt. beschriebener Fehlermeldung ändern. Nochmal F5 drücken uswusf.

    Dauert bei den allermeisten Fällen nicht mal 2 Minuten, bei hartnäckigeren Problemen vielleicht 5.

    Hi,

    zwei Scripte "nebeneinander" an einer Aufgabe arbeiten zu lassen, führt genau zu dem in deinem Beispiel gezeigten Ergebnis.

    Frag dich mal selbst, ob du irgendein Programm kennst, das auf diese (deine) Art und Weise arbeitet....

    Damit sollte die Frage schon beantwortet sein!


    Also während das Hauptskript läuft und das Nebenskript nachträglich zusätzlich aktiviert wird, warten auf Popup Fenster vom Nebenskript. Wenns erscheint, sofort schließen, da es nur ne Infobox ist.

    Genau so wird das "richtig" gemacht!

    Also los!


    Btw. ist es wesentlich einfacher zu helfen, wenn man die Scripte auch lesen kann! Glaskugeln ist heutzutage absolut nicht mehr "hip".

    Wenn du demnächst eine Frage hast, häng die Scripte an...

    Hi,

    Stringtobinary() ist dein Freund....


    btw., Hex() wandelt Integer um, ist also in diesem Fall falsch.


    Naja, wenn ich mir ab und zu die Bundesliga ansehe, dann frag ich mich schon, wer da mehr "Mädchen"-Fußball spielt :o)

    Ich schaue gerne Damenfuß- und in letzter Zeit auch Handball. Technisch ist da nicht mehr viel unterschied. Imho hängen sich die Mädels auch wesentlich mehr rein als die Jungs, die dann obendrein für ein 0:0 rumgekicke noch 20x so viel Kohle abstauben.

    Ich wäre sowieso dafür, bei einem 0:0 BEIDEN Teams mindestens 5 Punkte abzuziehen, besser 10. Dann würde definitiv wieder Fußball gespielt, und nicht "taktisch" ein Punkt nachhausegeeiert....

    Naja, "Koordinaten" aus Binärdateien rauszuholen, sollte nicht das Problem sein. Wenn man weiß, nach was man sucht....


    "Früher" hat man die Daten weder komprimiert, noch sonstwie "verkleinert", jedenfalls nicht mit einem Kompressionsalgorithmus. Bissl "bitweise zusammengeschoben" um einige Bytes an dem teuren Disketten/Festplattenplatz zu sparen war "State of the art".


    Von daher wäre es jedenfalls sinnvoll, jeweils eine Datei mit den "Steuerungsdaten" (im Klartext, bspw. g-code) zu bekommen, als auch eine der daraus erstellten "Binärdateien".


    Ich verweise da mal auf DTX Daten als Bild in GUI anzeigen

    So macht man das...

    Ich hatte in Ruhe gelesen^^

    Nun zitiere ich dich:

    dann muss das Ergebnis korrekt auf die darstellbare Genauigkeit hin gerundet sein

    Was soll DAS denn? "Korrekt" ist ja wohl mit mehreren verschiedenen Möglichkeiten einer Rundung schlecht machbar, oder nicht?!

    Und die Anzahl der Stellen ist dabei belanglos, denn das definiere ich ja in meinen Anforderungen.

    Das Problem ist, und das kommt in diesen Beiträgen keineswegs rüber, nicht die Berechnung an sich, sondern die Darstellung der Nachkommazahl.

    Und die hat wiederum mit der Genauigkeit der Berechnung nichts zu tun!

    Beispielsweise rechnet die "alte" FPU in x86-Prozessoren mit 80 Bit Genauigkeit. Dargestellt werden idR Zahlen (nach IEE 754) mit 64 Bit. Man könnte jetzt meinen, egal nach welchem Verfahren gerundet wird, das Ergebnis ist immer "richtig", da der letzte Teil der Nachkommastellen, die 16 Bit Differenz, sowieso abgeschnitten wird. Für eine einmalige Addition/Multiplikation ist das auch wahr, egal welchen Rundungsmodus ich im Prozessor einstelle.

    Also wo liegt das Problem? Das Problem liegt in der Berechnung innerhalb langer Schleifen, in der dieser "Fehler" in jeder Berechnung mitgeschleppt wird. Irgendwann dringt der Fehler in den Bereich der Darstellung vor, wobei die Anzahl der dargestellten Nachkommastellen dabei irrelevant ist.

    Konkreter: Rechenergebnis mit 10 Stellen wäre: 0,1234567890 - dann muss diese Zahl folgendermaßen auf 5 Stellen abgebildet werden: 0,12346 anstatt einfach nur 0,12345 hinzuschreiben

    Soweit richtig. Was dabei aber vergessen wird, ist denn die Berechnung (NICHT die Darstellung!) des Ergebnisses, also in diesem Fall die "Zahl" 0,1234567890 überhaupt "richtig"? Denn je nach Rundungsmodus/Einstellung Prozessor weicht das Ergebnis nach einigen Millionen Iterationen um Faktor X ab. Wenn jetzt nach diesen einigen Millionen Iterationen das Ergebnis bspw. 0,2345678901 lautet, dann ist es völlig unerheblich, ob diese Zahl dann "korrekt" auf 5 Stellen gerundet wurde.

    und durch entsprechende Standardisierung auch einheitlich.

    So muss das auch sein, aber wieso sieht die IEEE dann explizit 3 Rundungsmodi vor? Um doch genau die Freiheit zu geben, diesen "Fehler" (im System) geradezubiegen. Und zwar so, dass das Ergebnis zur Berechnung "passt".

    Das eigentliche Problem ist systemimmanent bei Berechnungen im Binärsystem. "Flippe" ich das letzte Bit der Berechnung oder nicht? Halbe Bits gibt es keine....

    Die von dir angesprochene "Standardisierung" sagt

    Zitat

    Statistisch wird dabei in 50 % der Fälle auf-, in den anderen 50 % der Fälle abgerundet,

    aber laut der Anwendung dieser Statistik haben ein Millionär und ein armes Schwein jeder eine halbe Million!


    Wenn die Raumfähre den Landeplatz auf dem Mars verfehlt, weil Europäer und Amerikaner unterschiedliche Maßsysteme verwenden, dann kann man darüber grinsen, aber wenn das passiert, weil bei der Auswahl des "Rundungsmodus" statt "Richtig" einfach nur "Standard" (in diesem Falle FALSCH, denn das Ziel wurde verfehlt) gesetzt wurde, dann werde ich nachdenklich.



    Es kam schon öfter vor, dass ich diverse Algorithmen in ASM umgesetzt hatte und meine Ergebnisse (mit Standard-Einstellung) von denen diverser Compiler/Prozessoren abwichen. Bei der Analyse des Sourcecodes/Compilereinstellungen stellte ich dann fest, dass die Programmierer sehr wohl die unterschiedlichen Möglichkeiten bspw. beim Runden nutzen (in den Prozessoreinstellungen!) , um das Ergebnis an ihre Erwartungen anzupassen.

    Bei Crosscompilern ist das auch bitter nötig, und wenn das nicht funktioniert, na dann wird eben ein "Emulator" benutzt, der die Berechnungen aka Ergebnisse "richtig" anpasst.


    Um bei der Landefähre zu bleiben: Wird der Landeplatz auf dem Mars erreicht, weil bei der Berechnung alles "richtig" berechnet wurde, dann heißt das noch lange nicht, dass dieses System mit identischen Berechnungen zielgenau auf dem Jupiter (oder einem seiner Monde :o) ) landen würde....

    "Standardisiert" ist immer nur so gut wie das damit erreichte Ergebnis.

    Und der Grund warum diese sich in manchen Fällen scheinbar nicht auswirken liegt nicht in der Art der Speicherung wie sie in IEEE 754 definiert ist begründet sondern in der anschließenden Konvertierung der Zahl in einen String.

    ....was ja nichts weiter ist (wie von dir oben beschrieben) als ein "abschneiden" der restlichen Nachkommastellen.

    Was aber das Rechenproblem mit dieser "Zahl" letztendlich auch nicht löst, weil der "normalo"-Programmierer davon ausgeht, dass die Rechenvorschrift ein "richtiges" Ergebnis liefert. Und da liegt das eigentliche Problem. Solange der Prozessor/Controller aka "Chip" auf der Platine die letzte(n) Stelle(n) (ich sag es jetzt mal provokant) nach "gutdünken" vergibt, wird sich daran auch nichts ändern!

    Natürlich macht der Prozessor das, was ihm der Programmierer vorgibt. Aber um das das "richtige" Ergebnis einer Berechnung "vorherzusagen", reicht es eben nicht, freudestrahlend auf F5 zu hauen und davon auszugehen, dass "richtig" gerechnet wurde.

    Denn den Prozessor "richtig" Rechnen zu lassen, hängt von den verschiedensten Faktoren ab. Runden (https://de.wikipedia.org/wiki/IEEE_754#Rundungen) oder das gerne verwendete (De)Normalisieren.

    Da hat man dann schnell mal zwei Handvoll Möglichkeiten, "richtig" zu rechnen, aka "richtige" Ergebnisse zu erhalten.

    Getoppt wird das alles noch, wenn man sich https://de.wikipedia.org/wiki/…thmetik_und_Quadratwurzel durchliest.

    Zitat von Auszug aus Wikipedia

    IEEE 754 verlangt von einer (Hardware- oder Software-)Implementierung exakt gerundete Ergebnisse für die Operationen Addition, Subtraktion, Multiplikation und Division zweier Operanden sowie der Operation Quadratwurzel eines Operanden. Das heißt, das ermittelte Ergebnis muss gleich demjenigen sein, das bei einer exakten Ausführung der entsprechenden Operation mit anschließender Rundung entsteht.

    Aha. Wenn sich also alle Beteiligten auf EINE der "richtigen" Möglichkeiten einer Berechnung geeinigt haben, dann ist dieses Ergebnis "richtig"!

    DAS muss man verstanden haben, damit der Satz des TE verständlich wird:

    Merkwürdiger Weise ist das Ergebnis davon anders als erwartet :D

    "ERWARTET" ist nämlich das Stichwort.

    Und das ist auch das, um was sich die IEEE 754 gelinde gesagt herumdrückt.

    Das Ergebnis einer Rechenvorschrift ist genau DANN "richtig", wenn das (von wem auch immer) erwartete Ergebnis eintritt!

    Ergo MUSS man im Vorfeld wissen, was das erwartete Ergebnis sein soll, um die (Prozessor/Software-)Einstellungen so vorzunehmen, dass auch genau dieses Ergebnis nach der Berechnung eintritt.


    Was passiert, wenn man das NICHT tut, damit kann man Webseiten füllen....

    https://www5.in.tum.de/~huckle/bugs.html

    https://www5.in.tum.de/persons/huckle/bugse.html



    Lanealine,

    Programmieren heißt, den Code so "hinzubiegen", dass das vom Programmierer erwartete Ergebnis eintritt. Und möglichst alle Eventualitäten, die dieses erwartete Ergebnis verfälschen könnten, zu erkennen und programmiertechnisch im Vorfeld (!) zu beseitigen....

    Da hilft nur, "wach" zu bleiben und regelmäßig (anderer Leute) "fehlerhaften" Code zu debuggen. Viel Spass dabei! Die "Fehler" (die ja nichts weiter sind, als "andere Erwartungen") so hinzubiegen, dass die "Erwartungen" erfüllt werden, ist die eigentliche Kunst!

    Hi,


    zunächst, was sind das denn für Textdateien mit welchen Einträgen, die von vielen "gleichzeitig" (24-Kernprozessor?!) gestarteten Prozessen abgearbeitet werden müssen?

    Wenn ich sehe, dass du mit FileReadToArray($Textdatei) arbeitest, was ohnehin eine der langsamsten Autoitfunktionen ist, dann frage ich mich ernsthaft, ob es nicht Sinn machen würde, dein PROBLEM zu schildern, statt an einer von dir vermuteten (!) "guten" Lösungsmöglichkeit rumzudoktoren!

    Stichwort X-Y-Problem!


    Mit mehreren Prozessen eine Datei zu bearbeiten macht nur dann wirklich Sinn, wenn ausreichend Prozessorkerne mit eigenem (großen) Cache bzw. Speicher zur Verfügung stehen.

    Wenn obige Scripte auf einem bspw. Vierkernprozessor mit angenommen 12 "Threads" (Programmstarts) abgewickelt werden sollen, dann dauert das idR länger, als nur mit 4 Programmstarts. Windows nimmt dem laufenden Thread sowieso über die Zeitscheiben seine Arbeit weg um die anderen Threads zu bedienen. Wenn man das auf die Spitze treibt und 200 "Threads" startet, dann bleibt der Rechner stehen, weil Windows mehr mit der Verwaltung der Threads zu tun hat, als Zeit für das "Problem" zur Verfügung zu stellen!

    BTW: Ein Tool zum Servermonitoring sollte eine Schnittstelle für Alarmierungen bereits mit anbieten. Wäre sicher der verlässlichere Weg!

    "Sollte" ist das Stichwort...

    Ich arbeite täglich mit webbasiertem Monitoring für Produktionsmaschinen/Mitarbeiterarbeitsplätzen. Da gibt es NICHTS, was nicht explizit seitens Softwarehersteller vorgesehen ist, alternativ "nachgepflegt/programmiert" worden ist. Manche Dinge sind nicht einmal vorgesehen, da seitens Programmierer dieser Fall/Fälle infolge mangelnder Fachkenntnis (die sind schliesslich Programmierer und keine Anwender! ) nie den Weg in die Software gefunden haben noch finden werden.

    Zitat von Wikipedia

    AutoIt ist eine Software zum Ausführen von Skripten, mit denen hauptsächlich Abläufe unter Microsoft Windows automatisiert werden können,

    ...genau DAFÜR ist es da! Um nicht vorhandene Funktionen/Abläufe "nachzubilden", die es sonst nicht gegeben hätte!