Hi,
ja habe schon geschrieben, aber ohne Anmeldung. Habe Antwort bekommen, dass Moderator meine Mail freigeben muss. Werde mich ggf. anmelden, Danke!
Wir haben noch einen Tipp bekommen. Es gab schon einmal so ein Problem, damals wurden unterschiedliche numpy-Versionen bei a) Kompilieren der EXE in C++ und b) den Python-Dateien benutzt, was zu diesem Fehler führte. Das haben wir überprüft und auch Visual Studio greift auf numpy-1.0.2-Ressourcen (header-Dateien...) zu, genau wie ich diese Version auch für die Pythonseite benutze.
Der Teufel steckt im Detail.
edit: Jetzt habe ich angemeldet an die MailingList geschrieben!
Rechenoperationen mit numpy.float64
OH WUNDER! OH WUNDER!
Nach viel Mühe und Herumprobieren, geht es nun. D.h. die Fehlerzeile wird nun nicht mehr als Fehler angezeigt.
Ich musste das
in
umwandeln. Darauf bin ich bei zahllosen testläufen irgendwann zufällig gekommen, habe ausprobiert und es liefert das gewünschte Ergebnis (=200.0).
Danke Euch allen, zumindest dieser Schritt ist nun erstmal erledigt für mich.
Michael --
Nach viel Mühe und Herumprobieren, geht es nun. D.h. die Fehlerzeile wird nun nicht mehr als Fehler angezeigt.
Ich musste das
Code: Alles auswählen
deltaX = x[m+1] - x[m]
Code: Alles auswählen
deltaX = x[m+1]*1.0 - x[m]*1.0
Danke Euch allen, zumindest dieser Schritt ist nun erstmal erledigt für mich.
Michael --
Python rockt.
Nee, ist nicht wahr, oder?
Allerdings würde ich ggf. statt '* 1.0' 'float(...)' schreiben, weil dann klar ersichtlich ist, warum man das macht - auch in drei Monaten. Der Code wird wahrscheinlich am wenigsten abgebremst, wenn Du überall wo arrays aus floats gebraucht werden schaust wo sie generiert werden und xxxxx(...., dtype = numpy.float64) schreibst. Hierbei ist xxxxx irgendeine array-Konstruktorfunktion, z.B. arange() oder array().
Ich frage mich aber, wie das sein kann. Bug in numpy oder in Deiner Software?
Gruß,
Christian
Allerdings würde ich ggf. statt '* 1.0' 'float(...)' schreiben, weil dann klar ersichtlich ist, warum man das macht - auch in drei Monaten. Der Code wird wahrscheinlich am wenigsten abgebremst, wenn Du überall wo arrays aus floats gebraucht werden schaust wo sie generiert werden und xxxxx(...., dtype = numpy.float64) schreibst. Hierbei ist xxxxx irgendeine array-Konstruktorfunktion, z.B. arange() oder array().
Ich frage mich aber, wie das sein kann. Bug in numpy oder in Deiner Software?
Gruß,
Christian
Welchen?
@mod_che: Welchen Typ hatte eigentlich das Array `x`? Kannst Du in der Ausnahmebehandlung mal ``x.dtype`` mit ausgeben?
Deine "Lösung" des Problems ist nicht wirklich eine. Solange nicht geklärt ist, warum dieser wirklich unerklärliche Fehler auftaucht und die noch weniger erklärbare "Lösung" funktioniert, würde ich keinem einzigen Ergebnis des Programms vertrauen. Die "Lösung" ist Voodoo ─ damit wird nur ein Symptom versteckt, aber kein Problem gelöst.
Deine "Lösung" des Problems ist nicht wirklich eine. Solange nicht geklärt ist, warum dieser wirklich unerklärliche Fehler auftaucht und die noch weniger erklärbare "Lösung" funktioniert, würde ich keinem einzigen Ergebnis des Programms vertrauen. Die "Lösung" ist Voodoo ─ damit wird nur ein Symptom versteckt, aber kein Problem gelöst.
Hehe, die Lösung ist Voodoo, das ist gut. Ja, sicherlich habt ihr recht mit Eurer Skepsis.
Ich habe alle so errechneten Werte ausgeben lassen und sozusagen nebenbei von Hand zur Kontrolle gerechnet - bisher habe ich keinen Fheler dabei finden können.
Den Type kann ich gerade nicht ausgeben, weil ich Code nicht hier habe. Morgen auf der Arbeit werde ich das aber hinbekommen.
Die "Lösung" ist auch mir suspekt und ich kann auch nicht verstehen, wieso es jetzt geht? Aber, was soll ich machen, Python rechnet jetzt, was eigentlich immer rechenbar war, oder?
Und wenn das ganze ein Bug im numpy ist?
Ich habe alle so errechneten Werte ausgeben lassen und sozusagen nebenbei von Hand zur Kontrolle gerechnet - bisher habe ich keinen Fheler dabei finden können.
Den Type kann ich gerade nicht ausgeben, weil ich Code nicht hier habe. Morgen auf der Arbeit werde ich das aber hinbekommen.
Die "Lösung" ist auch mir suspekt und ich kann auch nicht verstehen, wieso es jetzt geht? Aber, was soll ich machen, Python rechnet jetzt, was eigentlich immer rechenbar war, oder?
Und wenn das ganze ein Bug im numpy ist?
Python rockt.
diesen! Verstehe nicht ganz, was ich machen soll.CM hat geschrieben:Nee, ist nicht wahr, oder?
Allerdings würde ich ggf. statt '* 1.0' 'float(...)' schreiben, weil dann klar ersichtlich ist, warum man das macht - auch in drei Monaten. Der Code wird wahrscheinlich am wenigsten abgebremst, wenn Du überall wo arrays aus floats gebraucht werden schaust wo sie generiert werden und xxxxx(...., dtype = numpy.float64) schreibst. Hierbei ist xxxxx irgendeine array-Konstruktorfunktion, z.B. arange() oder array().
Sorry, ich weiss, ich bin manchmal etwas lahm, wirklich toll, dass mir so viel von Euch geholfen wird! DANKE!
Python rockt.
bzgl. BlackJacks post: Stimmt, ich bin implizit von einem Bug im Programmcode ausgegangen, bei dem dtype != float64 ist. Aber das muß nicht sein, weil:
Numpy Version ist 1.0.1. Doch ein bug in numpy? Wer will fragen?
Gruß,
Christian
Code: Alles auswählen
In [1]: from numpy import *
In [2]: a = arange(2)
In [3]: a
Out[3]: array([0, 1])
In [4]: a.dtype
Out[4]: dtype('int32')
In [5]: a.dtype = float64
In [6]: a.dtype
Out[6]: dtype('float64')
In [7]: a
Out[7]: array([ 2.12199579e-314])
Gruß,
Christian
Das sind zwei, aber gut:mod_che hat geschrieben: diesen! Verstehe nicht ganz, was ich machen soll.
Sorry, ich weiss, ich bin manchmal etwas lahm, wirklich toll, dass mir so viel von Euch geholfen wird! DANKE!
- mit float(...) statt *1.0 meine ich, daß explizit eben besser als implizit ist: Wenn Du in ein paar Monaten wieder auf den Code schaust, hilft ein Kommentat zusammen mit einer expliziten Konversion eben mehr, als ein Gehuddel, bei dem Du irgendwann nicht mehr weißt wozu. --- Mal abgesehen davon, daß BJ recht hat: Eigentlich muß diese Konversion überflüssig sein.
- mit dem zweiten meine ich, daß irgendwo Dein 'X' als array erzeugt wird. Dann existieren entweder schon floats oder es muß explizit in der Erzeugung dtype = float64 oder so angegeben sein, z.B.
Code: Alles auswählen
a = arange(10, dtype=float64)
Gruß,
Christian
OK, ich habe nochmal und nochmal nachgesehen und schlussendlich auch den Voodoo-Zauber erlegt
Es gibt bei mir eine Zeile
und diese müsste wohl eher
heißen, was?
Tatsächlich, dies löst das Problem mit dem
Was soll man sagen, ich habe viel gelernt, Eure Geduld strapaziert und bin beim nächsten Mal umsichtiger, OK?
Danke nochmal und Grüße aus Berlin
Michael --
PS Jetzt nicht wundern, ich habe numpy as Numeric importiert
Es gibt bei mir eine Zeile
Code: Alles auswählen
self.x = Numeric.array(self.x)
Code: Alles auswählen
self.x = Numeric.array(self.x, dtype=Numeric.float64)
Tatsächlich, dies löst das Problem mit dem
Code: Alles auswählen
deltaX = x[m-1] - x[m]
Danke nochmal und Grüße aus Berlin
Michael --
PS Jetzt nicht wundern, ich habe numpy as Numeric importiert
Python rockt.
Hoi,
jou, sieht gut aus. Und ist jetzt auch verständlich, obwohl eigentlich numpy selbständig den Typ zuweisen sollte ...
Gruß,
Christian
jou, sieht gut aus. Und ist jetzt auch verständlich, obwohl eigentlich numpy selbständig den Typ zuweisen sollte ...
Quatsch, so was gehört dazu. Außerdem habe ich hier auch Fehler gemacht und selbst BlackJack macht ab und zu Fehler . Einfach am Ball bleiben.mod_che hat geschrieben: Was soll man sagen, ich habe viel gelernt, Eure Geduld strapaziert und bin beim nächsten Mal umsichtiger, OK?
Gruß,
Christian