Beiträge von BugFix

Ich fasse mal zusammen:
- ihr habt einen ISDN-Anschluß (standardmäßig mit 3 Rufnummern)
- eure Anlage ist eine Eumex 308
- an der Anlage können sowohl ISDN- als auch Analogtelefone angeschlossen werden

In der jetzigen Konfiguration ist die dritte Rufnummer noch nicht zugeordnet. Das kannst du aber in der Software selbst tun. Die Software lag der Anlage bei (hoffe, du hast sie noch). Bei anderen Anlagen kann man auch die Konfiguration mittels Ziffernkombinationen über das Telefon einstellen. Ob das hierbei auch möglich ist, mußt du mal im Handbuch nachlesen.

Edit: Die Software gibt es hier. Allerdings DOS! - Kein Wunder, die Eumex wurde nur bis 1998 gebaut.

Hä ? Morzilla
Das muß Mozilla heißen!

Zitat von Schnuffel

Na ja, aber die "nächste größte Primzahl" kann man nach der Methode nicht errechnen.

Nein, aber dafür braucht man dann eine Ausgangszahl. Die Funktion dafür ist bei mir "nebenbei" abgefallen :). _GetNearestPrime() ermittelt die nächsthöhere/ -kleinere Primzahl zur eingegebenen Zahl.

...den richtigen Fensternamen verwenden..

"Google - Morzilla Firefox"

Zitat von Schnuffel

also ich finde, dass Euer Lösungsweg mit der For-Schleife bis 1299709 eigentlich Beschiss ist.

Tja, genau da liegt aber der Hund begraben. Jeder schnelle Algoritmus benötigt irgendeine Obergrenze zum Rechnen. Wenn ich einfach nur fortlaufend rechne: _IsPrime(Zahl) - Next, so funktioniert das zwar, ist wie du selbst siehst aber schneckenlahm.
Und was ist Beschiss, wenn du weißt, dass bis 1299709 genau 100.000 Primzahlen vorkommen? Um Chancengleichheit zu wahren, habe ich ja diese Information gegeben.. :wacko:

Hi,
ich hab mir eine Testumgebung erstellt, in der ich meine Algorithmen zum Primzahlbattle teste (nicht wundern, wegen der Zeiten: 1,5 GHz).
Dabei ist mir etwas seltsames aufgefallen:
- die Laufzeitabweichungen sind bei einem Skript max. 14%, beim anderen bis zu 25% !!
- führe ich die Skripts in einer Schleife immer abwechselnd aus ist die Abweichung am gerinsten
- wiederholte Ausführung eines Skriptes führt zu den stärksten Abweichungen

[01] 6.614 | 7.059	[02] 7.024 | 7.054	[03] 7.264 | 6.960
[04] 7.340 | 6.985	[05] 7.780 | 6.983	[06] 7.293 | 6.973
[07] 7.610 | 7.071	[08] 7.418 | 7.076	[09] 7.599 | 7.083
[10] 7.551 | 6.966


=== Algorithmus 1 ===
Min: 	6.614	- vom Mittel: 90%
Max: 	7.780	- vom Mittel: 105.86%	- vom Min: 117.63%
Mittel: 7.349


=== Algorithmus 2 ===
Min: 	6.960	- vom Mittel: 99.13%
Max: 	7.083	- vom Mittel: 100.88%	- vom Min: 101.77%
Mittel: 7.021




=============== Lauftest nur Algo 1:


[01] 6.742 | 0.000	[02] 7.846 | 0.000	[03] 7.876 | 0.000
[04] 8.108 | 0.000	[05] 8.236 | 0.000	[06] 8.108 | 0.000
[07] 8.256 | 0.000	[08] 8.103 | 0.000	[09] 8.009 | 0.000
[10] 8.385 | 0.000


=== Algorithmus 1 ===
Min: 	6.742	- vom Mittel: 84.62%
Max: 	8.385	- vom Mittel: 105.25%	- vom Min: 124.37%
Mittel: 7.967




=============== Lauftest nur Algo 2:


