seltsames Verhalten von Spider
-
- User
- Beiträge: 12
- Registriert: Montag 15. Juli 2019, 20:39
xD Also bei der Fülle an Informationen wird dir glaube ich nur jemand mit einer Glaskugel helfen können.Bykl hat geschrieben: Donnerstag 20. August 2020, 20:09 Hallo, hab ein kleines Programm geschrieben. Es müsste mir 2500 Zahlenpaare ausgeben. Auf der Konsole erscheinen aber nur die letzten 500. Was kann ich tun, um das zu ändern?
Ich bin jetzt auch nicht der Profi...hat deine Konsole vielleicht eine Zeilenbeschränkung!? Falls nicht, dann wird es mMn wohl an deinem Code liegen.
Ich weiß, dass ich nichts weiß und jetzt wisst ihr es auch. Also Vorsicht bei meinen Beiträgen.
Habe am Code nichts zu verbergen ... ist halt nur ne Übung
Code: Alles auswählen
import matplotlib.pyplot as plt
import numpy as np
from sympy.ntheory import isprime
from sympy import sieve
from sympy import primepi
from math import sqrt
import xlwt
zahl=9996 # Zahl mit Endziffer 6 eingeben
nr=0
nr1=0
liste_1=[]
liste_2=[]
list1=[]
list2=[]
def primteiler_a(zahl_a):
j=1
teiler_a=[]
teiler_1=[]
while j <= (zahl_a)/2:
if zahl_a%j==0:
teiler_a=zahl_a//j
if teiler_a%2>0 and isprime(teiler_a):
teiler_1.append(teiler_a)
# print(nr,"zahl",zahl,"if: i:",i,"j:",j,"Teilerb",Teilerb,"Teiler",Teiler)
j=j+1
else:
#Teiler.append(Teilerb)
#print(nr,"zahl",zahl,"else: i:",i,"j:",j,"Teilerb",Teilerb,"Teiler",Teiler)
j=j+1
return teiler_1
def primteiler_b(zahl_b):
j=1
teiler_b=[]
teiler_2=[]
while j <= (zahl_b)/2:
if zahl_b%j==0:
teiler_b=zahl_b//j
if teiler_b%2>0 and isprime(teiler_b):
teiler_2.append(teiler_b)
# print(nr,"zahl",zahl,"if: i:",i,"j:",j,"Teilerb",Teilerb,"Teiler",Teiler)
j=j+1
else:
#Teiler.append(Teilerb)
#print(nr,"zahl",zahl,"else: i:",i,"j:",j,"Teilerb",Teilerb,"Teiler",Teiler)
j=j+1
return teiler_2
for i in range(3,int(zahl/2)+1,2):
a=zahl-i
b=i
nr=nr+1
liste_1=primteiler_a(a)
liste_2=primteiler_b(b)
l_1=set(liste_1)
l_2=set(liste_2)
l_3=l_1.intersection(l_2)
if len(liste_1)>0 and len(liste_2)>0: # and len(l_3)==0:
nr1=nr1+1
print("Nr:",nr,"Nr1",nr1,"Ohne gem PT:",a,liste_1,b,liste_2,l_3,a/b)
else:
pass
#print("Nr:",nr,"Mit gem PT:",a,liste_1,b,liste_2,l_3)
book = xlwt.Workbook(encoding="utf-8")
Zahlsucher = book.add_sheet("Zahlsucher","cell_overwrite_ok=True")
Zahlsucher.write(0, 0, "Nr")
Zahlsucher.write(0, 1, "Zahl")
Zahlsucher.write(0, 2, "a")
Zahlsucher.write(0, 3, "PrTa")
Zahlsucher.write(0, 4, "b")
Zahlsucher.write(0, 5, "PrTb")
Zahlsucher.write(0, 6, "a//b")
i=0
for n in liste_1:
i = i+1
Zahlsucher.write(i, 0, i)
Zahlsucher.write(i, 1, n)
Zahlsucher.write(i, 2, a)
Zahlsucher.write(i, 3, primteiler_a(a))
Zahlsucher.write(i, 4, b)
Zahlsucher.write(i, 5, primteiler_b(b))
Zahlsucher.write(i, 6, a//b)
book.save("Zahlsucher.xls")
- __blackjack__
- User
- Beiträge: 14052
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Bykl: Da werden ein paar Sachen importiert die nicht verwendet werden.
Eingerückt wird in Python mit vier Leerzeichen pro Ebene.
Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst. Noch unübersichtlicher und fehleranfälliger ist es wenn man nicht nur das Hauptprogramm und Variablen auf Modulebene schreibt, sondern das auch noch mit Funktionsdefinitionen mischt.
Dieses Mischen in Kombination mit definieren von Variablen weit weg von dem Punkt wo man die dann tatsächlich braucht, führt auch, wie im Fall von `list1` und `list2` gerne mal dazu das man übersieht das Definitionen nirgends verwendet werden.
Um Gleichheitszeichen bei Zuweisungen ausserhalb von Argumentlisten, um binäre Operatoren, und nach Kommas, erhöhen die Lesbarkeit.
Bei den Kleinbuchstaben hast Du `Zahlsucher` übersehen.
Was ist eigentlich der Unterschied zwischen den Funktionen `primteiler_a()` und `primteiler_b()`? Warum sind das *zwei* Funktionen?
Die erste Zuweisung einer leeren Liste an die Namen `teiler_a`/`teiler_b` in diesen Funktionen ist offensichtlich unsinnig, denn diese Liste wird nirgends verwendet, und in der Schleife werden dann einzelne ganze Zahlen an diesen Namen gebunden, also ein komplett anderer Datentyp.
Wenn am Anfang beziehungsweise am Ende von ``if``/``else``-Blöcken das gleiche gemacht wird, dann gehört das nicht *in* diese Blöcke sondern vor beziehungsweise hinter das ``if``/``else``-Konstrukt, denn dann hängt dieser Code ja überhaupt nicht von der ``if``-Bedingung ab.
Die ``while``-Schleife in der `primteiler*()`-Funktion ist eigentlich eine ``for``-Schleife die man auch als solche schreiben sollte, weil das dann einfacher verständlich ist, und man diesem Umstand nicht erst selbst beim lesen herausfinden muss. Denn bei einer ``while``-Schleife geht der Leser davon aus, dass es einen Grund für eine ``while``-Schleife gibt, und er unnötig nach dem nicht-vorhandenen Grund suchen muss.
Warum wird da `j` als einzig vorhandener Laufindex verwendet, statt dem üblichen `i`?
Semantische Frage: Warum gehört die 2 nicht zu der Liste der Primteiler?
Ein ``if``- oder ``else``-Block der nur ein ``pass`` enthält macht keinen Sinn.
Funktions- und Methodennamen beschreiben üblicherweise die Tätigkeit die die Funktion oder Methode durchführt. `primteiler_a`/`primteiler_b` ist keine Tätigkeit.
`nr` sollte man nicht manuell hochzählen, für so etwas gibt es die `enumerate()`-Funktion.
Nummerierte Namen sind ein Zeichen, dass man sich entweder bessere Namen ausdenken will, oder gar keine einzelnen Namen und Werte, sondern eine Datenstruktur verwenden will. Oft eine Liste.
`nr1` sollte so benannt werden, dass der Leser weiss was diese Nummer *bedeutet*. Es scheint ja irgendeine Anzahl zu sein. Von was? Das sollte man am Namen ablesen können.
Zumindest `liste_2` braucht man nicht vor der Schleife definieren, denn es wird *in* der Schleife definiert und *nach* der Schleife nirgends verwendet.
Auch bei `liste_1` und `liste_2` ist die Nummerierung schlecht, und auch der Grunddatentyp im Namen hat dort nichts zu suchen. Der Leser möchte wissen was diese Werte bedeuten, nicht das es Listen sind, und die ”wie vielte” Liste das jeweils ist. Hier ist dann auch ein praktischer Grund warum man Funktionen nach Tätigkeiten bennennt: Damit der Leser eher passive Werte von Funktionen unterscheiden kann und man hier die naheliegenden Namen `primteiler_a` für die Primteiler von `a` und `primteiler_b` für die Primteiler von `b` verwenden kann und sich nicht irgend etwas anderes ausdenken muss weil man Funktionen schon so benannt hat.
Die Laufvariable in der ersten ``for``-Schleife im Hauptprogramm ist ja offensichtlich der Wert, der für `b` verwendet werden soll, warum heisst die dann `i` und nicht gleich `b`?
Bei `l_1` bis `l_3` haben wir wieder Nummerierung von Namen und absolut nichtssagende Namen. Zwei von den Namen kann man sich sparen weil man nicht jedes kleine Zwischenergebnis zwingend an einen Namen binden muss, und das Ergebnis von der Schnittmenge sollte wieder so benannt werden, dass der Leser ablesen kann welche Bedeutung dieser Wert hat. Beziehungsweise braucht man das im vorliegenden Code auch nicht an einen Namen binden. Wobei ich mir nicht sicher bin, dass der Code so überhaupt richtig ist. Der auskommentierte Bedingungsteil und der Ausgabetext "Ohne gem PT:" deuten darauf hin, dass das so falsche Ausgaben produziert.
`zahlsucher` ist ein komischer Name für ein Arbeitsblatt einer Exceltabelle.
Das "cell_overwrite_ok=True"-Argument ist eine sehr komische und irreführende Art effektiv `True` zu übergeben. Denn "Räuber Hotzenplotz" hätte den gleichen Effekt, wie jede andere nicht-leere Zeichenkette. Zudem sehe ich auch nicht warum man hier nicht den Default-Wert `False` haben will, denn der Code will ja gar keine Zellen mehr als einmal beschreiben, und man hätte damit eine Prüfung aktiv die solche Fehler anzeigen würde.
Warum werden beim schreiben der Exceltabelle die Primteiler vom letzten `a` und `b` in der Schleife davor immer wieder neu berechnet? Man hat die Werte doch bereits in `liste_1` und `liste_2` stehen und die ändern sich ja auch nicht, die sind in jeder Zeile des Arbeitsblattes gleich. Genau wie sich ``a // b`` nie ändert weil sich `a` und `b` nicht ändern in der Schleife. Das sieht sehr komisch bis falsch aus.
Eingerückt wird in Python mit vier Leerzeichen pro Ebene.
Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst. Noch unübersichtlicher und fehleranfälliger ist es wenn man nicht nur das Hauptprogramm und Variablen auf Modulebene schreibt, sondern das auch noch mit Funktionsdefinitionen mischt.
Dieses Mischen in Kombination mit definieren von Variablen weit weg von dem Punkt wo man die dann tatsächlich braucht, führt auch, wie im Fall von `list1` und `list2` gerne mal dazu das man übersieht das Definitionen nirgends verwendet werden.
Um Gleichheitszeichen bei Zuweisungen ausserhalb von Argumentlisten, um binäre Operatoren, und nach Kommas, erhöhen die Lesbarkeit.
Bei den Kleinbuchstaben hast Du `Zahlsucher` übersehen.
Was ist eigentlich der Unterschied zwischen den Funktionen `primteiler_a()` und `primteiler_b()`? Warum sind das *zwei* Funktionen?
Die erste Zuweisung einer leeren Liste an die Namen `teiler_a`/`teiler_b` in diesen Funktionen ist offensichtlich unsinnig, denn diese Liste wird nirgends verwendet, und in der Schleife werden dann einzelne ganze Zahlen an diesen Namen gebunden, also ein komplett anderer Datentyp.
Wenn am Anfang beziehungsweise am Ende von ``if``/``else``-Blöcken das gleiche gemacht wird, dann gehört das nicht *in* diese Blöcke sondern vor beziehungsweise hinter das ``if``/``else``-Konstrukt, denn dann hängt dieser Code ja überhaupt nicht von der ``if``-Bedingung ab.
Die ``while``-Schleife in der `primteiler*()`-Funktion ist eigentlich eine ``for``-Schleife die man auch als solche schreiben sollte, weil das dann einfacher verständlich ist, und man diesem Umstand nicht erst selbst beim lesen herausfinden muss. Denn bei einer ``while``-Schleife geht der Leser davon aus, dass es einen Grund für eine ``while``-Schleife gibt, und er unnötig nach dem nicht-vorhandenen Grund suchen muss.
Warum wird da `j` als einzig vorhandener Laufindex verwendet, statt dem üblichen `i`?
Semantische Frage: Warum gehört die 2 nicht zu der Liste der Primteiler?
Ein ``if``- oder ``else``-Block der nur ein ``pass`` enthält macht keinen Sinn.
Funktions- und Methodennamen beschreiben üblicherweise die Tätigkeit die die Funktion oder Methode durchführt. `primteiler_a`/`primteiler_b` ist keine Tätigkeit.
`nr` sollte man nicht manuell hochzählen, für so etwas gibt es die `enumerate()`-Funktion.
Nummerierte Namen sind ein Zeichen, dass man sich entweder bessere Namen ausdenken will, oder gar keine einzelnen Namen und Werte, sondern eine Datenstruktur verwenden will. Oft eine Liste.
`nr1` sollte so benannt werden, dass der Leser weiss was diese Nummer *bedeutet*. Es scheint ja irgendeine Anzahl zu sein. Von was? Das sollte man am Namen ablesen können.
Zumindest `liste_2` braucht man nicht vor der Schleife definieren, denn es wird *in* der Schleife definiert und *nach* der Schleife nirgends verwendet.
Auch bei `liste_1` und `liste_2` ist die Nummerierung schlecht, und auch der Grunddatentyp im Namen hat dort nichts zu suchen. Der Leser möchte wissen was diese Werte bedeuten, nicht das es Listen sind, und die ”wie vielte” Liste das jeweils ist. Hier ist dann auch ein praktischer Grund warum man Funktionen nach Tätigkeiten bennennt: Damit der Leser eher passive Werte von Funktionen unterscheiden kann und man hier die naheliegenden Namen `primteiler_a` für die Primteiler von `a` und `primteiler_b` für die Primteiler von `b` verwenden kann und sich nicht irgend etwas anderes ausdenken muss weil man Funktionen schon so benannt hat.
Die Laufvariable in der ersten ``for``-Schleife im Hauptprogramm ist ja offensichtlich der Wert, der für `b` verwendet werden soll, warum heisst die dann `i` und nicht gleich `b`?
Bei `l_1` bis `l_3` haben wir wieder Nummerierung von Namen und absolut nichtssagende Namen. Zwei von den Namen kann man sich sparen weil man nicht jedes kleine Zwischenergebnis zwingend an einen Namen binden muss, und das Ergebnis von der Schnittmenge sollte wieder so benannt werden, dass der Leser ablesen kann welche Bedeutung dieser Wert hat. Beziehungsweise braucht man das im vorliegenden Code auch nicht an einen Namen binden. Wobei ich mir nicht sicher bin, dass der Code so überhaupt richtig ist. Der auskommentierte Bedingungsteil und der Ausgabetext "Ohne gem PT:" deuten darauf hin, dass das so falsche Ausgaben produziert.
`zahlsucher` ist ein komischer Name für ein Arbeitsblatt einer Exceltabelle.
Das "cell_overwrite_ok=True"-Argument ist eine sehr komische und irreführende Art effektiv `True` zu übergeben. Denn "Räuber Hotzenplotz" hätte den gleichen Effekt, wie jede andere nicht-leere Zeichenkette. Zudem sehe ich auch nicht warum man hier nicht den Default-Wert `False` haben will, denn der Code will ja gar keine Zellen mehr als einmal beschreiben, und man hätte damit eine Prüfung aktiv die solche Fehler anzeigen würde.
Warum werden beim schreiben der Exceltabelle die Primteiler vom letzten `a` und `b` in der Schleife davor immer wieder neu berechnet? Man hat die Werte doch bereits in `liste_1` und `liste_2` stehen und die ändern sich ja auch nicht, die sind in jeder Zeile des Arbeitsblattes gleich. Genau wie sich ``a // b`` nie ändert weil sich `a` und `b` nicht ändern in der Schleife. Das sieht sehr komisch bis falsch aus.
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
Danke Blackjack, für Deine ausführliche Arbeit - muß man ja so schon nennen! Das ist sehr viel, und ich weiss nicht, ob ich das bis zum nächsten mal schon intus habe. Mein Hauptinteresse ist Mathedenken und mit Python will ich immer nur ein paar meiner Gedanken nachprüfen. Leider hält mich das Programmieren sehr auf, da zu viele Lehrer und Pädagogen im Forum unterwegs sind, die nicht produktiv antworten. Ich denke, manches, was ich mir mühsam über Stunden suchen muß, kann man mit ein zwei kurzen Stichworten oder Code berichtigen. Ich beantworte Deinen ausführlichen Post genauso ausführlich, damit Du nicht denkst, ich sei zu faul...
Den Satz versteh ich nicht!
... in der Originalversion nicht, nur hier in der Kopie....
Das ist eine Notlösung, weil ich nicht weiss, wie man, wenn die Funktion 2 Werte berechnet, die beiden zu verschiedenen Zeiten herausholt. Ich will ja die Primteiler von 2 Zahlen in je getrennten Containern, damit ich sie zur Schnittbildung (intersection) getrennt aufrufen kann.
Ich hoffe, Dir Deine Fragen beantwortet zu haben. Das Problem ist, wenn ich das jetzt nach Deine Richtlinien umarbeite, habe ich etliche andere bug's drin. Ich probier es trotzdem.... Vielen Dank noch mal, und lieben Gruss
hab das inzwischen auskommentiert.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 @Bykl: Da werden ein paar Sachen importiert die nicht verwendet werden.
Wusst ich nicht...__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Eingerückt wird in Python mit vier Leerzeichen pro Ebene.
Was sind eigentlich Klassen?__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert.
war in cpp auch so. Habe das in Python aber noch nicht gesehen .... Kannst Du mal so eine main-Zeile posten?__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst.
ich werde jetzt die Funktionsdefinitionen zwischen Bibliotheksaufrufen und main anbringen.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Noch unübersichtlicher und fehleranfälliger ist es wenn man nicht nur das Hauptprogramm und Variablen auf Modulebene schreibt, sondern das auch noch mit Funktionsdefinitionen mischt.
Ja, das ist in jedem Fall idiotisch. Vielleicht sollte ich die Globalen Variablen und Container zwischen Bibliotheken und Funktionen plazieren.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Dieses Mischen in Kombination mit definieren von Variablen weit weg von dem Punkt wo man die dann tatsächlich braucht, führt auch, wie im Fall von `list1` und `list2` gerne mal dazu das man übersieht das Definitionen nirgends verwendet werden.
__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Um Gleichheitszeichen bei Zuweisungen ausserhalb von Argumentlisten, um binäre Operatoren, und nach Kommas, erhöhen die Lesbarkeit.
Den Satz versteh ich nicht!
__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Bei den Kleinbuchstaben hast Du `Zahlsucher` übersehen.
... in der Originalversion nicht, nur hier in der Kopie....
__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Was ist eigentlich der Unterschied zwischen den Funktionen `primteiler_a()` und `primteiler_b()`? Warum sind das *zwei* Funktionen?
Das ist eine Notlösung, weil ich nicht weiss, wie man, wenn die Funktion 2 Werte berechnet, die beiden zu verschiedenen Zeiten herausholt. Ich will ja die Primteiler von 2 Zahlen in je getrennten Containern, damit ich sie zur Schnittbildung (intersection) getrennt aufrufen kann.
Das bitte ich noch mal genauer zu erklären, denn das Programm läuft zwar, aber er sagt: "raise Exception ("Unexpected data type %r" % type(data))" und aus dem rich_text_hellper in row.py in Spider werd ich nicht schlau. Es muß aber was damit zu tun haben.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Die erste Zuweisung einer leeren Liste an die Namen `teiler_a`/`teiler_b` in diesen Funktionen ist offensichtlich unsinnig, denn diese Liste wird nirgends verwendet, und in der Schleife werden dann einzelne ganze Zahlen an diesen Namen gebunden, also ein komplett anderer Datentyp.
Manchmal hat man If-Konstruktionen, in denen nur nach dem else was relevantes passiert, dann muß nach em If irgendwas hin, deswegen das pass. Immerhin gibt es dies ja. Also muß es nicht nur mir so gehen. Das j=j+1 stammt aus der Zeit, als ich das pass noch nicht kannte.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Wenn am Anfang beziehungsweise am Ende von ``if``/``else``-Blöcken das gleiche gemacht wird, dann gehört das nicht *in* diese Blöcke sondern vor beziehungsweise hinter das ``if``/``else``-Konstrukt, denn dann hängt dieser Code ja überhaupt nicht von der ``if``-Bedingung ab.
Ich denke auch so. Die while-Schleife hatt ich geklaut. Da sie funktioniert, hast ich sie gelassen. Alles, was funktioniert, da pfusch ich nicht so sehr drin rum, weil ich mir damit nur Zeit stehle.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Die ``while``-Schleife in der `primteiler*()`-Funktion ist eigentlich eine ``for``-Schleife die man auch als solche schreiben sollte, weil das dann einfacher verständlich ist, und man diesem Umstand nicht erst selbst beim lesen herausfinden muss.
Was ist denn eine Grund für ein while-Schleife.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06Denn bei einer ``while``-Schleife geht der Leser davon aus, dass es einen Grund für eine ``while``-Schleife gibt, und er unnötig nach dem nicht-vorhandenen Grund suchen muss.
Weil ich sicherheitshalber für ein anderes for eine andere Laufvokabel nehme.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Warum wird da `j` als einzig vorhandener Laufindex verwendet, statt dem üblichen `i`?
Aus Laufzeit- und Denkgründen__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Semantische Frage: Warum gehört die 2 nicht zu der Liste der Primteiler?
ich hatte mit dem Programm erst was andres gemacht, da war da noch was drin, dann habe ich adaptiert, und es, weil es nicht störte, stehengelassen.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Ein ``if``- oder ``else``-Block der nur ein ``pass`` enthält macht keinen Sinn.
Soll ich wirklich schreiben "primteiler_von_a_raussuchen" ?__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Funktions- und Methodennamen beschreiben üblicherweise die Tätigkeit die die Funktion oder Methode durchführt. `primteiler_a`/`primteiler_b` ist keine Tätigkeit.
Die kenn ich noch nicht..... brauche oft mehrere Zähler ....__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 `nr` sollte man nicht manuell hochzählen, für so etwas gibt es die `enumerate()`-Funktion.
Ich hätte auch rechts und links nehmen können, oder oben und unten.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Nummerierte Namen sind ein Zeichen, dass man sich entweder bessere Namen ausdenken will, oder gar keine einzelnen Namen und Werte, sondern eine Datenstruktur verwenden will. Oft eine Liste.
Da ich, wie oben bemerkt, diverse dinge Zähle und oft die Programme adaptiere, macht das nur wenig Sinn. Was nr und nr 1 mathematisch sind, hängt von dem ab, was ich grade suche....__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 `nr1` sollte so benannt werden, dass der Leser weiss was diese Nummer *bedeutet*. Es scheint ja irgendeine Anzahl zu sein. Von was? Das sollte man am Namen ablesen können.
Manchmal definiere ich einfach zur Sicherheit nochwas, damit Spider nicht meckert. Das gehört zu meinem Medikamentenkasten.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Zumindest `liste_2` braucht man nicht vor der Schleife definieren, denn es wird *in* der Schleife definiert und *nach* der Schleife nirgends verwendet.
Steht aber in jedem Tutorium so da.....__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06Auch bei `liste_1` und `liste_2` ist die Nummerierung schlecht, und auch der Grunddatentyp im Namen hat dort nichts zu suchen.
Ja, aber wenn der Programmierer das nicht richtig unterscheiden kann, wie soll er denn normgerecht benennen? Sinnvoll ist es schon, sehe ich.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Der Leser möchte wissen, was diese Werte bedeuten, nicht das es Listen sind, und die ”wie vielte” Liste das jeweils ist. Hier ist dann auch ein praktischer Grund warum man Funktionen nach Tätigkeiten bennennt: Damit der Leser eher passive Werte von Funktionen unterscheiden kann und man hier die naheliegenden Namen `primteiler_a` für die Primteiler von `a` und `primteiler_b` für die Primteiler von `b` verwenden kann und sich nicht irgend etwas anderes ausdenken muss weil man Funktionen schon so benannt hat.
Könnte man machen. Ich habe aber zwei math. Strategien, die von unterschiedlichen Vorraussetzungen ausgehen und mit derselbe Schleife arbeiten und darum ist es besser, ich definiere hier nochmal a und b und arbeite damit. Manchmal geht "ich muß wissen, was ich tue" - vor programmatische Effizienz und Codekürze. Weil ich kein Profi bin.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Die Laufvariable in der ersten ``for``-Schleife im Hauptprogramm ist ja offensichtlich der Wert, der für `b` verwendet werden soll, warum heisst die dann `i` und nicht gleich `b`?
Ich werde das umsetzen. Ich verstehe aber sowieso nicht, warum da erst ein Set Befehl hinmuß. Was macht der mit dem Container, in dem die Primteiler drin sind?__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Bei `l_1` bis `l_3` haben wir wieder Nummerierung von Namen und absolut nichtssagende Namen. Zwei von den Namen kann man sich sparen weil man nicht jedes kleine Zwischenergebnis zwingend an einen Namen binden muss, und das Ergebnis von der Schnittmenge sollte wieder so benannt werden, dass der Leser ablesen kann welche Bedeutung dieser Wert hat. Beziehungsweise braucht man das im vorliegenden Code auch nicht an einen Namen binden. Wobei ich mir nicht sicher bin, dass der Code so überhaupt richtig ist.
Das ist auch noch ein Relikt. Das Programm lief ordentlich.....__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Der auskommentierte Bedingungsteil und der Ausgabetext "Ohne gem PT:" deuten darauf hin, dass das so falsche Ausgaben produziert.
Ja, aber sag einen besseren, für so eine temporäre Nachkuck-Datei...__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 `zahlsucher` ist ein komischer Name für ein Arbeitsblatt einer Exceltabelle.
Das ist auch vom Vorprogramm. Es schrieb erst, als ich das gesetzt hatte.__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Das "cell_overwrite_ok=True"-Argument ist eine sehr komische und irreführende Art effektiv `True` zu übergeben. Denn "Räuber Hotzenplotz" hätte den gleichen Effekt, wie jede andere nicht-leere Zeichenkette. Zudem sehe ich auch nicht warum man hier nicht den Default-Wert `False` haben will, denn der Code will ja gar keine Zellen mehr als einmal beschreiben, und man hätte damit eine Prüfung aktiv die solche Fehler anzeigen würde.
Das ist wirklich eine Performance-Dummheit__blackjack__ hat geschrieben: Freitag 21. August 2020, 15:06 Warum werden beim Schreiben der Exceltabelle die Primteiler vom letzten `a` und `b` in der Schleife davor immer wieder neu berechnet? Man hat die Werte doch bereits in `liste_1` und `liste_2` stehen und die ändern sich ja auch nicht, die sind in jeder Zeile des Arbeitsblattes gleich. Genau wie sich ``a // b`` nie ändert weil sich `a` und `b` nicht ändern in der Schleife. Das sieht sehr komisch bis falsch aus.
Ich hoffe, Dir Deine Fragen beantwortet zu haben. Das Problem ist, wenn ich das jetzt nach Deine Richtlinien umarbeite, habe ich etliche andere bug's drin. Ich probier es trotzdem.... Vielen Dank noch mal, und lieben Gruss
-
- User
- Beiträge: 12
- Registriert: Montag 15. Juli 2019, 20:39
Boah heftig...Bykl hat geschrieben: Freitag 21. August 2020, 16:26 Leider hält mich das Programmieren sehr auf, da zu viele Lehrer und Pädagogen im Forum unterwegs sind, die nicht produktiv antworten.

@__blackjack__
Respekt, dass du ihm so viel Zeit geschenkt hast.
Ich weiß, dass ich nichts weiß und jetzt wisst ihr es auch. Also Vorsicht bei meinen Beiträgen.
- __blackjack__
- User
- Beiträge: 14052
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Bykl: Du weisst das der Einstiegspunkt in einem C++-Programm eine `main()`-Funktion ist, aber nicht was Klassen sind?
Klassen fassen Werte und darauf operierende Funktionen zusammen. In Python kann man die Begriffe ”Klasse” und ”Datentyp” synomym verwenden, weil jedem Datentyp eine Klasse zugrunde liegt. In Deinem Programm ist beispielsweise `Workbook` eine Klasse:
Globale Variablen/Container sollten nirgends platziert werden, es sollte sie gar nicht geben. Die machen Code unnötig schwer verständlich und damit fehleranfälliger und schwerer testbar, wodurch Fehler dann auch noch schwerer zu finden sind. Funktionen und Methoden bekommen alles was sie ausser Konstanten brauchen als Argument(e) übergeben und liefern Ergebnisse als Rückgabewerte an den Aufrufer. Container sollten möglichst nicht verändert werden, es sei denn das ist für den Aufrufer nicht überraschend oder Dokumentiert. Damit es nicht überraschend ist. So vermeidet man unnötige Fehler die man nicht so leicht finden kann.
Zu den Leerzeichen: Statt ``name=wert`` besser ``name = wert``, statt ``a+b/c`` besser ``a + b / c``, statt ``a,b,c`` besser ``a, b, c``. Also im Grunde die gleichen Richtlinien die man bei Text auch befolgt. Ausnahme bei den Zuweisungen sind Argumentlisten, also entweder bei Funktions-/Methodendefinitionen oder bei deren Aufruf. So kann man die leicht von den anderen, ”normalen” Zuweisungen unterscheiden, auch wenn sich die Argumentliste über mehrer Zeilen erstreckt. Ein Blick in den Style Guide for Python Code lohnt sich da.
Die Erklärung mit den zwei Funktionen verstehe ich nicht und ich denke das ist ein Missverständnis deinerseits wie Funktionen funktionieren. Dafür spricht auch Deine Erklärung für das `j` als Laufvariable. Jeder Aufruf von `primteiler_a()` erzeugt eine neue Liste mit Ergebnissen. Da braucht man keine identische zweite Funktion die nur andere Namen verwendet für. Die Namen die lokal in einer Funktion verwendet werden haben auch nichts mit Namen in anderen Funktionen oder Modulen zu tun. Das ist ja gerade der Witz von Funktionen, dass das in sich geschlossene ”Miniprogramme” sein sollten, wo man über die Argumente Werte reinfüttert und per ``return`` einen Rückgabwert liefern kann, und das dazwischen am besten keinen Einfluss auf den Rest des Programms haben sollte. Denn dann kann man Funktionen isoliert betrachten und nachvollziehen, ohne das ganze Programm kennen zu müsssen und sie auch einzeln testen, ob sie das tun was sie sollen. Zum Beispiel um Fehler zu finden, oder automatisierte Tests zu schreiben.
Ja es gibt ``pass``. Die blosse Existenz eines Schlüsselwortes sagt aber nicht, dass das überall wo man es hinschreiben kann Sinn macht und verwendet werden sollte. Im Grunde noch nicht einmal das es überhaupt verwendet werden sollte. ``global`` ist beispielsweise etwas von dem man eher grundsätzlich die Finger lassen sollte.
Es gibt Stellen da *muss* man tatsächlich aus syntaktischen Gründen etwas hinschreiben, auch wenn da gar nichts passieren soll. Ein ``if``- oder ein ``else``-Zweig gehören nicht dazu. Ein ``else: pass`` kann man einfach weg lassen ohne das sich am Verhalten des Programms etwas ändert. Und bei einem ``if bedingung: pass`` mit einem folgenden ``else`` kann man die Bedingung einfach negieren und den ``else``-Zweig in den ``if``-Zweig packen und das ``else`` weg lassen.
Einsatzzwecke für ``pass`` sind beispielsweise Klassen von denen man nur ableitet, aber sonst nichts verändern will. Typisch dafür sind Ausnahmen, falls man da keinen DocString schreiben will. Oder ``except``-Blöcke wo nichts passieren soll. Sieht man oft beim behandeln von `KeyboardInterrupt`.
Manchmal sieht man das als Platzhalter für noch nicht geschriebenen Code. Da sollte man aber einen entsprechenden Kommentar dazu schreiben, damit man diese Verwendung von den anderen, wo das ``pass`` tatsächlich da stehen soll, unterscheiden kann. Ich persönlich nehme dafür lieber das `Ellipsis`-Objekt das man als ``...`` schreiben kann.
Der Grund für eine ``while``-Schleife ist, dass man eine Bedingung hat, die man immer wieder aufs neue prüfen muss, und deren Bestandteile nicht so aktualisiert werden, dass man eine ``for``-Schleife verwenden könnte. Wenn man also eine ``while``-Schleife sieht, bei der vorher eine ganzzahlige Variable definiert wird, die in der Bedingung mit einem anderen Wert verglichen wird, dann kann es eigentlich nicht sein, dass die ”Laufvariable” in jedem Schleifendurchlauf bedingungslos gleichartig verändert wird und/oder der andere Wert konstant bleibt. Wenn man so ein ``while`` sieht, muss man beim lesen davon ausgehen, das da irgend etwas komplizierteres vor sich geht. Wenn wenn man dafür eine einfache ``for``-Schleife hätte schreiben können, hätte man das ja gemacht. Bei ``for i in range(n):`` weiss ich schon bei dieser einen Zeile am Anfang der Schleife wie sich die Werte von `i` in jedem Durchlauf ergeben. Bei ``i = 0`` gefolgt von ``while i < n:`` habe ich keine Ahnung wie sich `i` entwickeln wird, ohne den gesamten Schleifenkörper gelesen zu haben.
`primteiler_von_a_raussuchen()` enthält die unnötige Information `von_a`. Ansonsten ja, ich würde das `berechne_primteiler()` oder so ähnlich nennen. Man sieht daran, dass es eine Funktion ist, und man kann das *Ergebnis* davon dann `primteiler` oder `primteiler_a` nennen, ohne eine Namenskollision mit der Funktion zu bekommen.
`rechts` und `links` oder `oben` und `unten` machen aber nur Sinn wenn diese Namen tatsächlich bei den jeweiligen Werten Sinn machen.
Schlechte Namen stehen nicht in jedem Tutorium, aber ja, leider in vielen. Oft weil es dort einfach bei supergenerischen Beispielen einfach keinen passenderen Namen gibt, leider aber auch oft wenn es welche gäbe. Viele Tutorials gehen leider davon aus, das man nur die Syntax vermitteln muss. Gute Namensgebung ist aber wichtig und nicht nur Kosmetik, weil sie zum Verständnis des Programms beiträgt. Und nicht nur bei ”fremden” Lesern, sondern auch beim Programmierer selbst. Bei schlechten Namen können Fehler passieren die bei guten Namen auffallen würden. Wenn man Probleme hat einen guten Namen für einen Wert zu finden, ist das häufig ein Zeichen, dass man entweder das Problem oder die Lösung nicht ganz verstanden hat. Oder das man versucht Daten die nicht zusammengehören in einem Objekt oder einer Datenstruktur zusammenzufassen.
Wenn Du nicht verstehst warum da ein `set()` hin muss, warum hast *Du* das denn da hin geschrieben? Letztlich wird dort die Schnittmenge der beiden Teilerlisten ermittelt und dafür hat der `set()`-Datentyp eine Operation. Zusätzlich ”filtert” der mehrfache Elemente aus, weil jedes Element nur einmal in einer Menge vorkommen kann.
Bei dem `i` ist eigentlich immer `b` geht es weniger um programmatische Effizienz, denn diese eine zusätzliche Variable ist ja nichts was den Rechner jetzt stark belasten würde, sondern darum das für den Leser einfach zu halten. Der Mensch kann nur eine bestimmte Menge an Informationen/Variablen gleichzeitig im Kopf jonglieren. Je nach Studie sind das wohl so zwischen fünf bis sieben ”Dinge”, weshalb man mit der Anzahl an unterschiedlichen Variablen in einer Funktion oder mindestens in einem Code-Abschnitt sparsam sein sollte.
Ich sehe nicht warum bei dem gezeigten Code das überschreiben von Zellwerten erlaubt sein müsste. Aber selbst wenn, ist es halt falsch das `True` durch so eine total verwirrende Zeichenkette zu ersetzen, die aussieht als würde dort ein Schlüsselwort-Argument übergeben. Insbesonder weil da "cell_overwrite_ok=False" genau den gleichen Effekt hätte, weil das eben auch im boole'schen Kontext `True` ist.
Ich habe die Hinweise mal umgesetzt und dabei hoffentlich keinen Fehler gemacht (ungetestet):
Klassen fassen Werte und darauf operierende Funktionen zusammen. In Python kann man die Begriffe ”Klasse” und ”Datentyp” synomym verwenden, weil jedem Datentyp eine Klasse zugrunde liegt. In Deinem Programm ist beispielsweise `Workbook` eine Klasse:
Code: Alles auswählen
In [43]: import inspect
In [44]: inspect.isclass(xlwt.Workbook)
Out[44]: True
Zu den Leerzeichen: Statt ``name=wert`` besser ``name = wert``, statt ``a+b/c`` besser ``a + b / c``, statt ``a,b,c`` besser ``a, b, c``. Also im Grunde die gleichen Richtlinien die man bei Text auch befolgt. Ausnahme bei den Zuweisungen sind Argumentlisten, also entweder bei Funktions-/Methodendefinitionen oder bei deren Aufruf. So kann man die leicht von den anderen, ”normalen” Zuweisungen unterscheiden, auch wenn sich die Argumentliste über mehrer Zeilen erstreckt. Ein Blick in den Style Guide for Python Code lohnt sich da.
Die Erklärung mit den zwei Funktionen verstehe ich nicht und ich denke das ist ein Missverständnis deinerseits wie Funktionen funktionieren. Dafür spricht auch Deine Erklärung für das `j` als Laufvariable. Jeder Aufruf von `primteiler_a()` erzeugt eine neue Liste mit Ergebnissen. Da braucht man keine identische zweite Funktion die nur andere Namen verwendet für. Die Namen die lokal in einer Funktion verwendet werden haben auch nichts mit Namen in anderen Funktionen oder Modulen zu tun. Das ist ja gerade der Witz von Funktionen, dass das in sich geschlossene ”Miniprogramme” sein sollten, wo man über die Argumente Werte reinfüttert und per ``return`` einen Rückgabwert liefern kann, und das dazwischen am besten keinen Einfluss auf den Rest des Programms haben sollte. Denn dann kann man Funktionen isoliert betrachten und nachvollziehen, ohne das ganze Programm kennen zu müsssen und sie auch einzeln testen, ob sie das tun was sie sollen. Zum Beispiel um Fehler zu finden, oder automatisierte Tests zu schreiben.
Ja es gibt ``pass``. Die blosse Existenz eines Schlüsselwortes sagt aber nicht, dass das überall wo man es hinschreiben kann Sinn macht und verwendet werden sollte. Im Grunde noch nicht einmal das es überhaupt verwendet werden sollte. ``global`` ist beispielsweise etwas von dem man eher grundsätzlich die Finger lassen sollte.
Es gibt Stellen da *muss* man tatsächlich aus syntaktischen Gründen etwas hinschreiben, auch wenn da gar nichts passieren soll. Ein ``if``- oder ein ``else``-Zweig gehören nicht dazu. Ein ``else: pass`` kann man einfach weg lassen ohne das sich am Verhalten des Programms etwas ändert. Und bei einem ``if bedingung: pass`` mit einem folgenden ``else`` kann man die Bedingung einfach negieren und den ``else``-Zweig in den ``if``-Zweig packen und das ``else`` weg lassen.
Einsatzzwecke für ``pass`` sind beispielsweise Klassen von denen man nur ableitet, aber sonst nichts verändern will. Typisch dafür sind Ausnahmen, falls man da keinen DocString schreiben will. Oder ``except``-Blöcke wo nichts passieren soll. Sieht man oft beim behandeln von `KeyboardInterrupt`.
Manchmal sieht man das als Platzhalter für noch nicht geschriebenen Code. Da sollte man aber einen entsprechenden Kommentar dazu schreiben, damit man diese Verwendung von den anderen, wo das ``pass`` tatsächlich da stehen soll, unterscheiden kann. Ich persönlich nehme dafür lieber das `Ellipsis`-Objekt das man als ``...`` schreiben kann.
Der Grund für eine ``while``-Schleife ist, dass man eine Bedingung hat, die man immer wieder aufs neue prüfen muss, und deren Bestandteile nicht so aktualisiert werden, dass man eine ``for``-Schleife verwenden könnte. Wenn man also eine ``while``-Schleife sieht, bei der vorher eine ganzzahlige Variable definiert wird, die in der Bedingung mit einem anderen Wert verglichen wird, dann kann es eigentlich nicht sein, dass die ”Laufvariable” in jedem Schleifendurchlauf bedingungslos gleichartig verändert wird und/oder der andere Wert konstant bleibt. Wenn man so ein ``while`` sieht, muss man beim lesen davon ausgehen, das da irgend etwas komplizierteres vor sich geht. Wenn wenn man dafür eine einfache ``for``-Schleife hätte schreiben können, hätte man das ja gemacht. Bei ``for i in range(n):`` weiss ich schon bei dieser einen Zeile am Anfang der Schleife wie sich die Werte von `i` in jedem Durchlauf ergeben. Bei ``i = 0`` gefolgt von ``while i < n:`` habe ich keine Ahnung wie sich `i` entwickeln wird, ohne den gesamten Schleifenkörper gelesen zu haben.
`primteiler_von_a_raussuchen()` enthält die unnötige Information `von_a`. Ansonsten ja, ich würde das `berechne_primteiler()` oder so ähnlich nennen. Man sieht daran, dass es eine Funktion ist, und man kann das *Ergebnis* davon dann `primteiler` oder `primteiler_a` nennen, ohne eine Namenskollision mit der Funktion zu bekommen.
`rechts` und `links` oder `oben` und `unten` machen aber nur Sinn wenn diese Namen tatsächlich bei den jeweiligen Werten Sinn machen.
Schlechte Namen stehen nicht in jedem Tutorium, aber ja, leider in vielen. Oft weil es dort einfach bei supergenerischen Beispielen einfach keinen passenderen Namen gibt, leider aber auch oft wenn es welche gäbe. Viele Tutorials gehen leider davon aus, das man nur die Syntax vermitteln muss. Gute Namensgebung ist aber wichtig und nicht nur Kosmetik, weil sie zum Verständnis des Programms beiträgt. Und nicht nur bei ”fremden” Lesern, sondern auch beim Programmierer selbst. Bei schlechten Namen können Fehler passieren die bei guten Namen auffallen würden. Wenn man Probleme hat einen guten Namen für einen Wert zu finden, ist das häufig ein Zeichen, dass man entweder das Problem oder die Lösung nicht ganz verstanden hat. Oder das man versucht Daten die nicht zusammengehören in einem Objekt oder einer Datenstruktur zusammenzufassen.
Wenn Du nicht verstehst warum da ein `set()` hin muss, warum hast *Du* das denn da hin geschrieben? Letztlich wird dort die Schnittmenge der beiden Teilerlisten ermittelt und dafür hat der `set()`-Datentyp eine Operation. Zusätzlich ”filtert” der mehrfache Elemente aus, weil jedes Element nur einmal in einer Menge vorkommen kann.
Bei dem `i` ist eigentlich immer `b` geht es weniger um programmatische Effizienz, denn diese eine zusätzliche Variable ist ja nichts was den Rechner jetzt stark belasten würde, sondern darum das für den Leser einfach zu halten. Der Mensch kann nur eine bestimmte Menge an Informationen/Variablen gleichzeitig im Kopf jonglieren. Je nach Studie sind das wohl so zwischen fünf bis sieben ”Dinge”, weshalb man mit der Anzahl an unterschiedlichen Variablen in einer Funktion oder mindestens in einem Code-Abschnitt sparsam sein sollte.
Ich sehe nicht warum bei dem gezeigten Code das überschreiben von Zellwerten erlaubt sein müsste. Aber selbst wenn, ist es halt falsch das `True` durch so eine total verwirrende Zeichenkette zu ersetzen, die aussieht als würde dort ein Schlüsselwort-Argument übergeben. Insbesonder weil da "cell_overwrite_ok=False" genau den gleichen Effekt hätte, weil das eben auch im boole'schen Kontext `True` ist.
Ich habe die Hinweise mal umgesetzt und dabei hoffentlich keinen Fehler gemacht (ungetestet):
Code: Alles auswählen
#!/usr/bin/env python3
import xlwt
from sympy.ntheory import isprime
def berechne_primteiler(zahl):
primteiler = []
for i in range(1, zahl // 2):
if zahl % i == 0:
teiler = zahl // i
#
# TODO Warum wird hier die 2 als Primfaktor ausgenommen? Und warum
# wird dieser Umstand so umständlich/indirekt formuliert und nicht
# durch ein ``teiler != 2`` anstelle von ``teiler % 2 > 0``?
#
if teiler % 2 > 0 and isprime(teiler):
primteiler.append(teiler)
return primteiler
def main():
zahl = 9996 # Zahl mit Endziffer 6 angeben.
assert zahl % 10 == 6, "`zahl` hat falsche Endziffer"
anzahl_treffer = 0
b = None
for kandidaten_nummer, b in enumerate(range(3, zahl // 2 + 1, 2), 1):
a = zahl - b
primteiler_a = berechne_primteiler(a)
primteiler_b = berechne_primteiler(b)
if primteiler_a and primteiler_b:
anzahl_treffer += 1
print(
"Nr:",
kandidaten_nummer,
"Nr1",
anzahl_treffer,
"Ohne gem PT:",
a,
primteiler_a,
b,
primteiler_b,
set(primteiler_a) & set(primteiler_b),
a / b,
)
if b is not None:
book = xlwt.Workbook(encoding="utf-8")
sheet = book.add_sheet("Zahlsucher")
for i, text in enumerate(
["Nr", "Zahl", "a", "PrTa", "b", "PrTb", "a//b"]
):
sheet.write(0, i, text)
#
# TODO Ausser `i` und `teiler` enthalten alle Spalten in jeder Zeile den
# gleichen Wert. Das sieht falsch aus‽
#
quotient = a // b
for i, teiler in enumerate(primteiler_a, 1):
sheet.write(i, 0, i)
sheet.write(i, 1, teiler)
sheet.write(i, 2, a)
sheet.write(i, 3, primteiler_a)
sheet.write(i, 4, b)
sheet.write(i, 5, primteiler_b)
sheet.write(i, 6, quotient)
book.save("Zahlsucher.xls")
if __name__ == "__main__":
main()
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
Hallo _Blackjack_
ich bin noch am Durcharbeiten, bzw Dara, Deinen Programmvorschlag zum Laufen zu bringen.
Die Zeile sollte so aussehen:
Nr: 2453 Ohne gem PT: 5089 {7, 727} 4907 {701, 7} {7} 1.037089871611983
Hinter den beiden Paaren stehen je die Primteiler, dann die gemeinsamen PT und dann ein krumme Zahl, die 1,..... ist.
Dieser Quotient kann doch nur aus der Division zweier int berechnet werden.
Warum schreibst Du dazu:
Meines Wissens steht doch hinter primteiler_a) eine Liste. Oder irre ich?
Ich hatte nur mal die Paarungen in der Kette von 9996 gesucht, die sich ohne Rest teilen lassen.
Wie gesagt, daß Programm war manipuliert schon von mir. "Ohne gem. PT" ist nur noch Relikt.
ich bin noch am Durcharbeiten, bzw Dara, Deinen Programmvorschlag zum Laufen zu bringen.
Die Zeile sollte so aussehen:
Nr: 2453 Ohne gem PT: 5089 {7, 727} 4907 {701, 7} {7} 1.037089871611983
Hinter den beiden Paaren stehen je die Primteiler, dann die gemeinsamen PT und dann ein krumme Zahl, die 1,..... ist.
Dieser Quotient kann doch nur aus der Division zweier int berechnet werden.
Warum schreibst Du dazu:
?set(primteiler_a) & set(primteiler_b),
Meines Wissens steht doch hinter primteiler_a) eine Liste. Oder irre ich?
Ich hatte nur mal die Paarungen in der Kette von 9996 gesucht, die sich ohne Rest teilen lassen.
Wie gesagt, daß Programm war manipuliert schon von mir. "Ohne gem. PT" ist nur noch Relikt.
- __blackjack__
- User
- Beiträge: 14052
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Bykl: Ich schreibe da letztlich das gleiche wie Du, nur mit dem Operator statt der Methode:
Code: Alles auswählen
In [49]: {1,2,3}.intersection({2,3,4})
Out[49]: {2, 3}
In [50]: {1,2,3} & {2,3,4}
Out[50]: {2, 3}
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
Danke
zu dieser Zeile sagt mein Spider:
noch läuft das Programm nicht. Beim Kopieren scheinen besonders leicht Einrückungen flöten zu gehen.
Code: Alles auswählen
sheet.write(0, i, text)
im rich-text_helper steht:File "/Users/ottoreincke/opt/anaconda3/lib/python3.7/site-packages/xlwt/Row.py", line 278, in __rich_text_helper
raise Exception ("Unexpected data type %r" % type(data))
Was ist eigentlich der rich_text_helper?def __rich_text_helper(self, col, rich_text_list, style, style_index=None):
if style_index is None:
style_index = self.__parent_wb.add_style(style)
default_font = None
rt = []
for data in rich_text_list:
if isinstance(data, basestring):
s = data
font = default_font
elif isinstance(data, (list, tuple)):
if not isinstance(data[0], basestring) or not isinstance(data[1], Font):
raise Exception ("Unexpected data type %r, %r" % (type(data[0]), type(data[1])))
s = data[0]
font = self.__parent_wb.add_font(data[1])
else:
raise Exception ("Unexpected data type %r" % type(data))
noch läuft das Programm nicht. Beim Kopieren scheinen besonders leicht Einrückungen flöten zu gehen.
es bezieht sich auf diese Zeile:
Die verstehe ich überhaupt nicht ....
Code: Alles auswählen
if __name__ == "__main__":
main()
Was meint das? Muss da ein Float hin?runfile('/Users/.spyder-py3/malsehen.py', wdir='/Users/.spyder-py3')
Traceback (most recent call last):
File "<ipython-input-37-93d42ed6db9c>", line 1, in <module>
runfile('/Users/.spyder-py3/malsehen.py', wdir='/Users/.spyder-py3')
File "/Users/opt/anaconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py", line 827, in runfile
execfile(filename, namespace)
File "/Users/opt/anaconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py", line 110, in execfile
exec(compile(f.read(), filename, 'exec'), namespace)
File "/Users/.spyder-py3/malsehen.py", line 79, in <module>
main()
File "/Users/.spyder-py3/malsehen.py", line 70, in main
sheet.write(i, 3, primteiler_a)
File "/Users/opt/anaconda3/lib/python3.7/site-packages/xlwt/Worksheet.py", line 1088, in write
self.row(r).write(c, label, style)
File "/Users/opt/anaconda3/lib/python3.7/site-packages/xlwt/Row.py", line 252, in write
self.__rich_text_helper(col, label, style, style_index)
File "/Users/opt/anaconda3/lib/python3.7/site-packages/xlwt/Row.py", line 278, in __rich_text_helper
raise Exception ("Unexpected data type %r" % type(data))
Exception: Unexpected data type <class 'int'>
- __blackjack__
- User
- Beiträge: 14052
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Bykl: Ich hätte es tatsächlich mal testen sollen. Der komplette Traceback sieht so aus:
Der Ursprung in ”unserem” Code liegt also in der Anweisung ``sheet.write(i, 3, primteiler_a)``. Die `write()`-Methode die da aufgerufen wird, ruft ihrerseits eine `write()`-Methode auf einem `Row`-Objekt auf, und dort wird dann entschieden die `__rich_text_helper()`-Methode aufzurufen. Und zwar anhand des Datentyps von `primteiler_a`. Das ist eine Liste und bei Listen und Tupeln wird das versucht als ”rich text” in die Zelle zu setzen. Dazu muss die Sequenz offenbar aus Zeichenketten und Tupeln aus Formatinformationen und Zeichenketten bestehen. `primteiler_a` besteht aber aus ganzen Zahlen und damit kann die Methode nix anfangen.
Die Frage ist also was da in die Zelle geschrieben werden soll. Da muss halt irgend etwas hin was sinnvoll in eine Zelle geschrieben werden kann.
Code: Alles auswählen
Traceback (most recent call last):
File "./forum18.py", line 73, in <module>
main()
File "./forum18.py", line 64, in main
sheet.write(i, 3, primteiler_a)
File "/usr/local/lib/python3.6/dist-packages/xlwt/Worksheet.py", line 1088, in write
self.row(r).write(c, label, style)
File "/usr/local/lib/python3.6/dist-packages/xlwt/Row.py", line 252, in write
self.__rich_text_helper(col, label, style, style_index)
File "/usr/local/lib/python3.6/dist-packages/xlwt/Row.py", line 278, in __rich_text_helper
raise Exception ("Unexpected data type %r" % type(data))
Exception: Unexpected data type <class 'int'>
Die Frage ist also was da in die Zelle geschrieben werden soll. Da muss halt irgend etwas hin was sinnvoll in eine Zelle geschrieben werden kann.
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
-
- User
- Beiträge: 14
- Registriert: Sonntag 9. August 2020, 12:23
falls das ursprüngliche problem noch nicht gelöst ist:
das ist die beschränkung der Konsole (spyder ist eine IDE, im wissenschaftlichen bereich oft eingesetzt)
Einstellbar unter Einstellungen/Iphyton console. Nach einem neustart läuft der auch mit 20000 zeilen.
das ist die beschränkung der Konsole (spyder ist eine IDE, im wissenschaftlichen bereich oft eingesetzt)
Einstellbar unter Einstellungen/Iphyton console. Nach einem neustart läuft der auch mit 20000 zeilen.