complex diagonal matrix
Hi, I just wondered if there is a "nicer" way of generating a complex diagonal matrix than a) v=arange(10,typecode=Complex) mat=diag(v) b) v=arange(10) mat=diag(v)+0j Namely, wouldn't something like v=arange(10) mat=diag(v,typecode=Complex) be nicer? BTW: I somehow found that in the (excellent) documentation of Numeric the definitions from Mlab.py are a bit hidden. In my case I know nothing about matlab and I somehow expected that this type of routines are to be found in the section (together with zeros,ones etc. etc....) Also diag is not listed in the index http://www.pfdubois.com/numpy/html2/numpy-22.html#A or ? Arnd
baecker@physik.tu-dresden.de writes:
I just wondered if there is a "nicer" way of generating a complex diagonal matrix than a) v=arange(10,typecode=Complex) mat=diag(v) b) v=arange(10) mat=diag(v)+0j
Namely, wouldn't something like v=arange(10) mat=diag(v,typecode=Complex) be nicer?
Why would that be nicer? Personally, I prefer to have explicit typecodes limited to a very small number of array generators, and have all other functions apply the standard type-preservation rules. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
* baecker@physik.tu-dresden.de [26.01.2003 11:40]:
I just wondered if there is a "nicer" way of generating a complex diagonal matrix than a) v=arange(10,typecode=Complex) mat=diag(v) b) v=arange(10) mat=diag(v)+0j
Namely, wouldn't something like v=arange(10) mat=diag(v,typecode=Complex) be nicer?
No, because diag() is supposed to create a diagonal, but *not* to cast to another type. If you wanted to add that "functionality" to functions like diag(), you would also have to add it to functions like reshape() etc., i.e. practically everywhere. The way it is handled now is reasonably simple and flexible, and there is really no advantage of your suggestion compared to approach a). Cheers, Joachim
participants (3)
-
baecker＠physik.tu-dresden.de -
Joachim Saul -
Konrad Hinsen