Beiträge von UEZ

Zitat von sc4ry

Fehler lag an mir.

Also speedtechnisch:

1. Lauf 66694ms
2. Lauf 9904
3. Lauf 9324

Also ich muss sagen, beim ersten Lauf ist das Teil wesentlich langsamer als bei der 1. Version ... danach ist der Wert gut

Das Betriebssystem "cached" Dateien und deshalb ist der 1. Lauf eigentlich der tatsächlich relevante Wert! Nach jedem Durchlauf müsste man den Rechner durchstarten und neu messen, damit die Ergebnisse nicht verfälscht werden!
Darum werden auch HD Benchmarks auf Hardwareebene programmiert, damit die Ergebnisse durch das Cachen nicht beinflusst werden!

Gruß,
UEZ

Ihr habt mich überzeugt, dass die Rekusion von den Fibonacci nicht mit AutoIt, sondern wirklich mit der Rekursionstiefe und somit mit der Anzahl der Berechnungen zu tun hat!

@AspinirinJunkie: ich habe deine berechtigte Kritik nicht als Angriff angesehen! Ich dachte nur, dass der Unterschied nicht so krass sein würde! Ich habe mir den Rekursionsbaum für n=3 angeschaut, aber daraus lässt sich nicht klar absehen, dass die Berechnungen exponentiell zunehmen!

Jeder sollte Kritik nicht als Angriff ansehen, sondern eher als eine konstruktive Diskussionsgrundlage!

DANKE,
UEZ

Zitat

Das ist mathematisch begründet und nicht informationstechnisch.

Da gebe ich dir nur teilweise recht!

Zitat

Du hast dir zwar ein schönes Beispiel herausgesucht aber es taugt nicht für einen allgemeingültigen Vergleich zwischen Rekursion und Iteration.

Hast du ein besseres Beispiel? Wenn ja, dann bin ich sehr gespannt darauf!

Zitat

Bei der Fibonacci-Folge baut jede Fibonacci-Zahl auf "niedrigeren" Fibonacci-Zahlen auf.
Bei der Rekursion werden diese "niedrigeren" Fibonacci-Zahlen für jede Fibonacci-Zahl neu berechnet und damit mehrmals berechnet.
Bei deiner iterativen Variante werden die letzen Fibonacci-Zahlen gepspeichert und für die Berechnung folgender Fibonacci-Zahlen mehrmals verwendet - eine Fibonacci-Zahl wird also nur einmal berechnet - im Gegensatz zur Rekursion.

Und deswegen liegt die Laufzeit so weit auseinander? Eine Verdoppelung würde ich ja noch akzeptieren.

Zitat

Da ist der exponentielle Anstieg im Vergleich zu dieser iterativen Methode nur logisch - aber er ist rein mathematisch begründet - auch in reinem Assembler gegossen würdest du diesen Anstieg feststellen.

Das es einen Unterschied zwischen Rekursion und Interation gibt, da Rekusion mehr Berechnungen hat, ist mit schon klar, aber das der Unterschied so gewaltig ist, ist mir ein Rätsel. Liegt sehr wahrscheinlich an AutoIt und dessen internen Strukturen.

Ich werde demnächst mal das Beispiel in C++ coden und messen, ob dort der Unterschied so groß ist.

Gruß,
UEZ

Vielleicht so was:

Gruß,
UEZ

Ersetze die Funktion WM_DROPFILES_FUNC mit dieser:

Gruß,
UEZ

Mit GUIRegisterMsg vielleicht?

Hier ein Beispiel, das ein Farbverlauf erstellt (ist nicht die beste Methode) und das Fenster entsprechend neu zeichnet:

Die Funktion MY_PAINT() zeichnet das Fenster neu!

Meinst du das?

Gruß,
UEZ

Ich habe noch 3 weitere C++ Source Codes in meinem 1. Post hinzugefügt. Wenn die C++ Gurus mal reinschauen könnten!

Leider finde ich zu libsidplay2.dll keine Anleitung, wie ich diese DLL benutzen kann!

Danke,
UEZ

Zitat von PokerFace

Oh mein Gott.
Bei UEZ Skript sieht das richtig schön schwer aus^^
Hinter die Logik steig ich komischerweise nicht.
Wie sagt man denn zum Beispiel seiner Figur, das die sich nach oben bewegen soll?

Ich würde mir Mario von eukalyptus anschauen! Dort sind die Jump 'n' Run Elemente implementiert, genau wie du willst

AUTOITEROIDS ist im Prinzip nicht sehr GDI+ lastig, denn es werden ja "nur" Striche gezogen! Schwerer war da das gesamte Handling des Spiels, wie Kollision (simple Version), Berechnungen, etc.

Ansonsten würde ich mir die GDI+ Beispiele in den Foren anschauen und lernen, denn er gibt kein Tutorial dazu!

Gruß,
UEZ

Hier mein Vorschlag:

Gruß,
UEZ

#include <BigNum.au3>

$m = 72
$c = _BigNum_Pow($m, 7)
$c = _BigNum_Mod($c, 187)

MsgBox(0,"",$c)

$m = _BigNum_Pow($c, 23)
$m = _BigNum_Mod($m, 187)

MsgBox(0, "" ,$m)

Gruß,
UEZ

Zitat von chip

Hi,

