Seite 5 von 9

Verfasst: Donnerstag 8. Januar 2009, 15:05
von str1442
Ausserdem würde ich erwarten, dass bei den meisten Architekturen Objekte an durch 2, 4, oder 16 teilbaren Adressen liegen werden. Das schränkt die Ratemöglichkeiten mindestens auf nur gerade Zahlen ein.
Warum den das? Obwohl, der Python Interpreter alloziert afair Speicher in größeren, vermutlich aus einer geraden Anzahl von Bytes bestehenden, Grüppchen, die er dann verwaltet - deswegen?

@Rebecca sieht bei mir ähnlich aus :)

ADD:

@hendrikS: Ja, in der gleichen Session - man würde diese Methode vermutlich auch nicht produktiv benutzen (es sei denn man ist gesottener C Programmierer), aber für das "Golfspiel" war es eine nette Möglichkeit, zumindest halbwegs funktionierend Zufallszahlen zu generieren - auch wenn es da je nach Betriebssystem / Speicherverwaltung Einschränkungen geben könnte.

Verfasst: Donnerstag 8. Januar 2009, 15:06
von Hyperion
hendrikS hat geschrieben:Folgendes hallo welt Programm:

Code: Alles auswählen

for i in range(10):print id(9)
10mal das Gleiche. Nicht brauchbar zur Generierung von Zufallszahlen.
Na das wurde hier doch nun zur Genüge abgehandelt ... :roll: str1442 hat Dir sogar explizit geantwortet!

Verfasst: Donnerstag 8. Januar 2009, 15:11
von HerrHagen
Hat jemand Lust auf Statistik? :Wink:
Das musste ja soweit kommen...

Code: Alles auswählen

Z = [100, 104, 113, 95, 77, 113, 101, 99, 91, 101, 94, 87, 94, 115, 123, 76, 97, 109, 111, 88, 103,
 111, 107, 104, 95, 99, 107, 109, 97, 86, 102, 103, 103, 88, 91, 88, 96, 102, 95, 95, 102, 99,
106, 78, 124, 93, 108, 112, 98, 103, 84, 111, 97, 100, 89, 85, 109, 88, 105, 97, 113, 93, 99,
96, 92, 113, 96, 91, 109, 90, 108, 104, 73, 94, 89, 84, 88, 90, 107, 109, 91, 100, 96, 92, 84,
114, 97, 105, 103, 103, 100, 92, 99, 108, 99, 104, 111, 104, 99, 111, 93]
n = float(sum(Z))
r = float(len(Z))
print sum([((z-(n/r))**2)/(n/r) for z in Z])
http://www.mathematik.uni-ulm.de/stocha ... ode27.html
http://psydok.sulb.uni-saarland.de/voll ... at/chi.htm
Ergibt eine Testgröße von T=97.55 für den Chi-Quadrat-Test.
Das ergibt ein Signifikanzniveau von 55,05% für die Nichtablehnung der Gleichverteilung.
Nich sooo toll... oder hab ich mich vertan? *lange_nicht_gemacht* *hust*

Verfasst: Donnerstag 8. Januar 2009, 15:26
von numerix
hendrikS hat geschrieben:Folgendes hallo welt Programm:

Code: Alles auswählen

for i in range(10):print id(9)
10mal das Gleiche. Nicht brauchbar zur Generierung von Zufallszahlen.
Hast du die letzten Beiträge gelesen? Und verstanden?
Natürlich kommt so 10x das gleiche heraus. Du musst das Programm NEU STARTEN. Dann kommt - wenn du nicht gerade Pech hast - eine andere Zahl heraus ...


Edit: Ups, hatte die letzte Seite des Threads noch nicht entdeckt ... hatte sich schon erledigt. :oops:

Verfasst: Donnerstag 8. Januar 2009, 15:48
von hendrikS
Ich hatte schon alles dazu gelesen. Hatte mich nur gefragt wie rebecca Ihre 10000 Zahlen generiert hat. Wahrscheinlich nicht durch 10000 einzelne Aufrufe. Aber auch bei jedem einzelnen Aufruf ist es immer gleich.
Thema ist fuer mich erledigt.

Verfasst: Donnerstag 8. Januar 2009, 15:59
von Rebecca
Hab doch extra den Code gepostet:
Rebecca hat geschrieben: Hier der Code
Ich mache jedes Mal einen neuen Interpreter-Aufruf.

Verfasst: Donnerstag 8. Januar 2009, 16:13
von hendrikS
Dein Programm sieht smart aus. Der output ist aber irgendwie seltsam. Bei 1000 Schleifendurchläufen.

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1000, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Habe ich noch nicht ganz verstanden.

Verfasst: Donnerstag 8. Januar 2009, 16:24
von Rebecca
Ah, das ist interessant. Bei dir scheint der Python-Interpreter immer genau den gleichen Adressraum zu bekommen. Was fuer ein System nutzt du?

Mein Ergebnis kommt von einem Linux 2.6.26-1-686 mit

Code: Alles auswählen

Python 2.5.2 (r252:60911, Nov 14 2008, 19:46:32)
[GCC 4.3.2] on linux2

Verfasst: Donnerstag 8. Januar 2009, 16:31
von hendrikS
Mein OS: Windows XP
Python: 2.5

