Rechenoperationen mit numpy.float64

[CM]

`Numeric` wird doch gar nicht importiert. Zumindest in dem Stück was hier gepostet wurde, ist das nur ein anderer Name für `numpy`.

Jou, war Blödsinn: x-mal hingeguckt und dann nicht mehr gesehen, was eigentlich abgeht ...

Habe dazu das gefunden: http://projects.scipy.org/pipermail/sci ... 06083.html

Verstehe nicht was das mit Deinem Problem zu tun hat: Hierbei geht um Inputparameter für Scipy-Funktionen. Ein Problem was übrigens mittlerweile gelöst ist (jedenfalls in svn).

OK, scheinbar ist X vom Type ndarray, die Zähler in den [] aber floats? Bzw. die Zusammensetzung x[m+1] ergibt dann einen Float? Also, müsste ich was Konvertieren, oder?

Nein, die Konvertierung ist implizit. Das sollte keine Fehlermeldung geben (u. U. aber ein nicht erwünschtes Ergebnis). Wie aber sieht X.shape aus? Und wie Y.shape?

Gruß,
Christian

[CM]

PS Habe gerade etwas länger geschrieben und wurde unterbrochen, deshalb habe ich eure letzten Posts auch erst jetzt gesehen: Das Programm ist kommerziell, oder? Dann sollte es dafür eigentlich auch entsprechenden Support geben.

Gruß,
Christian

PPS Dennoch wüßte ich noch gerne - als letzte Idee - was .shape dieser beiden arrays ist.

[mod_che]

Kann man an die eMail-Adresse, welche auf der numpy-Seite gelistet ist, einfach so eine Mail schreiben oder muss man sich irgendwie anmelden?

[mod_che]

Hi Christian,
auch Dir nochmals Danke für die Hilfe und das Mitdenken!

Hier deine ShapeInfos:

Code: Alles auswählen

len x <type 'numpy.ndarray'> 252
len y <type 'list'> 137
x.shape: (252,)
######################################################################
type x <type 'numpy.ndarray'>
type_a, type_b <type 'numpy.float64'> <type 'numpy.float64'> True
######################################################################
Inappropriate argument type.
unsupported operand type(s) for -: 'numpy.float64' and 'numpy.float64'

y.shape funktioniert ja logischerweise nicht, da y vom Typ 'list' ist, was mich jetzt auch wieder etwas wundert. Auf jeden Fall ist len(x) ungleich len(y), aber das kann ja passieren. Es handelt sich sozusagen um eine Area für Grundwassermodellierung, also einen Layer mit Ausweitung x und y in zwei Richtungen. Dieser Layer ist eben nicht immer quadratisch, daher macht das schon Sinn. Wieso aber einmal array und einmal list, keine Ahnung, werde am Ball bleiben und habe auch schon mal eine Mail an numpy-mailingList geschrieben.

Bis bald...

[CM]

Kann man an die eMail-Adresse, welche auf der numpy-Seite gelistet ist, einfach so eine Mail schreiben oder muss man sich irgendwie anmelden?

Du kannst jederzeit eine Mail an die Liste schreiben, aber wenn Du sie auch lesen willst, mußt Du dich anmelden: http://www.scipy.org/Mailing_Lists

Ehrlich gesagt: Ich habe auch keine Ahnung mehr, was da vorgeht. Allerdings habe ich noch keine Mail von Dir auf der numpy-Mailingliste gesehen. Hast Du tatsächlich schon an die Liste geschrieben?

Gruß,
Christian

[mod_che]

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!

[mod_che]

Muss man die Subtraktion ansich vielleicht anders vorgehen? Bzw. kann ich werte auch mit anderen Methoden/Befehlen berechnen? Numeric.subtract oder so?

[mod_che]

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

Code: Alles auswählen

deltaX = x[m+1] - x[m]

in

Code: Alles auswählen

deltaX = x[m+1]*1.0 - x[m]*1.0

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 --

[CM]

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

[mod_che]

Stimmt, ich sollte mal aussagekräftige Kommentar zu diesem Codebereich schreiben.

Ich verstehe nicht ganz, was Du mit deinem Hinweis meinst?

[CM]

Welchen?

[BlackJack]

@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.

[mod_che]

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?

[mod_che]

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().

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!

[CM]

bzgl. BlackJacks post: Stimmt, ich bin implizit von einem Bug im Programmcode ausgegangen, bei dem dtype != float64 ist. Aber das muß nicht sein, weil:

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])

Numpy Version ist 1.0.1. Doch ein bug in numpy? Wer will fragen?

Gruß,
Christian

[CM]

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!

Das sind zwei, aber gut:
- 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)

, denn auf diese Weise muß sichergestellt sein, daß alle Zahlen vom gleichen Typ sind. --- Aber auch hier gilt: Nachschauen (siehe BJs post).

Gruß,
Christian

[mod_che]

OK, ich habe nochmal und nochmal nachgesehen und schlussendlich auch den Voodoo-Zauber erlegt
Es gibt bei mir eine Zeile

Code: Alles auswählen

self.x = Numeric.array(self.x)

und diese müsste wohl eher

Code: Alles auswählen

self.x = Numeric.array(self.x, dtype=Numeric.float64)

heißen, was?

Tatsächlich, dies löst das Problem mit dem

Code: Alles auswählen

deltaX = x[m-1] - x[m]

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

[CM]

Hoi,

jou, sieht gut aus. Und ist jetzt auch verständlich, obwohl eigentlich numpy selbständig den Typ zuweisen sollte ...

Was soll man sagen, ich habe viel gelernt, Eure Geduld strapaziert und bin beim nächsten Mal umsichtiger, OK?

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.

Gruß,
Christian