kann es sein das Autoit falsch Rechnet bzw. irgendwie rundet?

Habe folgendes Script:

Spoiler anzeigen

[autoit]

$m = 72
$c = $m^7
$c = Mod($c,187)

[/autoit] [autoit][/autoit] [autoit]

MsgBox(0,"",$c)

[/autoit] [autoit][/autoit] [autoit]

$m = $c^23
$m = Mod($m,187)

[/autoit] [autoit][/autoit] [autoit]

MsgBox(0,"",$m)

[/autoit]

Bis zur Zeile "$m = Mod($m,187)" stimmt noch alles, aber hier gibt es statt 72 den Wert 34 aus.

Alles anzeigen

AutoIt kann 30^23=9,4143178827e+33 (0xB708F35A37800000) intern (64-bit signed) nicht mehr richtig darstellen.

63 bits werden für die positiven Zahlen (0x7FFFFFFFFFFFFFFF) benötigt und das 64. bit für die negativen Zahlen!

Mod(9223372036854775807, 187) sollte noch gehen und Mod(9223372036854775808, 187) nicht mehr!

UEZ

Hier, was mir so ad hoc eingefallen ist:

;coded by UEZ
#include <ScreenCapture.au3>

$title = "Unbenannt - Editor" ;Beispiel mit Notepad
$list = WinList() ;liste alle Fenster
If $list[0][0] > 0 Then ;wenn Liste nicht leer, dann weiter
$i = 1
Do
If StringInStr($list[$i][0], $title) > 0 Then ;finde erstes Notepad Fenster
$hWnd = $list[$i][1] ;merke Handel vom Fenster
WinSetState($hWnd, "", @SW_RESTORE) ;stelle wieder das Notepad Fenster her, da minimiert der Screenshot sonst schwarz wäre
Sleep(250) ;warte auf das Notepad Fenster
_ScreenCapture_CaptureWnd(@ScriptDir & "\notepad.jpg", $hWnd) ;mache ein Foto und speichere das Bild ab
WinSetState($hWnd, "", @SW_MINIMIZE) ;minimiere das Fenster wieder
ExitLoop ;verlasse Schleife
EndIf
$i += 1
Until $i >= $list[0][0] ;suche solange bis alle Fenster durchsucht sind!
EndIf
Exit

Vorher Notepad starten und minimieren (Simulation).

Gruß,
UEZ

Klappt das denn:

$exe = "test15.exe"
$pid = ProcessExists("test15.exe")
If $pid Then
$wl = WinList()
$handle = 0
$i = 0
Do
If StringInStr($wl[$i][0], $exe) > 0 Then
$handle = $wl[$i][1]
WinActivate($handle)
WinWaitActive($handle)
Sleep(100)
StdinWrite($pid, "{ESC}")
ExitLoop
EndIf
$i += 1
Until $i = $wl[0][0]
EndIf
Exit

Wobei du für test15.exe deine Anwendung eintragen musst!

Gruß,
UEZ

Sorry, meine du musst die Prozesse nach der Webcam exe durchsuchen (Doppeltklick auf die einzelnen Prozesse)!

UEZ

Ein Doppeltklick auf Webcam.exe in procexp.exe sollte mehr Infos liefern!

UEZ

Probiere mal die Tools aus der Sysinternals Suite , z.B. Tcpview.exe, procexp.exe, autoruns.exe, etc.

Die geben wesentlich mehr Infos als die Boardtools von MS!

Gruß,
UEZ

Scheint an der AutoIt3Help.exe zu liegen!

Wenn man die ältere Version, z.B. aus AutoIt v3.3.2.0 benutzt, funktioniert der Button wieder wie gehabt!

Im Anhang die ältere Version!

Gruß,
UEZ

PS: wird auch als Child Process gestartet (macht ja Sinn)
PSS: schein ein Bug zu sein und es wird ein Bug Report erstellt!

Gruß,
UEZ

Mmhh, das Problem habe ich auch auf meinem priv. Notebook unter Vista x32!

AutoIt3Help.exe wird von SciTE.exe als Child Process geöffnet und "Open this script" funktioniert nicht. Wenn aber AutoIt3Help.exe vor SciTE.exe geöffnet wird, geht's (AutoIt3Help.exe ist kein Child Process von SciTE.exe)!

Muss jetzt zum Elternabend!

UEZ

Du kannst z.B. mit Bass.dll respektive Bass.au3 ID3 Tags auslesen. Schaue mal hier rein: http://www.autoitscript.com/forum/index.php?showtopic=83481&view=findpost&p=756437

Gruß,
UEZ

Zitat von peethebee

Grundsätzlich mal ja.
Funktionsaufrufe sind teuer, weil man Variablen sichern muss beim Aufruf und bei der Rückkehr. Außerdem muss man die Funktion in der Funktionstabelle nachschlagen und dahin springen. Das ist natürlich relativ umso teurer, je weniger Code pro Iteration/Funktionsaufruf abgearbeitet wird :).
Die Stärke des Effekts kann natürlich variieren.
Zudem kann mancher Compiler (einfache) Rekursionen in Iterationen umbauen.

Johannes

Da stimme ich dir vollkommen zu, aber ist der Unterschied so krass wie in AutoIt? In meinem Beispiel wächst der Unterschied exponential mit n!

Gruß,
UEZ