Der subprocess stuff sollte aber OS unabh. sein, dachte ich.

Verfasst: Donnerstag 8. Januar 2009, 16:41
von Rebecca
Ja, Subprocess ist auch nicht das Problem. Aber wenn ich im Linux-Terminal mehrmals hintereinander
python -c "print id(9)%101"
eingebe, bekomme ich stets eine andere Zufallszahl heraus (jedesmal wird der Python-Interpreter neu gestartet -> neuer Adressraum). Wenn du diese Zeile mehrmals in die Dosbox eingibst, sollte jedesmal 32 herauskommen (und nichts anderes macht mein obiger Code), einfach aus dem Grund, dass unter Win die Speicherverwaltung anders funktioniert.

Verfasst: Donnerstag 8. Januar 2009, 16:43
von BlackVivi
Rebecca hat geschrieben:Ja, Subprocess ist auch nicht das Problem. Aber wenn ich im Linux-Terminal mehrmals hintereinander
python -c "print id(9)%101"
eingebe, bekomme ich stets eine andere Zufallszahl heraus (jedesmal wird der Python-Interpreter neu gestartet -> neuer Adressraum). Wenn du diese Zeile mehrmals in die Dosbox eingibst, sollte jedesmal 32 herauskommen, und nichts anderes macht mein obiger Code. Einfach aus dem Grund, dass unter Win die Speicherverwaltung anders funktioniert.
http://paste.pocoo.org/show/98584/

Oo

Verfasst: Donnerstag 8. Januar 2009, 16:53
von numerix
Das unterschiedliche Verhalten ist nicht allein vom Betriebssystem abhängig. Python 2.5 und 2.6 liefern bei mir verschiedene IDs, Python 3.0 immer die gleiche ...

Edit: Linux 2.6.27

Verfasst: Donnerstag 8. Januar 2009, 17:08
von str1442
Exakt die gleiche Python Version wie Rebecca (also auch um 19:46 nochwas kompiliert 60911), Debian, Linux 2.6.27.7 selbst gebaut und bekomme auch eine recht breite Verteilung.

Verfasst: Donnerstag 8. Januar 2009, 17:16
von Rebecca
BlackVivi hat geschrieben: http://paste.pocoo.org/show/98584/
Oo
War das erste ein Messfehler? :wink:

Verfasst: Donnerstag 8. Januar 2009, 17:20
von BlackVivi
Rebecca hat geschrieben:
BlackVivi hat geschrieben: http://paste.pocoo.org/show/98584/
Oo
War das erste ein Messfehler? :wink:
Wenn ich das CMD-Fenster schließ... und nochmal öffne... ist das erste wieder 17 oO'' Und alle danach wieder 41....... Und ich schließ es wieder... gib wieder den Code ein... und es ist wieder 17 und danach 41. Ich bin ein ganz klein wenig verwirrt.

Verfasst: Donnerstag 8. Januar 2009, 17:25
von HerrHagen
Auf meinem WindowsXP System mit Python 2.5 kommt, wenn ich es direkt hintereinander ausführe immer die selbe Zahl raus. Es macht auch nichts wenn ich dazwischen viele Prozesse starte und Speicher beleg. Gerade hab ichs dann einfach nochmal probiert und es kam wieder ne neue Zahl.
Wäre mal interessant zu erfahren nach welchen System den Prozessen Speicher zugewiesen wird.

Verfasst: Donnerstag 8. Januar 2009, 18:24
von hendrikS
Vielleicht kann jemand bei Codesnippets mal ein Besipiel einstellen, wozu sich id() ueberhaupt sinnvoll einsetzen lässt. Hat bei meinen Anwendungen bisher nie eine Rolle gespielt.

Verfasst: Donnerstag 8. Januar 2009, 18:38
von str1442

Code: Alles auswählen

        new_positions = {}

        for member in self.members:
            position_to_check = member.position

            try:
            *snip*

            new_positions[id(member)] = new_position
           
            # Important checks that may lead to abort

        for member in self.members:
            new_position = new_positions[id(member)]
Aus meinen Tetris Klon Tetrix0r. id() liefert nur die Speicheradresse zurück, was man damit macht musst du entscheiden.

Verfasst: Donnerstag 8. Januar 2009, 18:46
von Trundle
`id()` liefert einfach eine Zahl, die eine Art Identität eines Objektes darstellen soll. Dass das die Speicheradresse ist, das ist lediglich ein Implementationsdetail.

Verfasst: Donnerstag 8. Januar 2009, 19:41
von BlackJack
@str1442: Hast Du bei den `member`-Objekten `__cmp__()` implementiert oder oder eine der "rich comparison"-Methoden?

Speicherbelegung bei vielfachen von 2, 4, oder 16 passiert aus Optimierungsgründen. Viele Architekturen greifen langsamer auf Werte zu, wenn sie nicht an solchen Grenzen ausgerichtet sind. Einige SIMD-Maschinenbefehle auf x86-Prozessoren funktionieren nur mit Daten, die an 16-Byte-Grenzen ausgerichtet sind. Das `malloc()` aus der GNU Standardbibliothek liefert auf x86-Architekturen AFAIK auch immer nur Zeiger, die auf 16-Byte-Grenzen ausgerichtet sind.