1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Andy

Beiträge von Andy

  • _GDIPlus_BitmapApplyFilter v0.9.6 build 2017-05-14 beta

    • Andy
    • 4. Juli 2016 um 03:49
    Zitat von UEZ

    Ich glaube nicht, dass mit den Standard ASM Befehlen ich überhaupt was rausholen kann.

    "was rausholen" ist das Stichwort...
    Mal angenommen, die Berechnungen für einen Filter dauern 300 Millisekunden. Dann hat der Programmierer ggf. noch einige Compilerflags gesetzt, und das sind die einzigen Stellschrauben, an denen er drehen kann, wenn (und ja, WENN(!) ) der Algorithmus ausoptimiert ist!
    Schaut man sich dann an, was der Compiler gemacht hat, wird man feststellen, daß bspw. für "Standardfunktionen" wie Sinus/Cosinus/Wurzelziehen/uswusf. ein API-Call bzw. ein Call der "eigenen" Bibliotheken erfolgt. Dort wiederum wird u.a. sämtliches Errormanagement betrieben, was sich die Bibliothekenbauer in den letzten 30 Jahren nur vorstellen konnten, um ALLE vorstellbaren Fehler des Programmierers abzufangen und auszuwerten und anzuzeigen, damit um Himmels Willen nur kein Absturz bei irgendeinem Programm erfolgt. Das ist idR auch gut so, da meiner Erfahrung nach Programmierer sich sehr gerne darauf verlassen, dass sie absolut keine Fehler machen... ;)
    Weiterhin angenommen, der Programmierer weiß was er da tut, kann er dann, statt die "superduper-absolut-Hochsicherheits-volldeppensichere-Sinus-Bibliotheksfunktion", welche "nur" 550 Prozessortakte benötigt, auf die vom Prozessor zur Verfügung gestellte Sinusfunktion zurückgreifen, welche diese Berechnung in meinetwegen 50 Takten abwickelt.
    Bei einem Full-HD-Bild mit ca. 2e6 Pixeln macht das bei 550 Takten/Sinusberechnung über den Daumen 1e9 Takte, bei 2Ghz Prozessortakt dauern alle Berechnungen somit ca. eine halbe Sekunde!
    Zwingt man nun, üblicherweise durch "inlinen" von Assemblercode, den Compiler zum Verwenden des fsin-Befehls der FPU, reduziert sich nur dadurch die Laufzeit des Filters um einiges....

    Das alles kann man aber nur dann "optimieren" wenn man sieht und versteht, was der Compiler macht. Einige Compiler sind richtig gut, andere eher nicht. Heutzutage würde ich mich bei "Standard-Berechnungen" nicht mehr mit einem Compiler anlegen wollen, allerdings gibt es imho nur extrem wenige Compiler, welche bspw. die seit Jahrzehnten verwendbaren SIMD/SSE-Befehle auch umsetzen....und da ist dann auch mal der Faktor 3-4 an Laufzeiteinsparung drin, wenn man diese "richtig" einsetzt.
    Wer als Hobbyprogrammierer sich dieses "Handoptimieren" antuen will, ist ja eine ganz andere Frage :theke:
    Eukalyptus hat da ja schon einiges vorgelegt :rock:

  • _GDIPlus_BitmapApplyFilter v0.9.6 build 2017-05-14 beta

    • Andy
    • 3. Juli 2016 um 19:57
    Zitat von UEZ

    , aber dann würden mir mit hoher Wahrscheinlichkeit die letzten Haare ausfallen...

    ....und dann würdest du so aussehen wie ich :D

    Sehr sehr feines Script, wie immer :thumbup: . Und ENDLICH hat es mal jemand geschafft, eine Compilersprache mit Nähe zu AutoIt einzubinden. :klatschen:
    Da kann ich mich ja (endlich?!) mit ASM zur Ruhe setzen...NIX DA, der FreeBasic-Compiler schreibt wirklich guten Code, aber gerade im Bereich SIMD/SSE geht da doch noch einiges :saint: . Und da ASM glücklicherweise zu inlinen ist, sind (potenziellen) Optimierungen Tür und Tor geöffnet...schaumamal...

  • AutoIt Script und Tablets

    • Andy
    • 3. Juli 2016 um 18:54
    Zitat von s.koni

    hat schon jemand mal ein AutoIt Script auf einem Rechner ausgeführt und diesen dann per Teamviewer gesteuert?

    Ich wüßte nicht, was an einer Teamviewer-Verbindung anders sein sollte, als an jeder anderen RDP-Verbindung.
    Mach ein Fenster auf, in dem die zu steuernde Anwendung laufen soll und probier es aus. Zum Thema "Sicherheit" sehe ich das genau wie du, viel sicherer wird es nicht gehen, da zu keinem Zeitpunkt "deine" Daten auf dem Remote-Rechner ankommen, da werden idr. nur "Bilder" in Form von Desktop-Screenshots übertragen. Tastatur/Maus wird einfach nur "durchgereicht"...
    Weiterhin kannst du per Rechtevergabe genau festlegen, was der User auf deinem "Server" darf und was nicht. Richte dem eine "nackte" Maschine ein, mit genau einem Icon auf dem Desktop, sämtliche Zugriffe außer einem Doppelklick auf das Icon kannst du verbieten.

    Für Android https://play.google.com/store/apps/details?id=com.microsoft.rdc.android&hl=de
    Ich habe selbst nur Windows-Tablets/Phones, da stellt sich die Frage garnicht^^

  • In einem Loop die Mausposition verändern

    • Andy
    • 3. Juli 2016 um 13:47

    Hi,
    du solltest dir zunächst mal Gedanken über deine Terminologie machen, bevor du anfängst Fragen zu stellen, egal um welches Thema es geht...

    Excel wird angefragt, das Script verwendet OpenOffice...zwei völlig verschiedene Paar Schuhe!
    Btw. gibt es u.a. auch eine Openoffice-UDF, welche dein "Mausgeklicker" und die dadurch provozierten "Fehler" reduziert. Um Internetanwendungen zu automatisieren, verwendet man idR. die IE-UDF.

    Du hast jetzt schon ein Script geschrieben nach deiner Methode "Mausgeklicker". Funktioniert das soweit, so gut?
    Wenn ja, klasse! Dann brauchst du ja nur weiterzumachen...
    Sämtliche Anwender hier im Forum, die auch nur halbwegs mit der Materie beschäftigen, benutzen ein gänzlich anderes, und glaub mir, wesentlich stabileres und einfacheres System um das zu machen, was du da versuchst zu tun! Und KEINER würde ernsthaft mit "Mausgeklicker" arbeiten....

    Ich gehe aus Erfahrung davon aus, dass diese Art "Script", welches nichts weiter ist als eine Aufzeichnung von "Mausgeklicker", ziemlich fehleranfällig ist.
    Dieses Script kann nicht verwendet werden, um dir Hilfe zu geben. Wenn eine andere Bildschirmauflösung bzw. Browser verwendet wird, läuft garnichts mehr! Von der nicht vorhandenen Möglichkeit, sinnvoll zu debuggen (Fehler zu lokalisieren und zu beseitigen), völlig abgesehen.
    Hilfe kann man nur geben, wenn ein ausführbares und somit testbares Script zur Verfügung steht!

    Wenn du in der Hilfe unter sämtlichen "Maus"-Befehlen nicht den findest, den du aktuell benötigst, dann können wir dir leider auch nicht helfen, alle Befehle stehen in der Hilfe!

  • AssembleIt2_64 incl. Debugger uvm...

    • Andy
    • 3. Juli 2016 um 02:12
    Zitat von alpines

    Na wie wärs wenn du uns dann ein paar Beispiele mitlieferst mit Standardproblemen und den immensen Zeitgewinn durch ASM-Realisierung?

    Wie wäre es, wenn du hier im Forum (und nicht nur hier, UEZ hat im "blauen" Forum einige Threads dazu am laufen) selbst nachschaust... :D

    Gerade bei extrem aufwendigen Berechnungen in langen Schleifen bspw. Grafikfilter, wird "Zeit gutgemacht".
    Wenn man sein Programm beschleunigen will, ist es zunächst wichtig, festzustellen wo wieviel Zeit verbraucht wird, also profilen.
    Dann den "inner loop" finden und diesen analysieren. Ist dieser durch bspw. eine Compilersprache oder ASM zu beschleunigen, dann los!
    Eukalyptus und auch einige andere hier im Forum haben schon wahre Meisterstücke gezeigt...

    Nichtsdestotrotz ist AutoIt in einigen Bereichen (ich bin mal vorsichtig) "suboptimal" aufgestellt. So werden beim Übergeben von bspw. Pointern "by reference" also bspw. str* , der String zunächst komplett kopiert, und dessen Pointer dann übergeben. Das dauert bei einem 100MB langen String eine knappe Sekunde! Ohne dass nur eine einzige Berechnung durchgeführt wurde....
    Man muss also abwägen, ob es sich lohnt, Zeit in die Entwicklung einer Funktion zu stecken, wenn deren Umgebung schon "bremst".

    In 99% aller Fälle ist AutoIt bei weitem schnell genug, aber ab und zu stellt sich ja schon die Frage nach etwas mehr "wums".
    Übrigens ist mit AssembleIt auch der Weg nach Multithreading/tasking überhaupt nicht weit, denn einfachst-"handcoded" ASM ist threadsicher und die Threadverwaltung ist per AutoIt ein Kinderspiel...

  • AssembleIt2_64 incl. Debugger uvm...

    • Andy
    • 3. Juli 2016 um 01:15

    //UPDATE 04.09.2016 Bugfix in Anzeige XMM-Register 2xDOUBLE
    //UPDATE 26.08.2016
    Debugger jetzt "schöner" mit eigener Schrift (Monospaced) und im Fenster, bitte Anmerkungen hier unten im Text dazu beachten , bitte Rückinfo bzgl. gewünschter Erweiterungen/Bugs.
    Bitte auf verschiedenen BS testen und ggf. Screenshots posten, falls bzgl. Anzeige/Fensterinhalt etwas nicht stimmt.
    Bei den Listviews sollte nur das untere einen waagrechten Scrollbalken haben
    Debugger AssembleIt.jpg

    Hi zusammen,

    seit einiger Zeit geistert die AssembleIt2_64 durchs Forum, hier die aktuelle
    Version 1.08:
    AssembleIt2_64.zip

    Wer noch "alte" Versionen von AssembleIt() benutzt, sollte umsteigen :D

    Der FASM-Assembler ist in Form einer direkt aus dem Speicher (also nicht als Datei beigelegten!) ausgeführten DLL integriert, daher reduziert sich der Overhead der AssembleIt2()-Funktion beim Ausführen auf einige Millisekunden!
    Der ASM-Code wird im AutoIt-Script einfach zwischen die #cs und #ce-Tags geschrieben, es genügt ein einfaches RET, AssembleIt sorgt intern für das Aufräumen des Stack.
    Im ASM-Code können, soweit sinnvoll, auch AutoIt-Variablen als Datenquelle eingesetzt werden. MOV EAX,$AutoItvariable funktioniert, MOV $AutoItvariable,EAX "natürlich" nicht...

    Mit der Funktion _AssembleIt2("retbinary", "asm_Funktion") wird der assemblierte Code zurückgegeben, dieser kann dann per DllCallAddress() aufgerufen werden, wenn es mal "richtig schnell" gehen muss.

    Der Debugger ist noch der "alte", bitte das Debugger-Beispiel testen und anschauen, damit man sehen kann, was damit "geht". Bei jedem Aufruf von _ASMDBG_() im Code wird in Scite die entsprechende Zeile im ASM-Code angesprungen. Es macht also Sinn, beim Debuggen das Debuggerfenster links, und rechts daneben Scite geöffnet zu haben.
    man kann _ASMDBG_() auch mehrere parameter in Form von Registern mitgeben, es wird dann das Programm so lange laufen, bis der Ausdruck TRUE ist.
    Bei _ASMDBG_("$EAX=12345 or $EBX=0xFF00FF") läuft der Code also so lange bis entweder der Registerinhalt von EAX=12345 ist, oder EBX=0xFF00FF. Da während dieser Abfragen der Debugger bei jedem _ASMDBG_() aufgerufen wird, "flackert" dessen GUI und das Programm läuft entsprechend "langsam. Ich würde also nicht EAX von 1e6 runterzählen und mit dieser Methode warten wollen, bis EAX=0 ist....
    Ich habe mittlerweile schon am neuen Debugger angefangen, der wird, so hoffe ich, irgendwann mal fertig und bietet auch neue Features....Anregungen dazu sind gern gesehen!!!

    Bitte die Beispiele testen, vor allem der 64-Bit-Modus sollte nun problemlos laufen. Dort wird, da die FASM-DLL nur im 32-Bit-Modus assemblieren kann, eine Hilfsdatei AssembleIt64_Helper.exe (im 32-Bit-Modus) erstellt, welche das assemblieren übernimmt und den so assemblierten Code ins Script überträgt. Diese Hilfsdatei muss nur ein einziges Mal erstellt werden. Bitte in den 64-Bit-Scripten darauf achten, daß, wie in den Beispielen gezeigt, dieser Prozess auch zusammen mit dem AutoIt-Script beendet wird!

    Macros können nun auch verwendet werden, siehe Beispiele.
    SSE-Befehle sind bis zu SSE4 (nicht 4.2) im Assembler enthalten, AVX fehlt auch ....ich weiß nicht, ob diese jemals als Assembler-DLL integriert werden. Ist imho auch unnötig!
    Wer irgendwelche esoterischen ASM-Befehle benutzen will, welche zzt. nicht unterstützt werden, muss eben, wie die Profis, die OPcodes "hartcodieren" :thumbup:

    Und weil ich es seit 30 Jahren runterbete, hier nochmal: "Mit ca. 10-12 ASM-Befehlen ist JEDES programmiertechnische Problem umzusetzen..."

    Viel Spass damit!

  • Probleme nach M$ Patchday Juni-2016 [GELÖST - doch nicht]

    • Andy
    • 27. Juni 2016 um 17:51

    Dieses Phänomen tritt bei uns in der Firma manchmal auf, da wartest du teilweise 1 Minute auf die Darstellung des Inhalts eines Ordners, andere Sachen gehen wiederum problemlos.
    Serverneustart, am nächsten Tag ist wieder alles paletti...

  • Passwortdatenbank mit automatischem Einloggen?

    • Andy
    • 26. Juni 2016 um 19:54
    Zitat von water

    Wenn Du Verschlüsselungsalgorithmen genauso effektiv programmieren kannst wie die Anbieter von Passwortdatenbanken,

    ...das ist das berühmte Henne/Ei-Problem...
    Keiner bräuchte ein "effektives Programm" wenn die "Verschlüsselungsalgorithmen" (wieviele tausend/hunderttausend? ) wirklich sicher wären. Dann gäbe es eine Handvoll "sicherer" Algorithmen, diese wären ausoptimiert, in alle BS implementiert, fertig, und dasThema gäbe es garnicht!
    "Sicherheit" ist immer nur dann ein Thema, wenn die propagierte Sicherheit garnicht besteht!

    Mir drängt sich da sofort der Vergleich mit Viren/Trojanern auf. Wäre auch kein Thema, wenn nicht Milliarden damit verdient werden würden.
    Krass gesagt, Win95 damals "zugenagelt", gäbe es keine einzige "sicherheitspolitische" Notwendigkeit für ein BS-Update! Und womit verdienen dann hunderttausende von BS-Programmierern ihre Brötchen? DAS ist der Grund für "...um Gottes Willen, du benutzt XP, das ist ja soooo unsicher..., besser auf Win7 / Win10 upgraden, das ist SICHERER!..."
    Da will mir also eine ganze Generation erzählen, daß die Vorgängergeneration 15 Jahre lang "gepennt" hat?! Und deren Fehler nicht wieder bzw. an anderer Stelle wiederholt?! Lächerlich...
    Das schlimmste daran ist, dass die "sicheren" BS von heute zum Großteil aus Kostengründen die (billigen weil bestehenden) Bibliotheken der Vorgängerversion weiterverwenden.
    "Fehler" werden ausschließlich nach Aufforderung gefixt, sichert langfristig tausende von Arbeitsplätzen!


    Ich habe den Großteil meines Lebens mit mechanischer/elektronischer Sicherheitstechnik zugebracht, von Einbruchhemmung über Schusssicherheit bis (nur einige Male) zur Sprengwirkungshemmung. Du hast Recht, die "ultimative" Sicherheit gibt es nicht, aber wenn dein Leben und Eigentum zu schützen ist, dann kommt es darauf an, den effektiven Weg zu nehmen. Bei einigen Leuten ist das keine Preisfrage, bei anderen nach dem dritten bis vierten Einbruch aber auch nicht mehr. Die wollen langfristig ihre Ruhe haben. Viel hilft viel, kostet natürlich auch viel. Wieviel ist dir die Unversehrtheit deines Lebens/Eigentums/Schutz der Persönlichkeit wert?
    Und jetzt stellen wir genau diese Frage in Bezug auf EDV einem weltweit führenden Softwareunternehmen im Bereich "Sicherheit". Können die mir ein Produkt liefern, gern zu einem exorbitant hohen Preis, welches "sicher" ist?! DA liegt der Hase im Pfeffer...
    Und deshalb ist es garnicht verkehrt, wenn man sich selbst Gedanken zu diesem Thema macht.
    Wenn die Implementierung von "Verschlüsselung" per se schon nicht sicher ist, wieso dann überhaupt verschlüsseln? Schmeiß doch die Nadel in den Heuhaufen....und lass die NSA suchen, solange nur du den Magneten in der Tasche hast, bist du "sicher" ;)

  • Bitte dieses Skript testen

    • Andy
    • 26. Juni 2016 um 19:20

    Funktioniert auch bei mir :thumbup:
    Startet mit der maximalen Kapazität der Leitung, also bei mir 6MBit, und fällt dann sukzessive auf 1MBit....aber lädt tapfer down 8)

  • Bitte dieses Skript testen

    • Andy
    • 25. Juni 2016 um 22:56

    Hi,
    bei mir Win7/64 wurden alle 4 Dateien angefangen herunterzuladen.
    ADW-Cleaner bleibt immer mittendrin hängen, DL geht nicht weiter, Fortschrittbalken hängt. Im Debugfenster sind die Dateigrößen angezeigt.
    Adv Syst-Care wird immer heruntergeladen, Fortschrittbalken geht bis auf 100%.

    Dr.WebCureIt wird heruntergeladen, aber es erscheint kein Fortschrittbalken, das Feld bleibt wie am Anfang grau.
    JRT genauso.
    Bei diesen beiden (jrt ist schneller fertig, da kleiner) wird heruntergeladen, das sehe ich anhand der steigenden Bytes im Ordner. Allerdings bleibt der Gesamtfortschrittbalken stehen. Der dateieigene Balken wird nicht angezeigt.
    Klicke ich auf den "Debug"-Button wird auch im Arraydisplay kein "Erfolg" angezeigt. ebenso wenig wie die Dateigrößen.

    Mir ist aufgefallen, daß die Zahlen im Fortschrittbalken "springen", das liegt daran, dass eine Kommastelle ausgegeben wird. Bei Komma null wird aber nur die Zahl vor dem Komma ausgegeben, daher das "springen" der Ziffern.

  • Passwortdatenbank mit automatischem Einloggen?

    • Andy
    • 25. Juni 2016 um 13:16

    Hi,
    zum Thema "Sicherheit" gerade in den letzten 20 Minuten in der aktuellen c´t gelesen: http://www.heise.de/ct/ausgabe/201…it-3243772.html
    - Juhuuu, es wurden ENDLICH, nach nunmehr über 20 Jahren, die seitdem (!!!) unverändert im Windows-Code verwendeten Web-Modul-Funktionen gefixt, die ein Sicherheitsproblem darstellen.... :Face:
    - In der gleichen Ausgabe ein Artikel, in welchem Produkte von weltweit operierenden Alarmanlagenherstellern (!!!) simpelst per Webinterface von außerhalb/innerhalb zu übernehmen sind :Face:
    - Weiterhin geben große (!!!) IT-Firmen an, lieber einen Pool an Bitcoins im 5-stelligen Eurobereich zu bevorraten, um sich im Falle eines Falles von Erpressungstrojanern "freikaufen" zu können. Backups? Viel zu teuer, (offensichtlich teurer jedenfalls als die Zahlungen) und viel zu aufwendig, Zahlung ist bequemer...Kundendaten? Zweitrangig!!! :Face:

    - Erpressungstrojaner 2. Teil, befallen mittlerweile Smart-TV´s... :Face:
    - simpelste Möglichkeiten werden demonstriert, um illegal Zugriff auf DHL Packstationen zu erhalten und dort Pakete abzugreifen :Face:

    Wie gesagt, 20 Minuten Zeitung lesen... ;(

    @Topic
    Wäre früher ein softwaremäßiger Algorithmus wenigstens theoretisch über den Quellcode auf seine "Sicherheit" überprüfbar gewesen ( seit Heartbleed hört man von den Linux-Großfressen "...du kannst bei einem "freien" BS ja den Quellcode einsehen und überprüfen..." glücklicherweise nichts mehr) ist heutzutage nicht einmal DAS möglich.
    "Sicherheit" wird in nicht mehr zu überprüfende Hardware ausgelagert.
    Heutzutage wird kein in Großserie produzierter Chip mehr ohne Backdoor ausgeliefert. Von sämtlichen Prozessorherstellern werden die Backdoors sogar noch mit "Trusted" beworben!
    In US-Waffensysteme darf aus diesem Grund kein im Ausland produzierter Chip verbaut werden, nur die "eigenen", da man die Hersteller im eigenen Land "zwingen" kann, die Backdoors offenzulegen... :rofl:

    Wer heutzutage EDV und "Sicherheit" im Zusammenhang mit der Verwendung externer Funktionen verwendet, demonstriert nachdrücklich, dass er von diesem Thema absolut keine Ahnung hat!

    @TE,
    mal abgesehen von der Bequemlichkeit, mit der die gängigen Tools das Thema bedienen (dein Statement beschreibt das eigentliche Problem sehr deutlich! ),

    Zitat von BlutigerAnfänger

    Ich verliere langsam den Überblick, bei welchem Portal ich oder meine Mitstreiter, sich schon mal angemeldet haben und was für Passwörter vergeben worden sind!

    kommst du nicht umhin, dir Gedanken zu machen und eine Entscheidung zu treffen.
    Vertraust du den externen Werkzeugen bedingungslos und führen diese zu mehr Bequemlichkeit, setze sie ein!
    Möchtest du wenigstens ansatzweise das Gefühl haben, dich selbst um die "Sicherheit" kümmern zu können, überleg dir eine Lösung und setze diese OHNE Hilfe von EDV um!


    Ich habe meine Zugangsdaten für pillepalle direkt im Browser hinterlegt, da kümmere ich mich nicht drum. Wer mein Handy/Laptop/PC klaut, der kann halt mit "meinem" Account bspw. auf auf der Aquarium-Website rumsurfen.
    Sämtliche "wichtigen" Zugangsdaten habe ich "einfachstverschlüsselt" (Brain 2.0 ist trotz hohen Alters noch nicht ganz abgemeldet :rock: ) auf einigen Zettelchen im Portemonnaie aufgeschrieben und die Kopie dazu im Bankschließfach (neben den Festplatten mit den Sicherungskopien). Was dazu führt, dass ich mir nicht mal die Pin für den Geldautomaten merke...

    Hardwarezugang erreiche ich über etwas, dass auf jeder Hardware vorhanden ist, das Typenschild. Aus jedem Typenschild kann ich innerhalb Sekunden (per Brain 2.0) hunderttausende 8-10-stellige mögliche Zugangscodes generieren. Einmal vor ca. 20 Jahren einen einfachen Algorithmus festgelegt, reicht ein Blick aufs Typenschild, und ich habe den passenden Zugangscode für mein Gerät. Ab und zu muss ich 4- oder 5 mal "probieren" je nach "Härte" des Codes, aber letztendlich hat es bisher immer funktioniert.
    Vor einigen Jahren hatte ich bei meiner weit entfernt wohnenden Tante einen Router installiert, der hielt lange durch, wurde durch einen neuen ersetzt, den "alten" hatte mein Bruder abgegriffen, welcher mich nach den Zugangsdaten fragte. Foto von der Rückseite des Geräts zu mir gemailt, 10 Sekunden später hab ich (dank im Brain 2.0 verankertem Algorithmus) eine Handvoll der möglichen Zugangsdaten (Login und Passwort) zurückgemailt. Wie gesagt, ich merke mir grundsätzlich keine Zugangsdaten, "Klartext NEIN DANKE"!
    In der Schule hatte ein Lehrer mal gesagt: " Wissen ist wissen, wo es steht!"
    Wzbw!


    @Lottich,
    Brav! :thumbup:

  • Bestimmte Permutation bestimmen

    • Andy
    • 25. Juni 2016 um 10:33

    So etwas ähnliches hatte ich mir bereits gedacht.
    Du willst eigentlich nichts weiter, als Nodes aus einem "Baum" abknipsen". Allerdings frage ich mich, wieso du in deiner Funktion GetPermutation() exakt die Funktion ArrayPermute() aufdröselst. Nur "rückwärts"...der Index gibt doch genau die zugeordnete Permutation zurück!?
    Dabei sind die Permutationen an sich völlig uninteressant, da jede sowieso mit einem Index angesprochen werden kann (da die Funktion ArrayPermute() diesen Index vorgibt)
    Somit erübrigte sich auch deine Array-"Rückwärtsberechnung".

    getPermutation($aArray, $v) berechnet extremst aufwendig die Permutation aus einem Index, die du doch sowieso schon berechnet hast bei $Permutation_orginal[$v] ( Local $permutation_orginal = _ArrayPermute($aArray, ""))

    Es stellt sich die Frage, was dir deine Funktion GetPermutation() bringt, außer zum gegebenen Index eine Permutation zurückzugeben...was wie gesagt über den Index sowieso schon erfolgt. ?(


    Sollte bei der Berechnung eine "schlechte Lösung" gefunden werden, bringt es nichts, den dazugehörigen Index zu wissen. Das hatte ich oben schon beschrieben. Elementar ist die Funktion, diese Indizes auszuwerten / zu bewerten. Mal "rechnerisch" gesprochen, deine "schlechte Lösung" wird gefunden, dann MUSS über den Index eindeutig sein, ob die Berechnung der nächsten Permutation überhaupt begonnen wird!
    Die Aussagen "Verwerfe alle Indizes zwischen 49 und 54" und "Verwerfe alle (weiteren) Permutationen, welche mit "cb" beginnen" decken sich! Das eigentliche "Problem", WIE diese Permutationen "abzuknipsen" sind, ist damit nicht gelöst! Natürlich könnte man, wie in deinem Beispiel oben gezeigt, per _Arraydelete() die schlechten (in deinem Fall schon berechneten Lösungen) entfernen. Das mag für die Handvoll Permutationen abcde noch mit Bruteforce möglich sein, bei 8! (abcdefgh) dauert das _ArrayDelete() einer einzigen schlechten Lösung" länger als sämtliche anderen Berechnungen!
    (schau mal HIER, da habe ich die rekursive Fakultät-Funktion gefunden, das ist 6 1/2 Jahre her^^)

    AutoIt
    #include <Array.au3>
    $perm = "abcde"
    Local $aArray = StringSplit($perm, "", 2)
    _ArrayDisplay($aArray)
    Local $permutation = _ArrayPermute($aArray, "")
    $permutation_orginal = $permutation    ;array sichern
    _ArrayDisplay($permutation)
    $perms = fakul(StringLen($perm))
    $counter = 0
    While UBound($permutation) > 1   ; prüft, ob alle Permutationen aus _ArrayPermute auch durch meine Methode abgedeckt sind
        ConsoleWrite("  " & $counter & " von " & $perms & " Permutationen berechnet: " & getPermutation($aArray, $counter) & "      aus Index orginal: " & $permutation_orginal[$counter+1] & @CRLF)
        $index = _ArraySearch($permutation, getPermutation($aArray, $counter))
        If $index <> -1 Then
            _ArrayDelete($permutation, $index)
        Else
            MsgBox(0, "ERROR!", getPermutation($aArray, $counter))
            Exit
        EndIf
        $counter += 1
    WEnd                             ; terminiert, da meine Methode zu funktionieren scheint
    Func getPermutation2($aArray, $v) ;????????
        Return $aArray[$v]
    EndFunc                          ;==>getPermutation2
    Func getPermutation($aArray, $v)
        Local $permutation = ""
        Local $a = $aArray
        Local $length = UBound($aArray)
        Local $i[$length - 1]
        For $l = $length To 2 Step -1
            Local $s = faculty($l) / $l
            $i[$length - $l] = Int($v / $s)
            $v -= $i[$length - $l] * $s
            $permutation &= $a[$i[$length - $l]]
            Local $b[UBound($a) - 1]
            Local $c = 0
            For $j = 0 To UBound($a) - 1
                If $j == $i[$length - $l] Then
                    ContinueLoop
                Else
                    $b[$c] = $a[$j]
                    $c += 1
                EndIf
            Next
            $a = $b
        Next
        $permutation &= $a[0]
        Return $permutation
    EndFunc                          ;==>getPermutation
    Func faculty($n)
        Local $w = 1
        For $i = 2 To $n
            $w *= $i
        Next
        Return $w
    EndFunc                          ;==>faculty
    Func fakul($n)
        If ($n == 0 Or $n == 1) Then Return 1 ;
        Return $n * fakul($n - 1)    ;
    EndFunc                          ;==>fakul
    Alles anzeigen

    Um zu demonstrieren, was allein bei 8 statt 5 Pfaden rechentechnisch vor sich geht, ersetze "abcde" mit " abcdefgh"

    Es ist definitiv wesentlich einfacher und vor allem schneller, die "schlechten Lösungen" im Orginal-Array entsprechend zu markieren als diese Lösungen komplett aus dem Array zu löschen.
    Ein $permutation_orginal[zu_löschender_index]="" macht diesen Job!

  • Bestimmte Permutation bestimmen

    • Andy
    • 24. Juni 2016 um 17:13
    Zitat von XovoxKingdom

    Ich will eine Funktion, die mir eine Permutation in Abhängigkeit des übergebenen Parameters gibt.

    Aber genau DAS meinte ich doch...
    $array=_ArrayPermuteXXX("abcde","01020") , gibt dir Permutationen zurück, die "ace" an den ersten 3 Stellen verwenden ("gute Lösungen"), b und d kommen IMMer hinten an!


    Zitat von XovoxKingdom

    Sollte ein Node 'merken', dass seine Permutationen nicht zu einer (guten) Lösung führen,

    Programmiertechnischer "Dünnschiss"! :D
    Wenn der Node etwas "merkt" , ist es schon passiert! Denn die "schlechte Lösung" wurde bereits berechnet! ALLE anderen Nodes haben das gleiche Problem! Dann könntest du gleich random durch die Permutationen fliegen und "hoffen", dass möglichst schnell eine "gute" Lösung gefunden wird.
    Was allerdings funktionieren würde wäre eine von allen Nodes erstellte Liste der "schlechten" Lösungen. Über diese Liste lässt man eine "Sortierfunktion" (ich vermute, dass du so etwas suchst) laufen, welche die "schlechteste" Permutation nach vorne holt.
    Nehmen wir an, die Nodes sind "dumm" und fangen an zu rechnen...eine "schlechte" Lösung wird gefunden mit b an der dritten Stelle. Dann wären automatisch ALLE Prermutationen mit b an der dritten Stelle auch "schlecht" (nehme ich an)!? Diese Info wird in die "schlechte" Liste geschrieben ("b3" b an der 3. Stelle ist schlecht)
    Jeder der "dummen" Nodes holt sich die nächste verfügbare Permutation bspw. "caedb" und schaut dann in die Liste..."b3", "c4", "a4"...ok, diese Permutation hat keinen Malus, also berechnen. Bei "cbdae" trifft "a4" und der Node verwirft diese Permutation und holt die nächste verfügbare, bspw. "bcead", rechnet und findet bei "d" eine "schlechte" Lösung. Dann wird der Liste "d5" hinzugefügt....

    Jetzt ist es nur noch eine Frage der aufwendigen Berechnung der Lösungen, ob man über eine wie oben beschriebene Liste die "schlechten" Lösungen ausmaskiert, oder sporadisch ALLE Permutationen durchläuft und die "schlechten" entfernt (wird sich rechentechnisch sicher nicht lohnen).
    Ich vermute mal, die Datenbankspezis könnten hier ein As aus dem Ärmel ziehen und genau diese Permutationen "löschen". Die letztendlich in der DB übriggebliebenen Lösungen wären somit "nicht schlecht".


    Btw. hatte ich vor vielen vielen Jahren mit einem ähnlichen Problem zu tun. Da wurden Fernseher (natürlich mit Röhre! ) produziert und das Bild musste vor der Verpackung des Geräts kalibriert werden. Auf der Platine waren ca. 10 Trimpotis, die alle in irgendeiner Art und Weise Einfluß auf die Bildqualität hatten, und natürlich waren alle Einstellungen voneinander abhängig. "Von Hand" war die Kalibrierung niemals in der Taktzeit (ca. 30 Sekunden) zu schaffen. Also wurde folgendes gemacht: eine Platte mit 10 an Elektromotoren befestigten Schrauberspitzen wurde an die Platine gefahren, und die Elektromotoren fuhren in einer ZUFÄLLIGEN Geschwindigkeit den Einstellbereich des Trimpotis ab. Wie gesagt, jeder Motor hat seinen Trimpoti einfach im gesamten Bereich mehrmals hin und herbewegt. Vor dem Bildschirm saß ein Mitarbeiter mit einem Handtaster und hat das Bild beobachtet. Wenn diese Person nun meinte, das Bild ist "gut", wurde der Handtaster betätigt und der Kalibriervorgang war beendet...nächster Fernseher....der aufmerksame Beobachter wird jetzt fragen was passiert, wenn der "gute" Zustand vom Mitarbeiter nicht erwischt wurde und/oder die Zeit ablief...dann wurde der Bildschirm mit einer SCH*** Bildqualität verpackt.... :D
    Da damals in Barcelona im Werk 24h-Schichten gefahren wurde, kann sich jeder ausrechnen, wieviele LKW mit Fernsehern von dort nach ganz Europa verfrachtet wurden...da kam es auf die Handvoll "Ausschuß" nicht an, denn genau damit haben dann Generationen von sog. "Radio- und Fernsehtechnikern" ihr Brot verdient!

    Was hat jetzt die "Fernseherkalibrierung" mit o.g. Problem, die "beste Lösung" zu finden, zu tun?! Wer DAS begriffen hat, verkürzt die Berechnungszeit auf wenige Prozent/Promille der Berechnungen aller Permutationen!

  • ImageSearch - Problem auf unterschiedlichen Displays.

    • Andy
    • 23. Juni 2016 um 19:04
    Zitat von autoiter

    Natürlich geht das. Aber ja, es ist am Ende des Tages Pfusch.

    Zitat von autoiter

    Wir haben das auch mehrfach angesprochen. Aber der Kunde möchte das im Kontext der Terminal Server Session nicht zulassen.

    wzbw... :Face:

    Genau DAS ist das Problem mit den Kunden.....

  • Bestimmte Permutation bestimmen

    • Andy
    • 23. Juni 2016 um 13:36

    Hi,
    ich würde nicht nach dem Permute auswerten, sondern schon vorher...
    Schreibe die _ArrayPermute() so um, daß du den einzelnen Symbolen ein "Gewicht" mitgeben kannst, dann wird ArrayPermute nach diesen Gewichten sortieren. Standard wäre bspw "00000"
    Somit hast du, wenn bspw. b schlecht aber e noch schlechter gewichtet wäre (also "01002"), die Permutationen so sortiert, daß die Permutationen von acd "vorne" mit be "hinten" stehen und letztendlich beacd , dann als "schlechtestes" ebacd...
    Was dazu führt, daß du keinerlei Algorithmus benötigst, da die "guten" Permutationen immer vorne, und die schlechten zwangsläufig immer hinten in der Liste stehen.
    Fällt eins oder mehrere Symbole komplett raus, löschst du es aus der Liste komplett.
    Nebenbei kannst du noch eine "Gesamtgewicht"-Funktion mitlaufen lassen, die dir für jede der Permutationen ein "Gesamtgewicht" mitliefert.
    Dann fallen alle Lösungen, welche ein definiertes "Gesamtgewicht" überschreiten, komplett weg!

  • ImageSearch - Problem auf unterschiedlichen Displays.

    • Andy
    • 23. Juni 2016 um 13:09

    Hi,
    wie wertest du die Bildschirmbreite- und Höhe auf den unterschiedlichen Displays aus?
    Probier mal
    $VirtualDesktopWidth = DllCall($hDLL_User32, "int", "GetSystemMetrics", "int", 78) ;sm_virtualwidth
    und 79 für die Höhe.

  • buttonbeschrfitung über 2 zeilen

    • Andy
    • 19. Juni 2016 um 10:01
    Zitat von water

    Du meinst die Suchfunktion zu verwenden

    auch die Suche in der Hilfe muss bedient werden können um passende Ergebnisse zu generieren ;)

    Wobei man in diesem Fall nicht mal suchen muss, in der Beschreibung der Parameter ist auf die Styles verlinkt.

  • Foren-Suchfunktion

    • Andy
    • 15. Juni 2016 um 07:08

    Wer die Foren-Suchfunktionen nutzt, ist selbst schuld! Unzulänglich programmiert und nur halbherzig implementiert findet die Suche meist nicht das gewünschte Ergebnis. Das gilt für 95% aller mir bekannten Forensoftware!
    Daher benutze ich seit vielen Jahren in Foren, deren Beiträge von den Google-Crawlern erfasst werden...Google.
    Ja, auch 95% der Internet-Nutzer haben keinerlei Ahnung, wie man mit Google RICHTIG sucht! Und diese Zahl ist eher zu niedrig gegriffen.
    Gleiches gilt übrigens für Ersteller von Startposts, da sind auch nur eine Handvoll in der Lage, ihr Problem so zu schildern, dass man ohne weitere Nachfragerei eine Lösung präsentieren kann...

    Ich benutze zur Google-Suche mein Programm ErGo Erweiterte Googlesuche, gibts hier im Forum.
    Ansonsten kann man auch "zu Fuß" im AutoIt-Forum (und in jedem anderen Forum/Website) googeln, bspw. "Suchbegriff(e) site:autoit.de"
    Google bietet haufenweise Tricks um Suchen/Ergebnisse clever einzuschränken, aber wie gesagt, wer nicht mal richtig suchen kann (will! ), der braucht auch keine "guten" Ergebnisse!

  • Wert aus Array bekommen

    • Andy
    • 14. Juni 2016 um 06:55
    Zitat von Lanealine

    warum funktioniert das nicht ? :
    $variable = $aTest[5][2]

    WEIL DU EINEN FEHLER IN DEINEM SCRIPT HAST, DEN WIR ABER NICHT NACHVOLLZIEHEN KÖNNEN, WEIL DU DEIN SCRIPT NICHT GEPOSTET HAST!

    Zitat von Lanealine

    danke

    Bitte!

  • Aller Anfang scheint schwer

    • Andy
    • 13. Juni 2016 um 06:43

    ....oder so:
    Deutsche Hilfe installieren

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™