[01] 0.000 | 7.181	[02] 0.000 | 7.856	[03] 0.000 | 6.849
[04] 0.000 | 6.907	[05] 0.000 | 6.875	[06] 0.000 | 7.150
[07] 0.000 | 6.974	[08] 0.000 | 6.891	[09] 0.000 | 6.927
[10] 0.000 | 6.899


=== Algorithmus 2 ===
Min: 	6.849	- vom Mittel: 97.14%
Max: 	7.856	- vom Mittel: 111.42%	- vom Min: 114.7%
Mittel: 7.051

Vielleicht könnt ihr ja mal testen, wie das bei euch aussieht - beliebige Funktionen in die Testumgebung einsetzen und los. Vielleicht ist es ja auch nur bei meinem Schlepptop so. :wacko:
Die verwendeten Funktionen verwenden übrigens ausschließlich lokale Variablen.

Zitat von oetzn

Solche Skripte sind genau genommen auch Bots, und in solch einem Fall versteh ich nicht wie jemand komplett gegen Bots sein kann, da er ja hier nicht zwischen Gamebots und anderen unterscheidet!

Nur ein Kommentar von mir und dann denke ich, das Thema sollte endgültig durch sein.
Im Sprachgebrauch unseres Forums wird als Bot bezeichnet, was zur Vorteilsnahme führt oder sonstwie gegen Regeln verstößt. Punkt.
Grundsätzliche stellt jede Form der Automatisierung einen 'Bot' dar - aber wie will man dann differenzieren? Deshalb die Definition, wie eben angeführt.
Wenn also im Forum jemand sagt, er sei gegen Bots, dann ist genau diese von uns verabscheute Form der Automatisierung gemeint.
Genau das ist auch aus der überwiegenden Mehrzahl der Posts hier herauszulesen.

- Die Meinung der Forumsbetreiber steht unverrückbar fest.
- Die Mehrzahl der User geht damit konform.
Somit erübrigt sich für jetzt und alle Zeiten jede weitere Diskussion dazu.

Ich schließe damit diesen Thread und werde evtl. nochmals auftauchende Diskussionsversuche kommentarlos abwürgen.

[CLOSED]

Zitat von Schnuffel

Da könnte ich ja die 5 und die 7 und die .... auch noch als gegebenen annehmen.

Wenn du einen Algorithmus hast, der dadurch arbeitet, dass er genau das voraussetzt - warum nicht.
Allerdings ist mir grad kein Algo bekannt, der das tut. 2 und 3 - ja, aber 5, 7... etc. sind durch die Operationen mit 2 und 3 abgedeckt.
Lassen wir uns mal überraschen.

Zitat

Dürfen die ersten Zahlen ohne Berechnungen als Primzahlen angenommen werden? 2, 3 vieeleicht noch 5?

Wenn der Algorithmus darauf aufbaut, dass 2 und 3 Primzahlen sind, sind diese natürlich nicht berechenbar und sollten als gegeben betrachtet werden. Oder seht ihr das anders?

Kleiner Tipp: Niemals die GlobalProperties editieren. Ist eh alles wieder weg bei der nächsten SciTE-Version. Schreib deine Änderungen in die UserProperties, die Einträge werden vorrangig behandelt und bleiben, wenn ich nicht irre, auch nach SciTE-Update erhalten.

Zitat von L3viathan2142

die ersten 100000 Primzahlen, nicht die Primzahlen unter 100000.
Keine Obergrenze darf gegeben sein, auch nicht per sqlite.
Reihenfolge ist egal.

Mit dieser (sehr seltsamen) Festlegung hast du schwupp-di-wupp alle ernsthaften Teilnehmer aus dem Wettbewerb gestrichen.
Zeig mir einen schnellen Algorithmus, der ohne Obergrenze funktioniert!
Das war ja der Grund, warum ich die Obergrenze (1.299.710) zum Ermitteln von 100.000 Primzahlen angegeben habe.

Auch von mir Alles Gute eukalyptus.

Nasch nicht zu viel vom Eukalyptus-Likör, das könnte arg enden.

Damit mal klar wird, was ich meinte:
Ein Schreibzugriff ist von soviel Begleitfaktoren abhängig, dass er niemals eine zeitgleiche Größe liefert.
Somit muss die Zeitmessung vor dem Schreiben in die Datei stattfinden.
Dazu könnte man die TimerInit-Variable ByRef übergeben:

; === Testumgebung
Local $timer = TimerInit()

Func _GetPrim(ByRef $timer)
; ...
; ...
ConsoleWrite(TimerDiff($timer) & @CRLF)
FileWrite($file, $100000_Primzahlen)
EndFunc

Zitat von Jonathan

chip: Interessiert mich auch... kommt fileopen / close mit in den timerbereich?

Sollte definitiv außen vorbleiben, sonst läßt sich kein ernsthafter Vergleich erstellen. HD-Zugriffe sind niemals gleichmäßig.
Am Besten: Funktion gibt trennzeichenbasierten String oder Array mit allen Zahlen zurück. Dann wird Zeit gemessen und wenn man will kann man das anschließend in eine Datei schreiben.

Mal als kleine Hilfe:
Um 100.000 Primzahlen zu ermitteln muß man die Zahlen bis 1.299.710 untersuchen.

Jawoll L3viathan2142!
Wobei ich vorschlagen würde, die ersten 100.000 zu ermitteln, da 10.000 so schnell gehen, dass der Rechenalgorithmus den geringsten Anteil am Skript hat.
(für 100.000 brauch ich knapp 7 sec., für 10.000 unter 1 sec.)

Ich gehe mal stark davon aus, dass all jene die der Meinung sind, dass man einfach x Minuten ermittelt und dann einen vergleichbaren Wert an Primzahlen hat, sich bisher nicht mit der praktischen Umsetzung beschäftigt haben (auf jeden Fall nicht mit effektiven Algorithmen).
Daher sollten wir den von Pee vorgeschlagenen Weg gehen.
Alles andere ist Makulatur.

Zitat von L3viathan2142

Wenn ein Skript in 5 Jahren 100 Primzahlen ermittelt, und ein anderes in 5 Minuten 10, dann ist zweiteres der Sieger.

Welche 100, oder welche 10? - Die ersten, die letzten bisher bekannten?
Diese Aussagen sind alle zu verwaschen und deshalb als Maßstab in einem Wettbewerb nicht geeignet.
Die Suche nach Primzahlen wird schwieriger und langwieriger, je größer der Zahlenbereich ist, indem man sich befindet. Ich denke darüber sind wir uns einig.
Das es wenig Sinn macht, dass wir hier "neue" Primzahlen ermitteln sollte auch klar sein (Bei der letzten "neuen" ist wohl der entsprechende Rechner ca. 3 Jahre gelaufen hab ich mal gelesen).
Also müssen wir uns einen Rahmen schaffen, indem wir arbeiten. Und Zeit ist kein Rahmen sondern ein Ergebnis. Zumal die Zeitsituation zusehr von der verwendeten Hardware abhängt.

Zitat von MatthiasG.

Wer die höchste Primzahl bei der besten Geschwindigkeit finden kann, hat gewonnen.

Das geht nicht. Um vergleichbare Kriterien zu bekommen, mußt du zum Bsp. einen Zahlenbereich vorgeben, aus dem die größte Primzahl ermittelt werden soll.
Denn es gibt nunmal keine größte Primzahl und wenn ich mit einem Skript nach 5 Jahren Laufzeit eine bisher nicht bekannte Primzahl ermittle, habe ich dann gewonnen, obwohl jemand eine kleinere in 5 Sekunden ermittelt?
Du siehst, eine Obergrenze ist unumgänglich.

Edit:
So, meine Version steht.
Als kleiner Meßwert:
Für die größte Primzahl bis 1.000.000.000 brauch ich auf meinem Laptop (1,5 GHz; 448 MB RAM) genau 1,11 Sekunden.

Hi,
manchmal braucht man die Info, die hinter einem Makro steckt (z.B. Pfade für FileInstall, da dort keine Makros verwendet werden können).
Man kann natürlich mit "ConsoleWrite(@MACRO & @CRLF)" sich das ganze ausgeben lassen. Ich habe es aber mal in einer kleinen GUI zusammengefasst als praktische Anwendung für IntelliSenseBox.
Einfach das Makro in das untere Input schreiben, oben wird das ausgeführte Makro angezeigt. Per Button kann dann kopiert werden.